Early Warning System

I was giving a course today, and we were talking about whether to do agile release planning at the beginning of the effort.
(I guess I must add that release planning always means release plan refactoring every sprint. To whatever degree it is needed.)
My advice is that most teams that I see need agile release planning. For a day or two before they start sprinting.
So, one question is: why do agile release planning?  And there are many reasons.
One additional reason: Early Warning System.
The agile release plan gets reflected in a release burndown chart. And the release burndown chart can show the team if or when it starts to get into ‘trouble’ versus the stories they expected to delivery in this release.
And then, knowing that, the team can make adjustments.  But, they cannot know they are in trouble without an early warning system.

The ScrumButt Test

Bas Voode originated a test.  7 or 8 items.  Jeff Sutherland and others liked it.  It got revised a bit.  Eventually it became known as the ScrumButt Test. 

They developed the test to check whether a team is really using Scrum or reverting back to waterfall.  Or, possibly, reverting to what I call Cowboy Agile (see wikipedia on cowboy coding). Or doing Agilefall (talking Agile terms, but really doing mostly waterfall).

The ScrumButt Test is in two parts.

First, are you doing Iterative Development?

• Sprints must be timeboxed to less than 4 weeks
• Software features must be tested and working at the end of each iteration
• Sprints start with an enabling specification

The experience is that if you ask a lot of "Scrum" teams if they can pass this part of the test, they can't. If you are at a conference, often not a single team in the room can pass.

The next part of the test checks whether you are doing Scrum:

• •You know who the product owner is
• •There is a product backlog prioritized (mainly) by business value
• •The product backlog has estimates created by the team
• •The team generates burndown charts and knows their velocity
• •There are no project managers (or anyone else) disrupting the work of the team

My reaction:
I think this is an excellent way to start to address Cowboy Agile or Agilefall.

Let me say this loud and clear: a firm can't in good faith say "we tried Scrum" if they can't pass this ScrumButt test. And pass for a reasonable period of time. Of course they could say "we tried Scrum", but they did not. (I will not define right now what 'pass' would require.)

The ScrumButt Test is demanding. That is clear. But a test of this nature is a necessary (if not sufficient) condition to doing professional agile software development. (Or did we expect to get out of Fred Brooks' tar pit by doing unprofessional software development?)

There are some forces in a firm that want to do Cowboy Agile or Agilefall or want Agile to fail ("it's moving my cheese"). This is true in every firm that I have worked in, I believe. So, if you use the ScrumButt Test, expect to get some resistance.

The  Test is arguably too minimal. There are many other important parts of Agile or Scrum that it does not cover. Are the things in the test the most important parts? My thought is that this collection of principles and practices provides a good core of Agile/Scrum that will defend you from the most common dysfunctions. Not all. 

Is there a better test? Probably we could define one, but let's pass the ScrumButt Test now.

Should the test be significantly more detailed? I think not. First, to work with any test, we need the test to be simple enough to be comprehended easily by most of the people involved. In this way, it becomes self-policing. Second, Agile/Scrum needs to be adaptive, so defining too many rules would, at some point, be counter to self-organization. 

What are your thoughts? Are you aware of similar tests? How does your firm limit Cowboy Agile?

Kanban ideas

We have been talking about Kanban a bit lately in other venues.

Let's talk about some key Kanban ideas in Scrum. Here.

1. Do the most important thing first.

In Scrum, we want the Product Owner to order the work (the PBIs or User Stories) mainly by Business Value.  (Yes, we talk about 'ordered' now, but this is mainly Business Value, looked at from the 'right' time dimension, not 'let's do the low BV things first.')

2. Pull

In Scrum, we only work on things that the PO has 'pulled.'  We don't do what we want, and hope it will sell.  We don't create 'excess' inventory.

Is this perfect?  Well, no. The ideal is that the PO has received an order from 'the customer.'  But this varies by business and by product.

But at least the PO, on behalf of the customer, says he wants it. Now.

3. Flow

Scrum has flow for each story. Anytime flow is stopped, as shown by the Scrum Board, then that impediment should be fixed.

It is true that flow stops for the 15 minute stand-up each day.  This is not really a problem.

How does Toyota do it?  Toyota (Taiichi Ohno) says that the Team must be in sync. As in crew, they must row in sync. That's his metaphor.  Scrum has the same concept, in part as shown in the Daily Scrum.  Toyota does not have 'every single minute' flow. In fact, Toyota is very famous for 'stop the line', where flow is purposefully stopped in a major way. To fix a defect.

So, Toyota and Lean are very mindful about when to have flow, and when to sacrifice flow for other values.

Using a Team that is in sync also enables greater flow. Example: If one person is stuck in any way, the other teammates are there for immediate help. And have every incentive to help, since they want the team to 'win' or be successful.  So, the team concept increases the flow.  Yes, there is a small 'price' perhaps in the Daily Scrum, but it is small compared to the benefit.

4. Minimize WIP

It is good for everything and everyone to minimize Work In Process (WIP). I won't try to explain here why that is so.

Scrum does this first by saying, one product backlog to one Team. And an ordered Product Backlog. And then, that the Team should choose for the Sprint the top items from the Product Backlog, but only so many as it can confidently do in a Sprint (whatever the Sprint length might be).

Some of the reasons for using a Sprint Planning Meeting for this are...
(a) to minimize disruptions during the Sprint,
(b) the inter-connectedness of pieces of work, so that the Team can choose stuff that is reasonably inter-connected, in such a way as to maximize the feedback at the end of the Sprint in the Sprint Review (demo) (we always get feedback...many reasons), and
(c) to allow 'chaos' in at the end of the Sprint. And a possible significant change of direction.

This last one also allows and encourages a serious re-think about the whole direction of the product. We _want_ significant mid-course corrections.  In part, based upon the feedback at the Sprint Review.

In addition, Scrum uses the Scrum Board to minimize WIP. Only the top story (PBI) or two should be in progress at any one time. If a story gets stuck, we can put it down, and pick up the next most valuable story.  But in any case, we minimize WIP.

***
I am quite impressed, as I think about it now, with all these Kanban ideas already in Scrum.  I will try to explain them more later.

And also explain how we might change the Scrum Board to be a slightly different Kanban board.

Waterfall meets Disciplined Agile

Two friends and colleagues (Etienne Laverdiere and Richard McMullin) put together a presentation about their experiences with one project. They titled it: Waterfall meets Disciplined Agile.


Very interesting.  Would, of course, be even better if we could hear them talk.

Enjoy.

PS. Of course, Agile should always be played in a disciplined way. They were not implying anything to the contrary.

Leading Fearless Change

What is the hardest thing about Scrum?  (Maybe in life.)
Probably, it is that we must lead change.
Getting people to change is difficult. And in Scrum, for example, we are always trying to change people. Always continuous change. Always removing impediments.
But first, we have to change them to agree to a fully dedicated real Team. Then to fewer disruptions and only one product (product release). Then to doing all of Scrum. Then to really understanding self-organization.  And on and on.
And then we start with the real hard impediments. Technical impediments. People issues. Managerial issues. Organizational issues.
Here are some resources to start with:
Leading Fearless Change by Mary Lynn Manns and Linda Rising. A good article by them. 3 pages.
This leading change course. With Mary Lynn Manns. In Charlotte in April.
By the way, this course will be about change. Any change. Not just change using Scrum or Agile. Any change.

Video Resources

Just added a bunch of new videos to the Resources section of the website.
Enjoy. Most are fun, I think.
Here.

Are there PMs in Scrum? No (but...)

Scrum has only 3 roles: Product Owner, ScrumMaster and Implementer.
Who is responsible for 'the project'?  Well, that would be the whole Team.
What do we do with George, who was a Project Manager (PM)?  Well, we have to talk to George, but maybe he would make a great ScrumMaster or a great Product Owner.  Or something else.
The ones who liked removing impediments tend to make good SMs. The ones who liked managing the requirements often make good POs.
Next, several comments.
1. Some of the best agile people I know were Project Managers once.  (I was one once.)
2. It is very common for the phrase 'project manager' to imply to some people that that person is 'responsible' for project success.  This is not the case with agile. The whole Team is responsible. Together.  Each person in a slightly different way. But, they win together or they lose together.
Now, often the PM knows well that only the Team has success. And sometimes the Team also understands this well. But as soon as we call someone 'PM', then a manager outside the Team starts talking as if this is George's project to win or lose. And it starts to hurt things, hurt the chances for success. So, I suggest avoiding the term completely.
It is a nice idea that one person only could be responsible. It might seem to make another manager's work easier.  And maybe in some areas, it is true. But in our knowledge work, the whole Team must contribute. So, they win or lose as a Team.
3. Some PMs have years of experience trying to drive a 'team'. They have their checklists. They have their command-and-control ways. I think this way of working is wrong, both as a way to treat people, and as a way to success. In any case, it is not what we do in Scrum.  And, many PMs cannot break these habits. So, watch out for that.
4. Scrum is a simple framework. Scrum does not even try to give the Team, by itself, everything that the Team will need to succeed.  They Team is expected to add things to Scrum, appropriate things for their work and their situation.
In this regards, many PMs have dealt with and studied many of these 'possible things to add'.  So, often George is good at suggesting these things. And other things can also be suggested by other 'disciplines too.
5. Some companies still have PMOs after getting well started in Scrum. (PMO means Project Management Office, although I find each PMO group...usually several PM types grouped together...each PMO group can be run quite differently.)  This may not be the best pattern, but it is not clear that this is a terrible pattern. Or at least, it might be a necessary pattern for a temporary period.  In any case, some PMs can still work in a PMO kind of office, and this does not seem to be totally contrary to Scrum, or to clearly hurt Scrum teams. (But there are occasionally issues.)
6. Most of the duties of the old PM are divided in Scrum amongst the PO, the SM, and the Team.
7. Should we put George (a PM) on a Team that already has a PO and a SM?  And give George mainly his old PM duties?  (We could make a long list of those....)  No, it seems very unlikely this will work well. George will be in too much unnecessary conflict with the PO and the SM. And, while there may be a few other duties, they are not enough to keep George busy full-time.  Maybe, in a system that still also demands Teams to comply with waterfall reporting, maybe then there is enough work for George (the former PM) as a 'pig'. Maybe. But we ought to get away from that as soon as possible.
8. Could Scrum Teams in large organizations need help doing 'project management reporting' and such?  Yes. And often George has a great role to assist several teams in handling this work.  In this case, we might say George is a 'chicken' to several teams.  Still, we would hope that most of this role would go away with time.

Our Favorite Scrum Mistakes

Ah, Valentine's Day!
A day for a simpler love than "love your enemies". But even this simpler love is quite complex.  Well, as long as one is not besotted like Romeo on below the balcony. Or Juliet above. When one is besotted (well, as I still am), then love is simple. But on other days, it is not. Or so I am told.
So, as a Valentine's Day gift, we offer "Our Favorite Scrum Mistakes".
This list was put together by a bunch of great Scrum trainers.
Some you will readily recognize.  Some you might say "Oh, really? We might be doing that." You will find some of them to be similar to each other. You may be surprised with how many there are.  And I disagree with a few of them. (One suggests it is bad to estimate...well, it has problems, I think we must.)
Read, enjoy, learn.  My and our gift to you.
The list is here.

Do we estimate in Scrum? Yes!

A really smart and experienced colleague says we should not estimate. And that in Scrum particularly, we should not estimate.
Now, to get into the deep inner-workings of Lean and Continuous Flow...well, I am not going to go there today.
As a minor point, I will say that the latest Scrum Guide to me says we estimate in Scrum.  Especially 'work remaining', both at a Sprint level, and at a 'release' level (although the guide says 'goal' instead of release -- I won't go there right now.)
But let's assume we really need a real explanation of why, not just 'the bible says'.
Where do we start to explain? I started at one place, and I kept going backwards. I kept asking myself "Yes, but why is that so?"  So, having gone backwards enough (at least, enough for me), I will go forwards in the ideas with you.
When the Duke basketball team plays UNC tonight, who is responsible for winning?  Just Mason Plumlee? (the big center for Duke, possibly their best player, a senior).  Coach K?  Well, they are too...but the whole Team is responsible. They win or lose as a Team.  Coach K only says that 1 million times each season. They win or lose as a Team.
OK, in Scrum, who is responsible for success?  The Team.
We have this saying: The PO is the single wringable neck. True, but possibly mis-leading. Yes, if the Team is not producing enough benefit over cost compared to other options (or just not enough period), then in Scrum, the PO has to call it and 'stop the madness'.  Do the right thing. And stop the Team completely, or start on another product.
It does not mean that the PO is the sole person responsible for success.
The whole Team is mutually responsible for success.
To customers, success always means delivering earlier, delivering fast. You, as a customer, always want it yesterday.  It is a key component of success.
Now, customers understand it takes some time, and they always say they want 'everything'.  But they need a solution now, so time also is always a critical factor.
So, we are always caught in this dilemma...do it faster AND give us more. It is a tension, it will always exist.
There are lots of stupid things we can do with this tension. Here are some classic ones:

• Death March!
• Unsustainable pace (the less immoral version)
• Cut the quality to make the date
• Give up
• Pretend like time is unimportant

Occasionally 'give up' is a responsible option, for example, when it is obvious our product will be too late to the market.
But usually the responsible thing is for the whole Team to manage through the tension.
In terms of specific trade-offs of stories (does it go in this release or the next release -- is often the question), typically the PO makes the call.  But based on all the input and work of the Team. The Team together is successful or fails.  The Team together works on impediments, for example, to improve their velocity.  The Team together must make the date.   (I don't want to mention any wonderful products that were late to market and failed. Do you really need me to do that?)
So, the whole Team needs estimates.
How much work will X be? (X could be a story or a whole release.)  And, as I assume you know, we use Story Points and Velocity in agile. (I won't explain them here.)
So, what's the problem?
Well, there are many problems that we have to deal with. Some were mentioned above (Death March, for example).
Next problem.  Many many Team members have seen estimates be used, over and over again, to just beat them into unsustainable pace. They have just been used irrationally and stupidly. They often have an immediate visceral reaction. Please be considerate of that. It is based on real (bad) experiences.
Next problem. As soon as we do estimates, some stupid manager (yes, there are a few stupid managers out there) starts to think that the estimate is perfect.  It NEVER is. That's why we call it an estimate, doh-doh head! (Speaking to that manager right now.)  I bet there is even a stupid manager in your firm, at least stupid on this subject.  Fix him or her.
So, in Scrum we do lots of things to manage the estimates, manage the tension. Some are:

• Remove impediments to increase velocity
• Re-estimate
• Learn more
• Break down the stories more, and move part of that work to later
• Try to harness the good change more (eg, learning, and ... did we mention fixing impediments?)
• Don't let the bad news get 'better' with age (one version: "no bug survives the sprint")
• Learn to estimate better (tends to happen, to some degree, naturally with time)
• Estimate as a Team (gosh, to me it was assumed, but I guess I better make it explicit...this does help a lot, especially with time)

We also have to be careful what we say when. Example: We do the initial release planning. We guess at the Team's velocity. Should we tell a 'stupid' manager the initial date (with some guessed at buffer) immediately?
Maybe not!  Maybe we wait a couple of sprints (this is how long the waterfall estimates used to take...it might be ok)...wait, find out the real velocity of the Team, and then propose a (more accurate usually) date range.
So, we need to use estimates in Scrum. In a professional way.
There is good stress and there is bad stress. Manage the tension in such a way that it becomes good stress for your Team. It won't be easy, but then most good things require some work.
***
Was this convincing to you? Could you use these ideas to explain to the Team why they should want estimates?  Could this help your PO? Comments please.

If you wait for perfection, you might wait too long

I guess I will take credit for this phrase (see title).

To me, it reflects a  key idea behind lean-agile-scrum.

It is an idea expressed in many other ways also.  Ex: The perfect is the enemy of the good, which originated in France.

I like my phrasing, because to me it has a sense of humor.  It teases you.  It says: "Why wait?  How bad can it be if you make a mistake? You might learn something if you act. And learn much faster."  In fact, in most of our business situations, this 'learning from real action' is so true and so powerful.

Agile - Penny Game rules

As attendees of my courses know, I like to use the Penny Game.
Rules:
1. Say: "We are about to see who is the best penny processor in all of [city] today.  And the winner, with the best single round, will win $20."
2. Select 4 players (4 departments).
3. Select 4 managers, one for each Dept. Make sure the managers each have a stop watch.  Also, we need a one or two special managers, for the 'first penny' and the 'last penny'.  Also with stopwatches. (Get inventive if you don't have enough people.)
4. Give Dept 1 a bunch of pennies (any kind) and say: "Please get 20 pennies ready, all face up, or face down."
4b. Optionally, ask the managers how they will motivate their worker.  Some good laughs.
5. Round 1: The managers time how long it takes to flip each penny, one at a time.  Only using one hand. And pass the FULL batch of 20 to the next Dept without errors. (May use 2 hands to pass.)
6. Write up the times for each Dept, and the times for the 'first penny' (to reach the customer) and for the last penny (to reach the customer).
7. Round 2: Each Dept must process 20 pennies, but in 2 batches of 10.  As soon as the first 10 are flipped, they must be passed. Each manager measures the full 20, until fully delivered.  Again, we write up the scores in public. Including the timing for the first and last penny (the last penny is in the last batch).
8. Round 3: Each Dept must process 20 pennies, but in 4 batches of 5.  As soon as the first 5 are flipped, they must be passed, and so on. Each manager measures the full 20, until fully delivered.  Again, we write up the scores in public. Including the timing for the first and last penny.
9. Round 4: Each Dept must process 20 pennies, but in batches of 1.  Flipping must be separate from passing. As soon as the first penny is  flipped, it must be passed, and so on. Each manager measures the full 20, until fully delivered.  Again, we write up the scores in public. Including the timing for the first and last penny.
The Dept with the lowest single score 'wins' the $20.  Hand the money to the manager.
10. You ask the participants: 'Did we do this game to find out that [George] is the best penny processor in [city] today?'  They say No.
11. Ask the people, "So, the numbers are talking to you. What are they saying?"  If you have experience with the game, you might comment on how 'normal' the numbers are.  Typically most numbers are quite normal, but a few are 'off'.
Usually the will come up with some very good, counter-intuitive Lean insights.