Don’t Do Scrum, Be Agile!
Don’t Do Scrum, Be Agile!
Lately we see more and more places where Scrum is applied by the book with little added value. One traditional methodology just gets replaced by another.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
Lately we see more and more places where Scrum is applied by the book providing but little added value. One traditional methodology just gets replaced by another methodology: changing names, sometimes roles. But the mentality, the dynamics remain the same.
Often these people have never experienced anything else than heavy bureaucracy and this prevents them from realizing that the things that matter have not changed, they are still doing the same things. They cannot see that there actually is another way.
In such a context, constant discussions would be held about what the theory says: “Normally, during this ceremony you have to do this first, then you have to do that”. You’ll hear extensive use of unnecessary jargon and the imperative will to follow every given rule (I am generally quite wary of sentences that begin with “Normally you have to …”).
What comes along with a global adoption of the whole SCRUM methodology is that you don’t always really understand what added value each practice brings to your team and why. Because of that you can’t make sure each of these practices fits your organization’s needs.
And that’s a pity, because you’re probably the persons who are in the best position to know how your team should work (much better than a bunch of guys writing books living on another part of the world anyway).
All of this makes people lose sight of the real game-changer: the agile mindset. It requires a profound mind-shift, but that’s what really makes a difference: it increases the chances to deliver actual value.
To achieve this, you need to split your deliverable (be it software or anything else) in small useful/working pieces. Then work on one at a time only and have a way to check the actual status after each one is done. This reality check is critical. That way you can always decide to change the next steps at any time and still know that everything that was already done can actually be used. The goal is then to continuously improve, step by step.
In the end it is important to have a long term vision but a short term view on the details.
So how do you get there? First, you do this collaboratively with all the members of the team who want to join. You try to visually represent the way the team works (a big drawing is perfect for this), then you identify issues and select the first one you want to work on (probably based on the pain it causes and the estimated workload for the solution).
Before you solve your issue, you might want to look around to see what solutions others have found to similar problems. And that’s where Scrum practices and XP techniques can be of great help!
But then the key point is to really understand the reason why each practice works and in which context. Only then can you decide how you want to try it in your context. Don’t forget to also come up with your own solutions, they are often the most relevant to your situation!
You would be well advised not to try too many different new practices at the same time if you can avoid it. This way you can assess together as a team the result of one particular practice and decide if you want to keep doing that, modify it or stop it.
In the end nobody cares what is “real” Scrum and what is not. By experimenting and progressively, continuously improving your way of working you can find your methodology. The one that really fits your team and its challenges. It will evolve with your team, with its future challenges, unlike any methodology you’ll find in a book.
This is how you achieve efficiency: don’t do Scrum, be Agile!
Opinions expressed by DZone contributors are their own.