There is something wrong with Scrum today
I don’t know what it is
Something’s wrong with our eyes
We’re seeing things in a different way
And Agile it ain’t is
It shore ain’t no surprise
Living on the edge…
The moment I learned about Scrum I became a big fan. I have been part of teams that used it in different companies. I have seen teams that deliver great software with it, I have also seen teams struggle and fail.
Yet sometimes I question its very existence… Where does the hype around it ends and reality begin?
It is almost to good to be true – self-organizing teams, customer collaboration, predictable delivery in small iterations, focus on delivering value to customers, high quality.
Agile and Scrum became buzzwords, something very good that “everybody is doing”, so “we must do it as well”.
And thats exactly the problem – “we” are not doing it.
Organizations “adopted” Scrum, but instead of focusing on the Agile Manifesto values and principles, they focused on the process. When you think about it is actually not that surprising – they just substituted some parts of their existing process with others and declared “Agility”.
What do you need in your organization to actually practice Scrum
- Your budget plan or customer contract needs to have some flexibility
- Your teams need to follow an iterative process by working and delivering in small iterations
- Your individual team members needs to be able to produce high-quality shippable software every few weeks
Reality
- Your budget plan or customer contracts are fixed. This frequently makes scope, time or both of your project fixed
- Your teams start to work in iterations, sometimes small, sometimes bigger.
- Your team members are doing their best to deliver, but frequently progress is very slow as quality suddenly drops
Is reality that bad?
Actually, no. It is definitely better than Waterfall with its huuuuge plan/execute/verify. But there is a lot to improve.
Budget planning
Nobody will give you money just like that. They need to know how you are going to spend them after all. So you will sign a contract. But for that you need estimations and planning. Estimations are however very different from contracts, as they are rarely precise. Contracts are a promise something will be delivered. Estimation is just some numbers and good ones have a range – 3-5 months, 5-8 weeks. Now only if you can put those ranges in a contract!
Actually – you can, but it is very hard to convince your clients or managers to sign such a document. By putting a flexible scope and budget you are reducing your risk of failing a contract. By doing the opposite your clients will transfer the risk to you. So it is actually in their interest to demand it. The risk for them becomes you to build the wrong feature, but at least they will spend predictable amount of money on it.
You have to balance money with value provided. Be prepared for money to frequently win as they are very easy to measure. Value you create, on the other hand, is not.
Following iterative process
There is a lot of benefit in working in smaller iterations. It makes development much more predictable over time and you will quickly find gaps and issues in your initial estimations. Unlke Waterfall, you will catch those much earlier, giving you at least some chance to alter that fixed contract/budget.
The real danger here is the need to maintain high quality work and actually produce “shippable” product every iteration. If you fail this more and more bugs will start to emerge and your progress will become slower and slower. Eventually technical debt will kill you, which brings us to our next point.
Maintaining High Quality
Highest quality is lowest cost
This Japanese aphorism reminds us about all the costs that just do not exists if your production quality standards are high.
By just focusing on the iterative process and not thinking about changing the way you work you are making your life very difficult. Because of this the term “Flaccid Scrum” was defined by Martin Fowler in this great post written 6 years ago.
Flaccid Scrum is like a shiny Chinese replica of a sports car. It looks great, have all these gadgets inside, but engine is the same as your 10 year old Toyota. You cannot judge the horsepower just by the appearance.
So what can you do? Make everything possible to produce high quality work. Look up the extreme programming practices and try to adopt some of them. Examples include:
- Automate your regression testing – learn when you introduce bugs and avoid retesting it time and time again manually
- Pair program and code reviews – this will greatly increase the quality of your design – producing less technical debt and bugs in the process
- Use Test-Driven-Development
Scrum actually does not prescribe any practices. And perhaps this is one of the reasons people think just following this iterative process is good enough. But Scrum is also about continuous improvement and effective Scrum teams will find and adopt practices that are good for them.
All practices I have listed have one thing in common. They focus on long-term
improvements over short-term gains and require a great deal of discipline. This is one of the main reasons they are not that widely used – just think about how hard it is to start running or going to the gym. You know it is good for you, but to get benefit from it you need to do it regularly and you will see first results after weeks of sweat.
How can you adopt these? This should probably be another post, but here are some suggestions.
- Suggest the team to experiment with a practice for a week.
- Make workshops, where people can practice safely – things like coderetreats and coding dojo.
- Explain in lectures the values of unit testing.
- Most important of all – just show people how these work and they will follow.
Best part is – these will always benefit you and your team. No matter the process you are trying to follow.
Think about it – what has greater impact on your project outcome? Yours and your team skills and attitude, or some great process you are supposed to follow?
Thank you for reading