my dog learned polymorphism*
The moose likes Agile and Other Processes and the fly likes Kanban and Project planning 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 and Project planning" Watch "Kanban and Project planning" New topic
Author

Kanban and Project planning

Tim Cooke
Bartender

Joined: Mar 28, 2008
Posts: 1055
    
  51

Hi Marcus and Joakim,

I was talking with our in house Agile Coach earlier today and mentioned to her that you guys were here this week to discuss your book and Kanban in general. I myself am no expert so instead of asking my question which would be along the lines of "What's the deal with Kanban? I know nothing about it!", I thought I'd put forward one of her comments for discussion.

Her main question is this: "Why is Kanban allergic to planning?". Somewhat tongue-in-cheek but she goes on to qualify this by saying that in her experience, Kanban works quite well for projects where there is an existing product and the team is tasked with maintenance or adding new features. Where she finds Kanban does not work too well is with new projects that have a finite lifespan. For example if a team were tasked with writing a mobile app for something or other for x months and then stop, she feels that Kanban doesn't really provide an efficient approach for the initial planning and setup phase.

What are your thoughts on this?

Regards
Tim


Tim Driven Development
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4474
    
    6

My 2 cents: Kanban works well when your team has a level of maturity where they can chunk work out into reasonably same-sized pieces or if they have established a relatively smooth flow of work such that WIP can be reasonably used as a predictor of the team's output. With new projects where a flow has not been established and there are still many unknowns both from the users' perspective as well as the developers' perspective, the work completed in the past may not be a very good predictor of the work that can be completed in the upcoming weeks.


Junilu - [How to Ask Questions] [How to Answer Questions]
Marcus Hammarberg
Author
Ranch Hand

Joined: Aug 07, 2013
Posts: 41
    
    5

Hi guys,

I've used kanban on a lot of teams, in a lot of settings. Some have been VERY inmature and at Spotify and my current client Tradera (Swedish Ebay kinda) I've met some of the most advanced teams I've known.

The tounge-in-cheek-question has a point, but I think it more has to do with what people read into the concept of kanban. As I wrote earlier (see http://www.coderanch.com/t/619628/Agile/Kanban) kanban is just 3 simple principles and the main goal of kanban is to improve your process. This is great news since that means that we can start today - right were we are, just as we work. You don't have to change a thing. Just:
- Visualize your current process
- Limit work in process
- Help the work to flow faster and smoother from start to finish

and see where it takes you. I've successfully used this approach to improve very old school waterfall-ish processes and teams.

A lot of people read in a lot of other things in kanban, but that's not really the case. Many practices has, over the years, become standard but it doesn't have to.

Back to the "Allergic to planning" (great quote btw, tip of the hat to your friend): kanban is not allergic to planning, but the planning is done in smaller chunks. And often when it's needed rather than at a given timed interval. One simple practice that I like is to have something called an Order Point; when we have 3 items left in the Todo-column we call the product owner (or customer or whatever) and say that we need more work.

In that way we pull new work to us just-in-time rather than plan up a lot of work onto a waiting list, just-in-case. We become more agile and can change easier.

Hope this answer your question and helps you. And your friend.


Hope this helps
/Marcus
http://bit.ly/theKanbanBook
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4474
    
    6

Marcus Hammarberg wrote:when we have 3 items left in the Todo-column we call the product owner (or customer or whatever) and say that we need more work.

In that way we pull new work to us just-in-time rather than plan up a lot of work onto a waiting list, just-in-case. We become more agile and can change easier.


By the same token, would you use a certain # of items left in the TODO column to trigger planning for a release or do you typically wait until items have fully crossed over to the DONE column? I supposed either way would work but what has been your usual practice to plan for a release?
Marcus Hammarberg
Author
Ranch Hand

Joined: Aug 07, 2013
Posts: 41
    
    5

Yeah, you're right. It's pretty much up to you, and either of the proposed ways could work.

I've seen a number of different approaches ranging from "put every finished item into production as soon it's done" (aka Continuous Delivery) to "this is the 52 items we need to have done before we release".

Generally speaking I urge team I coach to produce what's known as "potentially shippable product increments". (stealing from Scrum here). This means that if we could we would put this into production. There might be reasons to wait (technical reasons, marketing or us waiting for other teams to mention a few) but our mindset is to treat every item as if it would go straight into production. That is Done.

At my current client they make distinction between Deployed and Released. That is: Deployed means that it is on the production servers, but not used by users (or at least not everyone). Released means that we've released it to everyone. We deploy every change, but release when we have something that we think is useful to customers.
JOSEPH BIH
Ranch Hand

Joined: Jul 08, 2001
Posts: 44
Marcus/Joakim

I am an Agile Practitioner. And I am very glad to see your book on Kanban. It provides lots of insight into a simple yet powerful and effective software development practice. Born in the East culture, I embrace Kanban naturally. This word 'KANBAN' in Chinese character literally means "Watching on the Board", that tells a lot something (sticky notes) on board needs attention. This KANBAN, accessible/visible to the working team, is a powerful tool for a small workshop to keep tracking WIP (work done in process/progress), reducing any delay in process, bottleneck and such to a smooth, efficient delivery of high quality finished product. In an age of rapid change, software development process cope with challenges as business and technologies evolves, this approach can be a excellent tool to keep entire team well informed, best assuring value deliveries to customers/clients.
Marcus Hammarberg
Author
Ranch Hand

Joined: Aug 07, 2013
Posts: 41
    
    5

Hey cool!

I only knew the Japanese translation which is; "kan" = visual, "ban" = card.

Ok if I put your Chinese translation into the book too?
JOSEPH BIH
Ranch Hand

Joined: Jul 08, 2001
Posts: 44
看板 = KANBAN, borrowed from Chinese character and meaning too. 看 means watch, look, see, visit. 板 means board, can be blackboard, whiteboard, writing-pad to put, lay on, hold on things. I think the Japanese still uses the original Chinese character. This is only one instance, there are many. Japanese language borrow many other language characters too, e.g. Roman, English, Russian and etc. You can see this culture embrace others' good, and open learning attitude. Good and hard part is that they integrate as their own unique culture eventually and innovate, produce high quality results.

That's why I say a simple yet powerful tool!
JOSEPH BIH
Ranch Hand

Joined: Jul 08, 2001
Posts: 44
I think KANBAN makes planning process visible, adaptable in the way that traditional project planning process can not offer.
Marcus Hammarberg
Author
Ranch Hand

Joined: Aug 07, 2013
Posts: 41
    
    5

I cannot agree more!

You cannot improve what you cannot see!
Let's make stuff visible!

Think about this: how do your coworkers know that you have loads to do? That you're on a roll? That you need help? What you have accomplished the last week?

All of this can, and should be visualized to improve communication and help you improve!
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Junilu Lacar wrote:My 2 cents: Kanban works well when your team has a level of maturity where they can chunk work out into reasonably same-sized pieces or if they have established a relatively smooth flow of work such that WIP can be reasonably used as a predictor of the team's output. With new projects where a flow has not been established and there are still many unknowns both from the users' perspective as well as the developers' perspective, the work completed in the past may not be a very good predictor of the work that can be completed in the upcoming weeks.

To be fair, I think this is true for any agile methodology and for most non-agile planning methods too. It's not limited to Kanban.

Burk


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

Joined: Oct 01, 2001
Posts: 814
    
    3
Marcus Hammarberg wrote:Think about this: how do your coworkers know that you have loads to do? That you're on a roll? That you need help? What you have accomplished the last week?

Marcus,
This statement bring up a question in my mind - I'm going to post in a separate thread so this one doesn't get hijacked.

Here's the link http://www.coderanch.com/t/619683/Agile/Kanban-individual-status#2830539

Burk
 
GeeCON Prague 2014
 
subject: Kanban and Project planning