I've become convinced that the first widespread software methodology is still the best one: PRIDE (Profitable Information by Design).
You probably haven't heard of PRIDE. It's on the verge of being lost to time. But the principles behind it have driven successful software projects for about 70 years now. It was originally released in 1971 by Milt Bryce through his company, Milt Bryce & Associates, based on Milt's experience leading major software projects dating back to UNIVAC in the 50s. Milt's son, Tim Bryce, continued to market the PRIDE methodology and materials until recently.
The thing about PRIDE is how comprehensive it is. It encompasses business analysis, business process design, database design, and software design and development; and every artifact from single requirements to code changes is given a tracking number (decades before JIRA or Git, and these numbers were at first tracked on paper!). It's not really focused on developing software but the design and construction of business systems. Computers are only a part of the overall puzzle, and programmers have a tendency to fixate on just that part and not see the big picture. What PRIDE provides is a framework for understanding the business as a whole, the information needs of the various business systems, and how to design procedures to be executed (by human or computer) to fulfill those needs. It starts with a comprehensive systems analysis phase (undertaken by systems analysts -- not programmers -- which profession has also been nearly lost to time) followed by an in-depth design phase. A common vocabulary is developed so that the business people and programmers can communicate in plain English. The database is also designed based on this vocabulary; in fact Milt Bryce was also the inventor of the concept of a "data dictionary". Then the software is designed, its design thoroughly documented, and then it's implemented by the programmers.
Compared to Scrum and Kanban, it's very waterfall-like and involves a lot of big design up front. That's a feature, not a bug. The solution to not knowing what your requirements are is to figure that bit out first and make sure the programmers have very clear goals before they write a single line of code -- not to put programmers in the driver's seat and have them make guesses at an implementation until the stakeholders say "yeah! That's it!" That means bringing systems analysts in and having them identify the systems, what data they consume, and what data to produce.
I think that PRIDE-like methodologies are going to be the future of software development, especially in this post-ZIRP era where the money is attracted to profitability, not the latest Silicon Valley fad. I've never been on a Scrum team that delivered on time or under budget. What's needed is more thought up front, and more discipline and accountability built into the process.
You probably haven't heard of PRIDE. It's on the verge of being lost to time. But the principles behind it have driven successful software projects for about 70 years now. It was originally released in 1971 by Milt Bryce through his company, Milt Bryce & Associates, based on Milt's experience leading major software projects dating back to UNIVAC in the 50s. Milt's son, Tim Bryce, continued to market the PRIDE methodology and materials until recently.
The thing about PRIDE is how comprehensive it is. It encompasses business analysis, business process design, database design, and software design and development; and every artifact from single requirements to code changes is given a tracking number (decades before JIRA or Git, and these numbers were at first tracked on paper!). It's not really focused on developing software but the design and construction of business systems. Computers are only a part of the overall puzzle, and programmers have a tendency to fixate on just that part and not see the big picture. What PRIDE provides is a framework for understanding the business as a whole, the information needs of the various business systems, and how to design procedures to be executed (by human or computer) to fulfill those needs. It starts with a comprehensive systems analysis phase (undertaken by systems analysts -- not programmers -- which profession has also been nearly lost to time) followed by an in-depth design phase. A common vocabulary is developed so that the business people and programmers can communicate in plain English. The database is also designed based on this vocabulary; in fact Milt Bryce was also the inventor of the concept of a "data dictionary". Then the software is designed, its design thoroughly documented, and then it's implemented by the programmers.
Compared to Scrum and Kanban, it's very waterfall-like and involves a lot of big design up front. That's a feature, not a bug. The solution to not knowing what your requirements are is to figure that bit out first and make sure the programmers have very clear goals before they write a single line of code -- not to put programmers in the driver's seat and have them make guesses at an implementation until the stakeholders say "yeah! That's it!" That means bringing systems analysts in and having them identify the systems, what data they consume, and what data to produce.
I think that PRIDE-like methodologies are going to be the future of software development, especially in this post-ZIRP era where the money is attracted to profitability, not the latest Silicon Valley fad. I've never been on a Scrum team that delivered on time or under budget. What's needed is more thought up front, and more discipline and accountability built into the process.
The current PRIDE book, PRIDE Methodologies for IRM: https://www.amazon.com/PRIDE-Methodologies-IRM-Tim-Bryce/dp/...
Tim Bryce's PRIDE web site: http://www.phmainstreet.com/mba/mbapride.htm
Old vid of Milt Bryce explaining PRIDE and ASDM (a suite of project management tools based on PRIDE written in COBOL): https://www.youtube.com/watch?v=SoidPevZ7zs