Sunday, August 24, 2014

Agile Release Planning workshop - Comments

I have many comments to add to the blog, and many topics to discuss.  Let me start with this one.
Last week we had another Agile Release Planning workshop, in Montreal.  (We do one almost every week.)  The workshop is mainly about taking a real set of work (about 6 months of work for one team), and doing real agile release planning.  This is explained in this blog, and at LeanAgileTraining.com (for any specific workshop), and in my book, Joe's Agile Release Planning.
First, most everyone in the group said 'this is the best' or 'this is when it all came together'.  These are frequent comments from the workshop.
Today, let me talk specifically about Serge and his team, which were all from one company.
They took a brand new set of work, which the company has to do soon, and planned it out.
It was so good that Serge took the release planning information (the product backlog, etc, etc), back to the office.
***
They had two issues that struck me.

One:

They are used to developing the backlog in isolation from the Team, by one or two people.
And, to be fair, many of the people in the workshop were not members of what will be the real team.  Still, I think Serge started to see the value of creating the backlog with a Team.  And the team members did too.
And, later, all the individual detailed work could be done.  Research, cross-checking, etc.  So, the difference from what they used to do (have 2-3 'experts' develop the initial product backlog)....the difference ends up being mainly timing.  Now, the Team (with business stakeholders) does it first, and then the individuals can work on it later and make it better.
Why is this better?  Well, several reasons.  I will list two.
1. It greatly reduces the time before we start 'real work'...I'll call that real work 'writing code'.  And with code we can get feedback from 'the real world.'  So, instead of waiting 3 weeks before we can 'start', we can start the next day (well, honestly, usually it takes a few days more).
2. It enables the Team to have their hands in at 'the creation.'  This has two benefits.  One, it gets their creativity involved.  One consequence is that some of the 'missing' stories are identified now.  Two, it changes their motivation.  They no longer get the mushroom treatment.  And they start to see, by working on it, how all the pieces fit together.
The only downside is, this is a change, and to some degree some people may resist, and you have to explain it to them.  But I have always gotten people to do it fairly well the first time.  (Can you alone get them to do it the first time?  Maybe not.)

Two:

How to do Priority Poker?
In this case, the company has few 'business stakeholders' who will show up.  It is a small company, and one of the people who 'should' show up and do this is the CEO.  But he does not have the time.  And there is a sales person who also has some good insights, but who might take the Team in 'his own direction' ... we will say it that way.
And, Serge is right -- this is not ideal.  And, getting really good business stakeholders is hard and has problems.  Almost always, at least to some degree.
Still, we can get the ...well, best people we can get.  And then use the poker cards to vote, and then average the answers.  And put business value points on each story.
And, as is always the case, we will feel and in some sense know, that this is not perfect.  Except that, the BVPs are the best guesses by the best people we can get to do this at this time.
And then we can do things to improve the numbers.  Starting the next day, maybe.
One obvious thing in this case: Take the product backlog with the BVPs (business value points) and show them to the CEO, and then get his opinion.  And often he suddenly says something like "wow, I wish I had been there...I want to be there next time....but let's change the BVPs on these 10 stories."  And you realize that for 40 out of 50 stories, the CEO is agreeing we did a good job, and he is 'only' changing 10 of the stories.  And usually by not really that much.
AND...the exercise and the numbers enables the CEO to realize that he should act differently with the Team.  The information becomes evidence that causes him to change his behavior.
Well, I do not know that with these numbers and this CEO this has happened this time, but I do know that it can.  With the right CEO and with the right advocate.  (It may be that this CEO really really is too busy, for example.)
***
I hope these key observations (for me) also lead to useful thoughts and actions for you.
If you have questions or comments, please speak up (below or via email).

Saturday, August 23, 2014

Scaling Workshop - New thoughts

David Muldoon and I just had a new Scaling workshop in Montreal.  Two days talking about scaling, and solving problems.

One quick observation

Scaling is ugly.  That is, scaling is always a compromise.
We talked about the ideal state; what would we ideally want things to be like.  One way of expressing part of that: We want to have 5 teams (of 7 people each) work together in such a way that 'everyone knows everything', and we are completely in sync from top to bottom.  And we want this communication to happen at zero cost and in zero time.  We want this because we want to work fast and effectively and with high quality. ...Of course, this ideal state could never exist, but at least we see the trade-offs more clearly.
First, we hope we get that in a single Scrum team, and if we play Scrum well, I think we can.  It is hard, but we can, in a pretty reasonable way.  Yes, not at zero cost, but at a very reasonable cost.
But to get this with 36 people (including the Chief Product Owner) is hard.  There is an additional communication overhead, and we almost always start leaving people out of conversations.  In part, because it is so messy to have a conversation (or meeting) with more than 7 people.
What is the overhead to scale?  Well, honestly I have not looked at the data in a while, and I think we need better data, but I think the cost is quite high.  10, 20, maybe 30% of productivity is lost.  Very likely more.  In any case, we have to be honest....with scaling more of the raw energy of the people is dissipated 'into thin air' as we might say.  We have to accept that, but we also want, within reason and in the context of other values too, to minimize that dissipation of energy.

A second thought.

Each scaling situation is different.  I was again struck by this.  Yes, some of the problems are similar from one situation to the next, but the solutions you need to bring are different, at least to some degree.
For example, in one situation, a company is trying to rebuild a large legacy core system (a huge payroll system).  The original system took, they think, 5 years to build with many people.  The problem: How to take 5 teams and rebuild it in 2 years, and deliver it incrementally over those two years (in part, to mitigate the risk of a big bang delivery).
In another situation, the problem was different.  Here we had a growing company that is innovating, and changing.  How do we get evenness of flow so that the 3 'departments' (or areas)....Inception, Build, Transition each have an even amount of work to do.  In such a way that the highest Business Value stuff is delivered quickly to customers, no matter how big each release might be.  By inception, they meant identifying good idea sufficiently to move to Build.  Build meant, in simple terms, coding and testing and getting to a minimum viable product that was done, done, done.  Transition meant taking a (newly built) product and delivering and installing it at many (say 35) customers.
Describing how the solutions for these two situations were different is too much to address today.  But the first thing is to recognize how different the problems are.

A third thought.

Implementation is key.  We must implement scaling iteratively and incrementally.  This was clear to everyone, and clear in all situations.  The full meaning varied, eg, because of the different political situations, from situation to situation, but that we should, indeed must, implement scaling iteratively and incrementally was clear.
Why?  One was the cost and the related approval for each part.  For example, in one situation, it became clear that each of the 5 teams needs a Product Owner and we need a CPO 9chief product owner).  But, they only have one PO now (for 3 teams).  There is no 'open requisition' for 5 new POs.  So, the feasible way to implement this was: add one PO now.  A bit later, get approval for another PO.  And so on.
Another reason.  Whenever you add something to scaling you must get them, and usually to some degree 'all of them', to agree to the change, to change, and then to learn how to use the change effectively.  It is easier for 'all of them' to agree to the changes iteratively and incrementally.  The changes are easier to implement iteratively and incrementally.  And you can manage the process of becoming professional in the use of each change better if each change is fairly small. (There are other factors, depending on the situation, but one of the bigger risks is with a 'big bang' implementation of scaling changes.

A fourth thought.

I continue to learn about scaling.  I think we all do.
Slightly related to this: We have or should have a strong bias toward KISS.  Keep it stupid simple.  Keep it maybe somewhat simpler than it 'needs to be'.  Why? Because we have so much complexity already that we are almost stopped in our tracks, and the more complexity we add to the scaling part, that complexity makes things harder by itself.  What do I mean by harder?  Communication is not as good.  We get confused.  Everyone in the scaled group does not understand how we are scaling well enough.  Hence, the do not use the official scaling effectively, and resort to doing nothing or to doing it in a personal or informal way (which often can run counter to what is happening in official channels).
But back to the learning. Let me give two examples.  My colleague Dave has a bias toward 1 week sprints, and I have a bias toward 2 week Sprints.  Maybe better to say: I think getting most teams to do 1 week sprints well is harder than getting them to do 2 week sprints.  And that 3 or 4 week sprints are only rarely good ideas (ie, useful only in a few situations).
So, that is a small difference between us, and we both knew about it.  I think it arises mainly from different experiences (different specific situations), and that we fundamentally agree on the principles (eg, the value of fast feedback, that one must save one's political capital for the most important changes, etc).
But, even though Dave and I have been talking about scaling frequently for years now, we discovered a new difference in this workshop.
Dave likes to talk about 'grooming' as one meeting, and a big grooming working of many hours, maybe even a whole day in a Sprint.  He has good reasons for this preference.  I like to talk about those activities as 'the red zone' (versus the 'black zone' of doing the 'real work' of ... in very simple terms, coding and testing).  In the red zone we do grooming and we do longer term release plan refactoring.  I like to call all of the red zone 'release plan refactoring and make it clear how connected the 'grooming before the next sprint' and the 'pre-planning' (as people often call it), it directly connected to the black zone, and to the longer term release plan refactoring.  And, for reasons I won't explain fully hear, I therefore do not define the contents of the red zone has strongly in other ways, but do usually propose at least two shorter meetings over a 2 week sprint, one hour each.  So, in simple terms, more meetings but overall less time 'all together'... or at least less time where we 'require' that we be together.
Dave and I had talked about these different views some.  But what became clear is how, for one situation, we were suggesting notably different options for the people to consider in scaling.   And they each had value.  They each made a different compromise about the different things we might try to optimize.  This was very interesting.
One key idea we discussed is the typical pattern of 'group-individual team-group'.  This is of course a typical pattern one find all over the place with scaling.  We need to discuss X at the group level first, then we need to discuss it at the team level to get into the details, then we need to bring back the learnings at the team level, and discuss again at the group level.  Perhaps you follow the idea enough so that, when I use the Yogi Berra quote ('Little things are big.') you see what I mean and why.  (If not, tell me, and I will explain more.)  Sometimes the concept is expressed succinctly in the aphorism (two versions): 'God is in the details" or "the devil is in the details."

Concluding thought

I was very pleased with this 2 day workshop.  The people wanted us to explain scaling, and all the different ideas 'out there' about it.  While of course there are a huge number of ideas out there, and it would take days and days to cover them 'fully', we gave them a decent summary in a time box.
And we talked about specific situations, and specific small patterns that might address those specific problems.  And we talked about the implementation issues for implementing those patterns (eg, the politics of getting approval or buy-in). And to enough detail that I felt they had 'enough' to go do it.  These became not just abstract suggestions, but rather palpable, do-able action items.
So, I felt (and I think the attendees felt) that it was a very successful workshop.  It was fun for me to work with them.


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.