• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Kanban and Project planning

 
Sheriff
Posts: 5555
326
IntelliJ IDE Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Author
Posts: 41
5
Mac OS X Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 https://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.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 41
5
Mac OS X Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 41
5
Mac OS X Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
看板 = 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
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think KANBAN makes planning process visible, adaptable in the way that traditional project planning process can not offer.
 
Marcus Hammarberg
Author
Posts: 41
5
Mac OS X Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 883
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Burk Hufnagel
Ranch Hand
Posts: 883
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 https://coderanch.com/t/619683/Agile/Kanban-individual-status#2830539

Burk
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic