How to Overspend on Development Teams
When is Agile Software Development Worse?
Existing products used by known customer groups are usually best developed with conventional waterfall methodology (ie. like you would build a house). I would also argue that anything that has already been sold to a customer should be developed with conventional Waterfall. In both of these cases, the end point is clear, uncertainties are few, and thus few changes are anticipated. With waterfall, the development team has tools to manage risks over the entire project, optimize efficiency across the full scope, and can be held fully accountable.
When developing a new product for a new market, there are lots of unknowns on the technology, business, and user sides. Agile (eg. Scrum) is the way to go. Combine this with Lean Startup techniques and we see how under-gunned startups can still crush an established player in the market. With Scrum, every one week sprint is a potentially releasable product and if it is a failure or a dead-end, it is quickly discovered, rolled back, and mistakes corrected. In addition, teams write uninterrupted code for days at a time yet priority and specifications can still be changed weekly. It is a near perfect balance for early stage and high uncertainly digital products
The worst of both worlds, however, is to make waterfall specifications and use an engineering team that is operating with Scrum methodology. In such a scenario, there are no benefits from mid-point releasable products since no one plans to use anything until the full release. Even if they could, there is no one on the user/business side to help to design the sprints and plan incremental experience testing
In this scenario, the discipline of Scrum development methodology to focus on the in-sprint issues and de-emphasise the backlog means that efficiency, estimation accuracy and dependencies are poorly managed over the overall scope without any benefit in return. Finally, since formal iterations are not used to confirm requirements with releasable sub-products, there is a high risk that substantial effort was consumed without fulfilling the main product need. If specifications could be perfect, the design freedom and subsequent benefits found in Scrum are simply too risky. At DLabs we see this happen so often that we started to call it “Fake Agile”.
“Fake Agile” is the epidemic striking founders and entrepreneurs globally.
Fake Agile
Fake agile is common with founders/entrepreneurs that have strong business knowledge when they take the time to write full specifications of an entire product. (This can still be a very useful exercise even if you are running proper agile/scrum, but the key is to break this into Epics & Stories that can fit within sprints and design user/business testing with each partial product). With full specifications in hand and a feeling that everything is critical, “fake agile” users either don’t know how to manage (the costs of) agile and/or simply tell themselves that sprint planning and participation is not a critical use of their limited bandwidth.
Want to waste 30+% of investment money on engineering costs? Choose a project house (waterfall development) for your new breakthrough product. Want to waste 50+%? Hire a Scrum team and send them equally detailed specifications in an email. For everyone else, we suggest you learn how to manage costs in an Agile development world and take advantage of this amazing development methodology breakthrough. Want to save even more? Synchronize your business development cycles with your Scrum development cycles and become super “lean”.
Enjoyed reading the article? Hit that clap button 👏 and help others find it.
Have any question, you are building your own product (or/and company) or just want to connect? Drop me an email on matt.mayfield@dlabs.si I’ll be happy to help.