Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Kanban compared to other Process Frameworks and Project Mgmt Methodologies

 
Joseph Chestnut
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I was curious to understand thoughts on when Kanban is a good choice.

For example, when selecting a project management or process framework from traditional, agile, or extreme project management methodologies one might consider how known and repeatable the work is ( in terms of team experience and understanding of requirements ). Well understood low volatile requirements combined with team experience with repeatable process lends itself to traditional project management techniques (according to academic texts anyway) . On other hand, the higher level the requirements and the more unknown and new the work it, the more agile methodologies like incremental and iterative tend to be recommended. And at the end of the spectrum in R&D environments, extreme project management is said to fit the bill.

Where/how does Kanban fit in on that continuum and why?

Thanks for any thoughts!
 
Marcus Hammarberg
Author
Ranch Hand
Posts: 41
5
Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Great question!

I love the ending "Thanks for any thoughts"! I can't miss

Kanban don't really say much about that but I think it's more of a generic question about how our work varies in size and complexity. For most software development projects I've come across there a large unknown factor in the outset of the project and we want to learn as much as possible about what we don't know yet (for more on that see this excellent video with Dan North: https://vimeo.com/43603453). The further we come along the project it more and more comes to just filling out the blanks.

I can see kanban support both those cases. Kanban is a tool for process improvements and helps us improve the flow of work (items) through any process. When we have a lot of exploring to do we might timebox the work items and say things like "This work item card represent us exploring requirement X for 5 days". After that we can decide if we need more exploration or if we have learned enough to feel that we have a grip on the risk involved with requirement X.
At the other end we can start to have a very predictable and stable process, so that we can say stuff like: "This is classified as a Small work item. They usually takes 2-3 days. Medium takes 3-8 and Large takes 5-20 days".

Kanban will help you by visualizing your work ("Why does all the stickies pile up in the test-column?", "Every work item from Team B always takes twice as long to complete" etc.), limit work in process to get faster flow ("should I pick up a new or help finish ongoing work? If I pick up new work I'm breaking the WIP limit so I better help out instead") and help work to flow ("Team, let's experiment with not accepting X-Large work items anymore, but instead find a way to slice it up into smaller items").
 
Burk Hufnagel
Ranch Hand
Posts: 814
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marcus Hammarberg wrote:Kanban don't really say much about that but I think it's more of a generic question about how our work varies in size and complexity. For most software development projects I've come across there a large unknown factor in the outset of the project and we want to learn as much as possible about what we don't know yet (for more on that see this excellent video with Dan North: https://vimeo.com/43603453). The further we come along the project it more and more comes to just filling out the blanks.

I can see kanban support both those cases. Kanban is a tool for process improvements and helps us improve the flow of work (items) through any process. When we have a lot of exploring to do we might timebox the work items and say things like "This work item card represent us exploring requirement X for 5 days". After that we can decide if we need more exploration or if we have learned enough to feel that we have a grip on the risk involved with requirement X.
At the other end we can start to have a very predictable and stable process, so that we can say stuff like: "This is classified as a Small work item. They usually takes 2-3 days. Medium takes 3-8 and Large takes 5-20 days".

Marcus,
Sounds like a team might have two or more kanban boards during a project, or keep the same board, but change the columns when the process changes significantly. Is that what you're saying here?

Thanks,
Burk
 
Marcus Hammarberg
Author
Ranch Hand
Posts: 41
5
Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, the board is a living thing. It should change, when we do.
And we improve by changing.

So we might start out with two separate boards, then merge them with swim lanes to finally end up with two boards again. Or end up with just one board without swim lanes.

The end state cannot be predicted nor should it be. It's the journey that make us better.

PS
This is one of the reasons I often recommend against electronic boards, since they might constraint how we can evolve and change the board. They might not but just the risk of that have me shy away from them
DS
 
Burk Hufnagel
Ranch Hand
Posts: 814
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marcus Hammarberg wrote:This is one of the reasons I often recommend against electronic boards, since they might constraint how we can evolve and change the board. They might not but just the risk of that have me shy away from them

Marcus,
I understand that concern, but I wonder if there's a better solution when you're working with a team that's spread out geographically. Any suggestions?

Burk
 
Marcus Hammarberg
Author
Ranch Hand
Posts: 41
5
Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, not really.

If you're distributed then you might be at a loss.

That said... I've gone through GREAT lengths of not using electronic tools even for distributed teams: http://www.marcusoft.net/2012/10/improving-presence-of-remote-worker-in.html

Don't let the tool constrain you. That's all I'm saying. Often we (IT-people that is) search for a tool and then stick to it. Sometimes that constrains us.


 
Marcus Hammarberg
Author
Ranch Hand
Posts: 41
5
Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bah! Forgot my last sentence.

You know what the first question after a kanban presentation ALWAYS is?

"Is there a tool for Kanban boards online?" It's about 98% of all the presentations i've done.
Check the questions in this forum as well. First or second question was about tooling.

It's a sickness in our community to look to tool. The tools are great but we don't want to be slaves under them.

</toolRant> :P
 
Burk Hufnagel
Ranch Hand
Posts: 814
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marcus Hammarberg wrote:It's a sickness in our community to look to tool. The tools are great but we don't want to be slaves under them.

</toolRant> :P

I agree. I suspect you've seen another problem too. People who start using an electronic board without really understanding the Kanban process. They create a few cards, move them around a bit, and wonder why they're not seeing the benefits you promised them. Does that sound familiar?

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic