Thursday, July 24, 2014

Kanban: Taiichi Ohno quote

As David Anderson notes in his book, one of the best things about Kanban is improvements, continuously getting better.
Taiichi Ohno invented the Kanban idea in the 1950's when he visited Piggly-Wiggly, an American supermarket.  He explains most of this in his book, Toyota Production System.
The book has one short section titled: Kanban Accelerates Improvements.  In that section one reads this wonderful quote:
It is said that improvement is eternal and infinite. It should be the duty of those working with kanban to keep improving it with creativity and resourcefulness without allowing it to become fixed at any stage.
Earlier in the book, he mentions many comparisons between sports and business. He mentions baton passing and rowing, two of his favorite metaphors.  Then he says:
I feel the most important point in common between sports and work is the continuing need for practice and training.  It is easy to understand a theory with the mind; the problem is to remember it with the body. The goal is to know and do instinctively. Having the spirit to endure the training is the first step on the road to winning.
Wonderfully insightful words.  As are many many more comments he makes in this brilliant work.

Question: Building user stories remotely...

Question: Hi Joe! Quick question - what have you found to be the best approach for creating user stories for the team members that are participating remotely? We have a release planning meeting for a group that has three team members in Connecticut and will be dialing in for the meeting. We have go to meeting and webex as options also. Thanks!
I like to simplify and think of two parts.
(1) Initial Agile Release Planning, which is done in roughly one-day, upfront, as a Team plus business stakeholders.
(2) Every sprint, we have Release Plan Refactoring (aka product backlog grooming or backlog refinement.
For #1, really think it makes things much better in the long term to get the team (that whole group) collocated.  Yes, it costs some money, but it pays real dividends.  Your firm really must do that.
Now, I can appreciate that you cannot get them to do that, always.  Or the people just won't do it.  More on that a bit later.
For #2, I recommend 2 week sprints typically.  And if so, then 2 meetings per sprint to do RPR (release plan refactoring).
And I like to do RPR collocated if we can. But here, justifying the time and cost of collocation is not as clear.  So, you might do it 'remotely' as we say.
I do not care much which 'virtual meeting' tool you use.  GoToMeeting, WebEx, and others are very good.  I do recommend that you get at least one person on the call who understands that product well, and knows how to use it well (can make it work quickly) and can explain it well.  And get that knowledge spread throughout the team quickly.
Then, I like to use a story tool.  Again, there are many.  Trello comes to mind.
What do you want?
1. The ability for anyone to write a story, without waiting in line.  This enables a volume of stories to be done in a small timebox.
2. The ability for everyone to *see all the stories at the same time.
3. The ability to re-arrange the stories (in multiple ways) to see patterns and relationships in the stories.  (Examples: 'all in one module', parent-child, 'connected', same role, same department, business flow, etc, etc.)  This visual thinking often leads to more creativity.
I think Trello enables all 3 of these.  Probably other tools do too.  Certainly a physical board can support this.
I would use brainstorming rules for a good while.  Meaning mainly: 'any idea is a good idea; no criticism until later; we need a pile of stuff to work with.'
Related to this, identify to the participants what your goals are.  They include: a pile of stories (volume in a time box), clarity of the stories (although they may be rough at first and clarity may be added later), completeness (of the stories, given the timebox), inventiveness or innovation (something unexpected), learning across all team members, etc, etc.
How big a timebox for this round?  Well, you did not give me much to go on, but I will guess 30 minutes for this round.  Maybe extend to 45 minutes if everyone says they need it.  Set the outer boundary at 1 hour.
Does that help?

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, 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:
  • 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 (, 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.

Courses and Workshops we offer

Here is a list of all the courses and workshops we offer. 

We do these both publicly and in-house.

 Course and Workshop Offerings Ver2

This is not a complete list, but gives an good overview.

We will update this listing from time to time.

Of course we are happy to answer questions.  

Sunday, July 13, 2014

The truth: Scrum is not easy!

May I tell the truth? I am a trainer, and people come to my course.  And often they want an easy answer.  A magic answer that is not disturbing, or bothersome, but is in every way only good and friendly and just better. In other words, they come to change, but they don't want to change.  Well, maybe that brought a chuckle, but that is a bit unfair.  They want to change, but they don't want the change to be hard.  And we all feel that way sometimes, right?  This is human nature and no one's fault.  But... I could say that in a kinder way.  And maybe I should be kinder, but I am blunt.  I am blunt because I do not wish to waste their time (nor mine).  Because life is short. Because they need a kick in the pants.  But mostly, they and the people they serve need to move on to a new and better life.  We need a better life now! And denying them and their customers and us all a better life because some change is a bit painful.... that is not an acceptable answer. I am also compassionate. I see the suffering of their current lives, and I cry inside.  I see all the lost talent, and see all the pretending, and the dishonesty that their current work requires of them. And I cry inside for that. But I only have compassion enough to risk anger with a KITP. (Often friends get mad at us a bit when we give them a KITP, but good friends thank us later. At least for caring.)  Let us be fair too: A KITP (as I mean it here) is not an actual kick. "Sticks and stones may break my bones but words will never hurt me."  When we say KITP, we mean a serious conversation, we mean bluntness.  We do not mean a brutal conversation, we do not mean breaking someone down into tears in public, and we certainly do not mean anything approaching physical violence.  Of course. But, in these days, someone can complain now that you hurt their feelings and it is sometimes treated as a physical felony.  It has gotten a bit crazy. But this issue is not the subject of this post. *** So, why is Scrum hard? Well, the first truth us that Scrum is mostly a lot more fun.  It is, net net, more pleasurable, for everyone.  But it is also painful, particularly in the changing to it. 1. It requires that we try to see the truth, and the truth is sometimes painful.  And we typically often want to look away.  The truth often tells us unpleasant things about ourselves. And Scrum requires us to tell the truth.  And, that can be hard. 2. Scrum requires that we change, that we challenge everything, that we become better than we are now.  And it makes us move from our comfort zone to a zone that feels weird and different and dangerous.  Yikes! *** Should you talk about the truths in the class? Or ignore them? I feel there is no option.  I must tell the truth. But, some say, they are stupid, and you will upset them by telling these truths.  Don't tell them until they ask or at least until later. Is that the way you would want me to treat you?  No, I did not think so.  Yes, it is true that some of them in the class are not ready to make the change.  And, in some sense, if I could identify that and only teach the class to that one person, then I might 'more carefully tailor the course to the needs of the individual.'  But, again, I do not have those options. So, I do many things in the course to help you appreciate how life in a Team is different.  Things are moving fast. You must interact with all of your teammates.  That there is a new speed, a new informality, and directness, and a lack of hierarchy and 'respect'.  A lower 'formality'.  It is not all gone, but it is substantially changed.  And you want it to change.  Except that many of you, in your hearts, at least partly, do not want it to change.  But, in the class, with a thousand small remarks, I force you to feel the change.  People will say blunt things, people will say non-PC things.  The tight lid on all so-called 'bad words' is lifted.  For many people, this is not a problem at all, this is good, this is refreshing, liberating even.  For men and for women.  But for some people, it is very upsetting.  (If I upset you in a serious way, I am sorry.) Am I being mean?  Well, honestly, to some it can feel mean.  And if the pain is reasonable, I am ok with that. Life on a NYC street is a rough and tumble business.  We all get a bit bruised.  And whenever I hear it is painful, I back off in some way.  But some people hide their reactions, and what is humorous to one person can be painful to another.  One never knows. In some classes I get some especially sensitive people, and I back off some.  But, for those few, it is too late. To be fair, one is fairly sure that some feign sensitivity as a way not to change.  People have many ways to seek their goal indirectly.  But, one thinks. no always is this the case. But honestly, if they do not experience rough and tumble with me in a 'safe' environment, it will go much harder for them in a less safe environment. It is tricky and hard for me as a trainer to bring them up to speed with Scrum quickly.  I never do it perfectly for everyone in class.  I focus mainly on those who are likely to really 'get it.'  So, for some I fail or partly fail every time.  I am not happy about that, but it is a price we pay.  Time is short, as many a poet has written.  Later TS Eliot alluded to an earlier English poet, and had Prufrock say "Do I dare to eat a peach?"... a classic description of our current passivity.  We cannot be so passive.  Life is too short, and the opportunity of a better life is too great. So, Scrum is painful, some.  Bear the pain with dignity.  May it be that I am not the bringer of the pain (to you at least, Reader), that I have prepared you for the pain usefully.  And then may the pain be small. And indeed I have always found the pain to be very small compared to the benefit and the pleasure of doing Scrum with a good team.  And the benefit to the customers, and the satisfaction we get from having done something good for someone else, something we may not crow about, but in after years we may look back and be proud of.  

Friday, July 11, 2014

Scaling Whitepaper

We have started a scaling whitepaper.  It will go through many iterations.  Already iteration 4. Getting Starting with ScalingVer0.04 Please comment on how you think this paper should evolve, and which key questions this paper should address. Thanks.

Thursday, July 10, 2014

Impediments - Charlotte Course July 2014

In the Charlotte course, the following impediments were identified.  These came from different people and were expressed in different ways.  I just copied what they said.  So, for example, sometimes a "..., lack of" is implied, I think.
  1. No one knows what done looks like
  2. Missed stakeholders
  3. Poor or non-existent planning
  4. One release per year (mentality)
  5. Technology
  6. Undefined critical risks
  7. Gold-plating requirements
  8. Goals that are not measureable
  9. Modeling for the sake of modeling
  10. Lack of knowledge share
  11. Not a clear defined deliverable
  12. No client involvment
  13. Multitasking
  14. No capability to deliver
  15. Lack of collaboration
  16. Dependent on other projects
  17. Decreased motivation to change
  18. Adversarial position with S/W vendor
  19. Lack of S/W vendor participation
  20. Leadership
  21. Interruptions
  22. Technology change
  23. Unrealistic expectations
  24. Not enough money
  25. Lack of commitment
  26. Unrealistic timeline
  27. Management override
  28. Requirements not defined
  29. Low morale
  30. Budget
  31. Communication
  32. Not enough resources [He might have meant people.]
  33. Single point of failure
  34. Scope creep
  35. Changing requirements
  36. Wrong people
  37. Lack of teamwork
  38. Not enough people assigned
  39. Missed requirements
  40. Lack of communication
  41. Did not plan budget properly
So, that is what they listed.  Many duplicates were not listed twice.  The number do NOT indicate a priority order (numbers are just added to add reference). Some of them were what each attendee felt was his team's biggest impediment today. Let me make a few quick recommendations on impediments.
  1. Impediments can be anything that slows down the team.  Anything.
  2. All the impediments go into one public list.  The one impediment that is slowing the Team down now the most goes to the top of the list.  Consider benefit-cost analysis in prioritizing, etc.
  3. Some impediments can't be fixed, but any impediment can at least be mitigated (have the impact reduced).
  4. The Team should prioritize them, but often will not agree.
  5. Fix the top one, one at a time.  See Theory of Constraints, for example.
  6. Slice your fixes into small things, so that noticeable improvement can be measured each Sprint.
  7. Although the Team has become numb to many old impediments, re-awaken their senses to the 'we have always done it this way' kind of impediments.
  8. Give the Team a challenge, to identify impediments we can fix that will double the Team's productivity.
  9. Never, never, never, never stop getting better.
  10. Recognize the value of a SM who aggressively attacks the impediments.
  11. Impediments can be fixed by the SM, by the Team (or team members), and by people outside the Team (including people outside the company).