Welcome to Agile Hotline!
One of the Scrum Master’s we coach often calls us with problems he is dealing with. He joked that we should answer our phones as ‘Agile Hotline, how can we help?’. We decided it was such a great idea we are starting a series on our blog called Agile Hotline. These are our answers to questions we get from people about agile or Scrum. Our hope is that others can learn from them.
Question
Recently someone asked for advice about a debate he was having with a co-worker about whether agile and Scrum can work in any software development scenario. The co-worker argued that it couldn’t.
This was his scenario
Say we are working on building a software product that allows user’s to take assessments while reading an e-book. We are told that the client’s vision was there to be at least 2 types of these assessments.
In the agile/scrum way of doing things, we would typically try and deliver a working, valuable product sooner and so the goal is to deliver 1 of these assessment types which can be used very early on by the users. This would be v1.0. We then a little later down the line start implementing the second type of assessment, and aim to deliver that a couple sprints after as v2.0
In the waterfall approach, we would take how ever long it would take to deliver both assessment types in the first version.
My co-worker’s argument was that, in this case, waterfall made more sense, because he argues that there would be a high chance of needing to refactor all the code to support the second assessment type for v2.0. While in waterfall, both assessment types would be developed together, despite it taking longer to deliver the first working version of the product, there would be less rework.
He believes waterfall saves time and is more efficient because there would be less refactoring if you start developing with current and future requirements. While in agile, even though we are aware of the need to support more types of assessments in 5-7 sprints time, our focus is on the ‘now’ and on the only 1 type of assessment.
What is your take on this? How would you address a group of developers who see agile as introducing the need to re-do work in the future because they ‘weren’t allowed to plan’ to far ahead?
What we think
There are really 3 key points to understand first, so I will explain those first and then answer the question.
- Firstly: Agile and Waterfall both have their place. Agile is designed for complicated/complex systems, i.e. when there is some uncertainty in requirements and/or technology. Waterfall is best for simple projects e.g. when requirements and technology are well understood and not going to change. We use the Stacey Matrix to describe when to use each. The problem is that in the complex space waterfall fails completely, whereas in the simple space agile works, but is just a lot of overhead.Our favourite example when explaining this is organising a conference. This is a simple project and so waterfall works best. You can use agile, but it will seem like unnecessary overhead.
- Secondly: Agile is NOT more efficient that waterfall. It is more effective. This means it might take more man hours to deliver something with agile, but it is likely to be released to market sooner with agile (because you should be able to release at the end of each sprint, rather than only at the end of the project) and the total cost of ownership is likely to be lower (because quality and design is better, and knowledge is shared so maintenance is easier).
- Thirdly: Agile is not about building the same stuff faster. It is about maximising the amount of work NOT done. The Chaos report tells us that 65% of software is never or rarely used. With agile we try to identify the 35% that is most likely to be used then building that first, and then stopping. So even though it might take longer to build that first 35%, we save by not building the other 65% no one will use.
So how does this relate to the example project? Well firstly you wouldn’t build the whole first assessment and then build the second assessment, you’d identify the most valuable part of the assessment. Maybe it is one type of question (let’s say for example a multiple choice question). You would build just one question into the assessment, then test it with users and figure out if it works. You could even release the first assessment with only multiple choice questions. Then you would build the next most important assessment question type. Or maybe you would decide that is good enough and start on a different project.
If the scope of the assessments is really fixed, known to work with the users, and there are 0 unknowns in the technology then waterfall might be a better choice for this project. Agile will still work, but it won’t necessarily save you time. In my experience people like to think the requirements are well know and understood, but usually they aren’t, so the ‘overhead’ of agile is often worth it.
If you have any questions or things you are struggling with – please email us – and maybe it too will become a blog post 🙂