Friday, October 17, 2014

3 Ways a Scrum Team is managed

We think it is reasonable to manage a Scrum in at most 3 ways.

1. Self-management.

The most important way is to tell the Team that they are respoonsible for managing themselves to success.  That is, within their scope, they have to figure out what they need, and then get it.  They have to define all the details of success.

2. Business stakeholders.

The business stakeholders directly working with the Team have a responsibility to provide management over-sight. Honestly, though, what I see is that these managers usually over-manage.  They do not let the Team self-manage enough.  And this hurts.

But, if the Team is not managing itself well, they must do something.  The first thing is to say things, ask questions, but let the Team make some small mistakes.  That's the way they learn.

But if the mistakes continue or might be big, then these 'managers' must intervene.  Usually by helping with one or two impediments.  Possibly by making some people changes.  At the extreme, by dis-banding the Team.

3. Oversight of multiple Teams

There should be an oversight group.  In a small company, this might be the Executive team.  In a larger company, maybe a 'team oversight group'.

The purpose of this group is to look at each team and evaluate whether it is doing 'well enough' to continue, when compared to other Teams and other opportunities.  And, they can help a Team as well.  And resolve some conflicts (eg, two teams want the same person, and that's not possible at the same time).

One can also imagine that the business stakeholders might not do their management job, so this is a backstop to that level of management.

BTW, we strongly urge that the Team itself be there when the oversight group reviews them.  The Team can answer questions, and they can take any feedback 'back to the Team' with much less mis-understanding.  Try to keep the communication clear.  It might be ok if only the PO and the SM appear at the oversight group.  Maybe.

***

So, 3 'levels' of management.  And that is *enough.  The poor Team needs time to actually do something, instead of being managed so much that they go crazy.

In Scrum, it is pretty clear to see if they are making progress, and usually even if they are making enough progress.

It is just wrong to over-manage innovation.

 

9 Key statements about estimating

I won't explain them now, but here's the summary...   
  1. Estimations can be mis-used by some managers (and have been).  Watch out!

  2.    
  3. Customers want some kind of estimate. (Ask for their details about what kind of estimate they want.)

  4.    
  5. There is a trade-off between the time it takes to estimate and relative accuracy.  Keep it shorter (usually) (of course, that depends on how short you were thinking...).

  6.    
  7. Always re-estimate.  Usually many times.  And arrange things with the 'customer' of the estimate to expect a re-estimate.  Make it easy to re-estimate.

  8.    
  9. Re-estimate when you are smarter.  Devise things so that you get smarter

  10.    
  11. Always discuss the variability of the estimate.  At least in some way, with the 'customer' of the estimate. ('I can promise 2015, but I can't tell you which month.'  A small joke, illustrating the range method.)

  12.    
  13. People can learn to estimate better, and faster.  Sometimes they start out terrible.

  14.    
  15. It is not the plan, but the planning.  We (the Team) get so many wonderful outcomes while we are planning.

  16.    
  17. Estimating can be fun, if you do it right. (But expect many teams to start with latent fear due to #1.)

Interested in your comments.

Bonus points if you notice a reference to John Legend.

Thursday, October 16, 2014

Can the Team promise a date?

I think this is an important question.

Promise.  Umm.  What does promise mean?  Can Joe Namath promise a Super Bowl victory?

(I think he said 'guarantee'... and, oddly, his Jets team did actually win it.)

***

Let's say you have a fairly big project, that maybe requires 3 releases that happen every 3 months.  So, overall, a 9 month product before it is 'fully' built.  (IMO, no product is ever fully built; the customer always wants more.)

So, it is what I used to think of as a normal situation.

To make it easy to describe, let's imagine we are at January 1, and the releases will be March 31, June 30 and September 30.

In this situation, can the Team promise on Day 0 (Jan 1) that the releases will happen on exactly those dates?

Well, maybe they can.  In other words, they can say "We will release on those dates, and we can give some rough ideas today what the functionality will include, but it may change some."  I think they can usually or often say that.

Will change happen?  That is about the only thing that is a 100% certainty.  (Ben Franklin said death and taxes were certain, but Buddha said "Everything changes, nothing remains the same.")

For certain, some bad change will happen.  We will disrupted.  People will be 'taken' from us, in some form or another.  Important features will be discovered later.  (BTW, discovering important features is only bad when it happens 'later', and really only because it leads to a delay, and we have a weak mechanism for doing the customer trade-off between delay and the value of that feature.)  Etc, etc.  What is uncertain is how much 'bad' change will happen.  But, we will certainly have some bad change.

If we are professional, we will also have good change.  What is that?  Well, we will learn.  We will become smarter.  We will remove impediments and become more productive.  And, if we generally professional, this good change is certain too. What is uncertain is how much good change we will have.

***

Can we make a useful prediction of the release date for every product?

This is a very hard question, since no one can even imagine 'every' product.  But it certainly sounds like the answer must be 'no'.  One can imagine situations of many unknowns, extreme change, etc, etc.  We can issue a prediction, but, at least for those 'hard' products, it will turn out to have been useless or worse.

So, 'useless' predictions are possible, I think.

But, does the 'fact' (well, we posit it as a fact) that some predictions will be useless make all predictions useless?  I think not.

How accurate does a prediction need to be to be useful?  Well, I find most business people do not need that much accuracy.  They completely understand risk and uncertainty.  But they want some better information. Often they will say 'can you get me better information than the competition has?'.... a very low standard usually, but when we say it that way, you see how they will use the information.  They just want to improve their odds.  The odds of success, and also the odds of not losing too much on a gamble.

***

Now, back to the Team's point of view.

A promise is not a guarantee (Joe Namath not withstanding).  A prediction is an educated guess about the future.  And, as any adult should know, to predict is difficult, particularly of the future.  (That's a variation on a quote from the Latin.)

Can managers mis-use a prediction?  Most certainly.  And some people called managers have brutally punished the Team when their forecast was not accurate.  This is not right.

Typically, managers should not even see the Day 0 prediction.  But, after some small number of sprints (given something like a 9 month situation), most Teams should be able to give a reasonable prediction.  It is never a guarantee, because something weird could always happen. But it is usually a useful business prediction, that can enable useful business decisions.  Decisions by managers or decisions by customers.

If you are in the Team, when should the Team 'issue' these predictions?  Well, that is a very hard question, that requires lots of judgment.  It depends.

It depends on whom they are talking to. How much that person (that group) understands that things might change.  How much we have learned.  How much uncertainty this product has compared to others.  How close it is to the release date.

There are many factors.

But, as a coach, can we in fairness suggest that Apple never tell the customers anything?  Should we suggest that Apple actively deny any rumors about a future iPad?  And say, 'we have no idea when the next iPad might be ready?'  (Today Apple is expected to announce a new iPad.)  Apple should never tell its suppliers when to expect to start building the new iPad.  Never tell its managers when the basic development of the iPad might be done? (So that the managers could talk to the supply chain.)  Clearly, in business, some predictions must be made.  It is just required by business.  If the company and 'rumor' does not make a prediction, then the people themselves will, and often a very wrong prediction (too early or too late).

And, of course, some understanding of the degree of uncertainty needs to be communicated, if the person can listen to it.  Sometimes we use a percentage. Sometimes we use a range.  Sometimes we use only non-denial of 'rumors'.  Or just words ('we think it will be announced in the Fall of 2014').  But we urge you to help those you are working with (eg, help your customers) by giving them some sense of the degree of uncertainty.

The uncertainty can vary quite a bit, from one product to another.

***

In summary:

1. Be careful making predictions.

2. Sometimes bad things can result from making predictions.  (Ex: Some teams have, to my horror, been forced into a Death March to make some 'predicted' date. Unbelievable that humans would do that, but it has happened and continues to happen, we think.)

3. Again, do not make predictions lightly.

4. You usually must make a prediction at some point.  People will require it; it is the nature of life.

5. Try to assure that the person understands the uncertainty in every prediction.

6. Try to establish that a new and better prediction will be made later (when you are smarter).

7. Accept that life has risk. ie, Make a prediction.

8. Learn to make useful and relatively accurate predictions.  The best way to learn that is to ... practice.  By making real predictions, and seeing how life turns out.

9. Never pretend that a prediction is a guarantee.