Scrum is one of the most popular software development methodologies today. I have personally been part of a couple of agile transformations in my career. However, many companies adopt agile practices and scrum and hold onto them holistically. This religious view on such agile development practices can cause huge resource waste. Agile or scrum is not always the best way to go forward. In this article I will present one example when such practices can do harm to a software project.
If you’ve been developing software for at least a few years, you probably have experience with so-called “greenfield” projects. A greenfield project is simply a new project, not building on anything existing. The analogy is to build on a green field - there are no existing buildings or infrastructure. This is opposed to brownfield projects - which would involve changes and maintenance to an existing piece of work. (source - stackexchange).
Starting with scrum does not always make sense
When you start such a project in a new team, your company probably has decided to use scrum as the development methodology. You will have planned bi-weekly sprints, retrospectives and plannings. However, very well know, that you won’t deliver first working software in the first two weeks of the projects. Sometimes, there is this practice of running “sprint zero” to get familiar with your colleagues and the project. For many projects that I’ve been a part of, even 4 weeks was not enough to release anything into production (and according to scrum you should be delivering every sprint to production).
Why first version of your application should be an MVP
The essence of “agile” is to have an iterative process that delivers business value fast, on each iteration. MVP fits this description perfectly. You can read more about MVPs in my blog series here. However, developing an MVP might take much longer than 2 sprints of your scrum process. Instead of having artificial bi-weekly sprints, it’s better to negotiate with your Product Owner or Scrum Master so-called „sprint zero” and define the length of it by estimated time to deliver the first working version of the software. This will save you a lot of time as you will cut from your week at least a day for scrum meetings. The sprint zero will probably be very large compared to others, we are talking here about a month or two of development. That’s usually the time that takes to develop first working version of any new software.
Don’t forget to cut the scope for the first release
Also consider cutting scope for the sprint zero. The goal is to kickstart the project as soon as possible. All the rest can be done later. As you already know, MVP is all about core functionality. Don’t inflate the scope by adding features that are not crucial to the first version of the application. With agile processes you should always build on top of working software (by working I mean - in production, used by customers).
Summary
Adopting agile practices blindly does not give any benefits. What I want to stress here, is that instead of pretending to work in sprints and spending time on countless scrum meetings, it’s better to work steadily towards the first working version of software. Only after achieving that, you should start discussing, whether to adopt scrum or not. This way, your company will save money and you will save a lot nerves, as you won’t be part of many pointless meetings that don’t help with you delivering software.