Saturday, July 19, 2014

Kanban - Love It. Why?


I have been working on Kanban lately.

 I love the Lean ideas.  There is so much there we still need to understand better and do.  And, interestingly, the ideas are counter-intuitive to most people, and yet obviously simple and powerful when you actually take some time to do them.

The one sentence version (hugely over-simplified): For most people, I would recommend Scrum-Kanban, as where they want to get to.  Or, maybe better to say: Lean-Agile-Scrum.

But let's stick to a smaller topic today.

One of the great things about Kanban is that you can do it for so many reasons.  I started to make a list of them all.  Here is what I came up with:
  1. Maximize business value to the customer
  2. No more death marches
  3. Eliminate burnout
  4. Faster delivery (shorter lead times)
  5. Higher quality
  6. Lower cost
  7. Easy to implement
  8. Manage things in our control
  9. Start to see what is going on - at least…
  10. Scrum is not working, so then what?
  11. A way to get minimal control, a place to start
  12. So we can disconnect from the business side (we have no PO)
  13. Start finishing! (Stop just starting)
  14. Minimize WIP (for all of its benefits)
  15. Allocate people to work
  16. Fix the biggest constraint
  17. Measure lead times
  18. Adapt to changing work items faster
  19. So the process is minimal (we get to have almost no ‘process’)
  20. So that the process does not get in the way, and can be adapted to our specific situation
  21. To enable team learning
  22. Gain some slack in the system
  23. Get space (slack) to make improvements (Kaizen)
  24. Build trust through frequent more frequent releases

I stole some of these ideas from Henrik Kniberg, Mattias Skarin, and David Anderson.

Only one of those goals do I not like.  #12, which is in italics.  It might actually be necessary in a few real cases, but still I do not like the idea. But, I do think people use Kanban to do that.  There is a second phrase, also in italics, that I worry about. A process should be as simple as possible, but not simpler.  Put another way, the tool(s) must be big enough for the job.  Some people who use Kanban do not add enough to it, IMO.  So that the 'process' is too simple to be professional for their situation.  Again, IMO.     -- Just to make clear...with my personality type and other characteristics, I generally dislike 'process.'

Also, Kanban, like anything else, is not a silver bullet.  It cannot 'give' you these results.  But it can help, and indeed help a lot if you and the group are skilled, hard-working, professional, etc.

More on Kanban later.  A wonderful subject.  

Scaling with Agile: A Patterns Approach


I will be speaking to the Agile CoP of the PMI in Nashville.  Lots of interesting things happening in Nashville.  And very nice place.

 Here is the title of the discussion: A Patterns Approach to Scaling in Agile/Scrum.

Here is the description:

An introduction to some concepts for scaling in Agile/Scrum, and how to use them effectively to bring value to your organization.
  1. Definition of scaling and topics related to scaling.
  2. Implementation of scaling in patterns.
  3. Implementation of scaling iteratively and incrementally.
  4. Discussion of standard scaling patterns.
  5. Discussion of ScrumPLOP.org, LeSS, SAFe, etc
We will review all of this quickly, in 90 minutes, including Q&A. It is kind of a condensed version of our workshop, except it lacks most of the workshop aspects.

If you are interested in this topic, you may be interested in our Whitepaper on Scaling: Getting Starting with ScalingVer0.04

Looking forward to discussing these ideas in Nashville.  I am sure they will have some great questions.  

Southern Fried Agile Proposed Topics


Some of you may find interest in the topics I proposed for Southern Fried Agile.  I may or may not 'get' any of these....
  • Culture, Change, Scrum: What we can do about it
This is an evolving topic for me.  I spoke on this same basic topic last time, and people seemed to be pretty interested.  This time it will be different. My plan may vary, depending on which other speakers come (for example, if Mary Lynn Manns comes). My current plan is to focus mainly on two sub-topics: what is culture and how to use Open Agile Adoption. Here is my current 'extended' slide deck on this subject: http://www.slideshare.net/jhlittle
  • A patterns approach to Scaling
I will describe why I prefer a patterns approach to scaling.  That is, why I do not prefer a monolithic approach, but rather prefer to do scale iteratively and incrementally. We will discuss some key terms associated with scaling. We will discuss the logic behind using patterns. We will review the basic and classic patterns for scaling. We will discuss the main sources for patterns of scaling (ScrumPLOP.org, SAFe, LeSS, etc.) Most importantly, we will discuss how you can take action on these ideas on Monday.
  • Agile Release Planning: One approach
This is an important topic for virtually every team.  How to do the initial Agile Release Planning (usually covering more than one release). In this short session I will describe one simple approach that addresses many issues. One the key thing:  this approach has different main goals than what you probably expect.  It's main goal is to change the people -- get them on the same page, get them motivated, get them to share the tacit knowledge (or 'negative' knowledge) they already have about the work, and share that with the others involved in the work. In the session I will quickly describe the main steps I use, and also some detailed techniques. We will also discuss Release Plan Refactoring.  This is similar to what many people call Product Backlog grooming or Backlog refinement. Due to the timebox of this session, we will touch very quickly on how to do this in a scaled environment. I hope this will be an interactive session for a relatively small group, so we can discuss this very interesting topic. This topic is related to my book, Joe's Agile Release Planning. *** I can probably arrange to speak on these topics at your company or at your user group.