Development and maintenance should be done by the same people, it should not be divided and conquered. Why? It’s one product/system! After the first release (it’s all about TTM, isn’t it) you have maintenance, but you’ve only finished a small part of the product. From then on, it’s development AND maintenance, after just a month or so. Still, maintenance, dealing with support, defects and stability, is more variant than development. IMO, scrum is great for development, kanban is great for handling maintenance and variants, and the suggestion in this post is to combine them. Say, if you had 3 teams, would 2 scrum teams and 1 kanban team, rotating each iteration, be a good solution?
This post is in part an answer to Geir Amsjøs blog post and comments at Geir’s smidige hjørne (norwegian only) ITIL – et gufs fra 90-tallet (reads: ITIL – a gust from the 90s), but mostly it’s a post inspired by the problem, trying to find other solutions to the development and maintenance. ITIL is about maintenance, but I will not tell you more about it (check Geir’s link and look at the process diagram) as some stuff can’t be refactored or modified, it just have to be identified as what it is, waste, and handled accordingly.
I greatly appreciate Geir Amsjø, even being Norways only certified SCRUM Trainer, his mindset is not limited to fitting everything to SCRUM. Well, that’s my impression at least! Geir has written alot of great articles about scrum and software development in general.
I’ve been working with scrum since 2006 and have a lot of good and bad experiences with it. My goal is to be agile, delivering business value as first priority, rather than following a detailed plan. It’s all about failing fast, acknowledging that one do fail a lot! Or is that only me? I’ve experience that SCRUM might help me being more agile, done the right way, and what I like best about it is the way it focuses on people working together as teams. I suppose SCRUM is fairly familiar to most of you, and maybe you know or have read about KANBAN too.
My understanding (wishful thinking) of what KANBAN is, is:
- continuously prioritized queue (of tasks. Might be user stories). SCRUM is at best weekly, more often monthly (please understand why this is bad)
- continuous deployment
- applying what works for you (daily standups, retrospective (this is a must) )
Here’s my go at illustrating KANBAN for software development and maintenance:
Actually, the continuous deployment part is so incredibly agile that it will identify an extreme amount of waste in your process, architecture and people/roles that this should be the goal in its own.
As a side not, I suppose you know quite a bit about SCRUM and KANBAN already, I’m not going to explain each element, only stating the main difference: SCRUM is iterative, while KANBAN is flow (continuous). KANBAN may be implemented many ways (hence it is doomed too fail as well when becoming mainstream) and my own understanding of the details is surely to change in the future, so think for yourself and don’t take it all literally. Nice!
What about KANBAN and SCRUM, combined?
First of all, assume SCRUM works really well for software development. That you don’t want to throw away SCRUM just yet (and you probably shouldn’t). Too me, scrum is great at building great teams, done the right way (sadly, I don’t often see it being done right). The team commits, the team fails, or the team succeeds.
In a lean perspective or systems thinking, you need to consider the bigger picture. Talking about software, this certainly does involve maintenance too! I feel SCRUM handles this poorly. Well, there are many (SCRUM) solutions/proposals to this. Some people creates a pot for support task up front, say 20%, but as defects are variant, they introduce unpredictability to a team, affecting commitment and be counterproductive to what I feel make SCRUM good. In my opinion! Others would just focus on development, leaving maintenance to others, which is like closing their eyes!
The way I see it, is that its built upon weekly or monthly waterfalls (V model), as KANBAN is hourly or daily waterfalls, exaggerating of course, bear with me! What does experience teach us? Different tools for different problems, there’s no silver bullet!
OK, to the point, best explained through an example!
3 teams, 2 SCRUM teams and 1 KANBAN team
Wouldn’t it be interesting to run such an experiment? How would I organize this:
- Rotate the members each sprint.
- Each developer should be part of the KANBAN team every third sprint!
- The SCRUM teams focuses on user stories and features, no “support pot”
- The KANBAN handles support and maintenance.
- Developers will better understand what they are making, why, and how it is being used.
- Eliminating failure demand (Leading Lean Software Development)
- High responsiveness yields happy users and customers (yields profit?)
- Better quality
- Both SCRUM and KANBAN teams holds retrospective and implements whatever method they think will be good (as standup, whiteboard architecture, pair programming)
- Product Owner, right people to continuously prioritize the queues.
- Prioritizing (continuously) might be THE most effective improvement to any project. This work is extremely important!
- The continuous work on prioritizing and working on the backlog will improve the sprint backlog for the teams too, as an extra benefit (I’ve experienced that this is part of SCRUM that most often result in it all failing. It should not be taken lightly).
- source control, versioning
- task dependencies
The latter first, task dependencies. The tasks of the KANBAN team cannot depend on a task being completed by the SCRUM team.
Being all agile and whatnot, the obvious choice is using git, hehe.
Said in one line: As the KANBAN team continuously deploys to production, as each defect or such is done, the SCRUM team should merge it into their code.
Said in pseudo code:
for each time the KANBAN team performs 'git push prod' do for each SCRUM Team do 'git pull prod' (into devbranch) for each SCRUM team member, when sharing code do 'git commit ...', then 'git push' (into devbranch) at end of sprint, push devbranch into prod
Hope this was somehow understandable, not to satisfied with this one.
As Mary and Tom Poppendieck states. Failure demand is WASTE. Eliminate failure demand! Understanding the failures one introduce is essential in order to not produce them to begin with. Having the developers, rotating as being part of the KANBAN team, take the support calls themselves, fixing defects at once, will make them understand both the needs of the users (customers), and what code quality is all about. Why not only have KANBAN teams? If you truly believe that SCRUM is well suited in creating a winning culture, that is, wanting to commit to delivering as much as possible, repeatedly succeeding with it, you are greatly increasing your chances for success.
Why not trying to extract the better from the two methods?
If you’d like to try it out, remember that I’m a contractor, sign me! :) While being an agile coach, I’m a developer at hearth! I spend most my time programming, experimenting and improving. I would love to work with reflective people with a vision.