I'm not a believer in frameworks or rigid methodologies. The world is complex, and it's nearly impossible that whatever framework you can define today will fit every current or future need of the team.
Nevertheless, a company or team should start somewhere, continuously inspect their work, and make changes to fit current and future needs.
When deciding which methodology to use as a starting point, I like how Simon Wardley frames it. He says you need to look at the type of product or component you're going to be working on:
- Are you working on a novel idea? This means that requirements might change, people do not yet know what they want, or there is no product-market fit. Use Agile.
- Is your product or component serving customers or found Product Market Fit? You want to go Lean, focusing on reducing waste, learning, and continuous improvement.
- Is your product or component a commodity? You may want to try Six Sigma (or ITIL, if you work in IT) to help you lower costs and be more predictable.
It is also worth noting that different parts of your organization or team might be working on these different stages of development simultaneously, so you should be open to changing the methodology or using more than one according to your needs.
Follow me on Twitter or subscribe to the newsletter for more articles on software engineering leadership and troubleshooting software engineering teams' problems.
