I joined Twitter June 22, 2010, so, needless to say, I was not an early adaptor. Nevertheless, I just passed 500 tweets, and most of my tweets are somehow related to agile development, so did I come across something useful? The answer is yes, and I believe it’s an appropriate time to reflect – focusing on Kanban and Scrum this time.
During this period I’ve learned to enjoy Lean thinking, and Kanban in particular. The difference, you may ask? David Anderson puts it well:
“People ask me what is the diff between Lean & Kanban? Answer: Lean is a destination, Kanban is a means to get there.”
If you don’t know Kanban, here is a clean and to the point overview:
http://reaktor.fi/en/our_expertise/kanban/
And here is a first hand experience on what you can expect if you introduce it:
http://www.agilecoach.ca/2011/07/07/kanban-reboot-pt1
It’s not always easy to map a process to the Kanban board, so you might need some tips when you are stuck:
http://blog.brodzinski.com/2011/08/map-process-to-kanban-board.html
After a while, you will know that keeping an inventory is not free of charge, and there might be an upside if you manage to keep it down:
”In 1987, while GM held 2 weeks of parts in inventory, Toyota held 2 hours.” (Jeremy Lightsmith)
By then you should know that you need to pull work items, not push them. This strategy, if you see the analogy, might even affect your leadership:
“Management is push, leadership is pull.” (Jim Benson)
…and what’s really the difference between a project leader and a project manager?
http://www.projectsmart.co.uk/project-leader-or-project-manager.html
Kanban takes an evolutionary approach, so big changes won’t happen overnight, but you should still be prepared for resistance in the organization. Here are 5 arguments against Kanban – and how to respond to them:
http://noostvog.wordpress.com/2011/06/29/5-arguments-against-kanban/
Even though I find Kanban very appealing, I still like Scrum. Recently, Scrum even got a major update to the Scrum guide! I found it really interesting that they now had removed release planning, cause it might compensate for poor development practices:
http://www.scrum.org/scrum-guide-updates
This doesn’t mean you have to stop all release planning, it’s just not mandatory anymore, and you should use it with care. This is an example of one small step you can take to improve the quality.
And quality, that’s what you need to focus on, no matter what agile process you are using. If you shorten down the feedback cycles, that would help you on the way. To get fast feedback, there’s a number of things you might consider:
…shorten the iterations:
http://www.itjoblog.co.uk/2011/06/the-iteration-is-too-long.html
…keep the releases small and deploy to production often.
http://kenschwaber.wordpress.com/2011/03/23/major-releases-are-a-failure/
…but maybe not 50 times per day?
http://www.thehackerchickblog.com/2011/02/continuous-deployment-for-continuous-learning.html
If you want to go fast, you need to move with a sustainable pace. You need to stay clean so you can keep going fast:
http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot
So, to be able to shorten the feedback cycles, you need to focus on getting working software at the end of each sprint. And if you don’t, you’re definitely not alone. Over 50% of Scrum teams can’t get shippable code at the end of each sprint. Research shows that this will slow you down between 2 and 24 times:
http://scrum.jeffsutherland.com/2011/01/optimized-scrum-getting-to-done-done.html
There are many topics I didn’t cover this time, so maybe there is room for another post?
Disclaimer: This blogpost was originally published on a different platform. Formatting may be incorrect, links may be out of date.
Jørn Hunskaar 