wood burning stoves*
The moose likes Agile and Other Processes and the fly likes Kanban compared to other Process Frameworks and Project Mgmt Methodologies Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Kanban compared to other Process Frameworks and Project Mgmt Methodologies" Watch "Kanban compared to other Process Frameworks and Project Mgmt Methodologies" New topic
Author

Kanban compared to other Process Frameworks and Project Mgmt Methodologies

Joseph Chestnut
Greenhorn

Joined: Sep 10, 2013
Posts: 1
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

Joined: Aug 07, 2013
Posts: 41
    
    5

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").


Hope this helps
/Marcus
http://bit.ly/theKanbanBook
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
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


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
Marcus Hammarberg
Author
Ranch Hand

Joined: Aug 07, 2013
Posts: 41
    
    5

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

Joined: Oct 01, 2001
Posts: 814
    
    3
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

Joined: Aug 07, 2013
Posts: 41
    
    5

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

Joined: Aug 07, 2013
Posts: 41
    
    5

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

Joined: Oct 01, 2001
Posts: 814
    
    3
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?

 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Kanban compared to other Process Frameworks and Project Mgmt Methodologies