Agile is Evolution not Revolution
When we take steps towards agility, we shouldn´t look for revolution, we should aim for evolution. Let´s take small steps towards a more fun and efficient way of working!
One way we could start with is to eliminate some waste: Some parts of estimation!
Scrum is more or less the standardized way of working with software development today. But have you seen any problems in your way of using Scrum?
What about:
- Burn-down charts: Maybe your Scrum Master is focusing much on the burn-down chart so you really deliver your points and keep your velocity up.
- Failed or succeed delivery: Maybe you feel that you sometimes succeed and sometimes fail with your planned delivery?
- Cut Quality: Maybe you are cutting tests, reviews, discussions just in order to meet your important deadline (demo at the end of Sprint).
- Planning: Maybe you feel that your discussions regarding estimation takes too long time, and that you spend quite a lot of time on focusing on how you could improve your estimates.
Maybe one, or many, of these listed points are bothering you but you really don´t know what to do about it.
Let me give you one advice in how you can try another approach.
I think that you should talk to your Scrum Master, or your Product Owner, or maybe just another team member to try another way. One small step. Evolution, not revolution!
First Planning Meeting
Ok. Now it is day one in your new Sprint. You have a planning meeting. Your Product Owner has a backlog of prioritized stories that you should work with. Then you could just start with breaking down maybe 4 stories. Discuss, draw, describe what you should be doing for every story. But. Cut the estimation. Don´t estimate the time it will take for every story or every task to be delivered. I really mean it. #NoEstimates for your stories. After this is done, go to your white board again.
Swimlanes
Now put two of your stories up on your white-board. Then you ONLY work with these two stories. The entire team works with those stories. When moving things to ”DONE” column means that it is really done. It is developed, code-reviewed, tested, system-tested and deployed (or whatever your Definition of Done is). Do not cheat just to make your Product Owner happy.
You will probably need one Swimlane for ”emergency” issues, like production-problems etc. But focus from the team should be these stories!
To Demo
A couple of days passes by and you are done with Feature 4(see picture below). Then you just move that story to the ”To Demo” column. And. Now you take the most important story again to your board since you have a free swim lane (in this case Feature 1).
And whenever you feel like there is risk of idling, in other words being done with all your stories, you should have a ”Planning-meeting” (or whatever you want to call it). If your team including your PO is co-located then you can probably take it whenever you want to, when you have the need. If not, then maybe you need to plan the meeting one or two days ahead.
The Demo
Now it is time to Demo for your product owner and perhaps other stake-holders (customers?). And what do you demo? You demo exactly what you have delivered. You don´t say that ”We promised feature 2, but I am sorry we could´t make it”, just because you did NOT promise anything.
And after the demo you have your retrospective as usual and then you start a new sprint. Without promising anything. And when you have done two or more sprints you can evaluate if you want to go back to your old way of handling story points, promising deliveries in 3 weeks and so on. My guess is that you don’t. My guess is also that you tune this way to suite your own needs instead. But I can almost promise you that you will not go back to your previous way of working!
Conclusion
Agile for me is about taking small steps. Many small steps, all the time, to always improve your way of working. Deliver software more often, in smaller pieces, with higher quality. Promise less, deliver more! Above is just one example that you can use to get further on the ”agile road”.