What is a real team?

I recommend you read "The Discipline of Teams" by Katzenbach and Smith. See HBR.com.  It is an article.  And they also wrote a book with the same title. And their original book was The Wisdom of Teams.  All recommended.

In the article, they give a short definition of a real team. And they distinguish carefully between a real team and all other 'work groups.'

Here is the definition:

"A [real] team is a small number of people
with complementary skills who are committed to
a common purpose, set of performance goals,
and approach for which they hold themselves
mutually accountable."

As an aside, I think the authors really mean that the Team members hold each other mutually accountable for success, however they define success for their mission.

A real team is a difficult concept.  If you have been on a great team, you know in your blood what one is. Or, at least, that there was something special about the people as a Team.  If you have never had that experience, either in sports or at work, then it is all just some concepts.

And of course the real question is 'how do you form a high performance team?'

We can say that some people have this magic ability to form great teams.  One thinks of Coach K of Duke.  And many other great athletic coaches.  Some managers are famous for it. And some agile coaches and ScrumMasters are great at it.

It can be done.  And there are some special talents.

Let us give our first hints.

1. Get a good team.  They need to have the raw talent.

But raw talent alone is hardly the key. And almost no 'special' Team ever had all the skill sets on Day 0.

2. Get them to be team players.

This is key, and hard. First, they should care most about team success.

It is hard, because in some moments they must also be 'selfish' in a sense.  One person must demand the ball, as we say. But, the key is that they are driving toward team success.

3. They hold each other mutually accountable.

Quite key.

Not everyone is equal in ability.  And they each do not have exactly the same skill sets.  Yet, they each demand the best from each other.  And each person is willing to give, as we say 'all that you got.'  And they each help each other get better.  And sometimes that involves a tough conversation.

4. They communicate.

Coach K says this is key. And each great Team does it a bit differently.  One could say the communication is so good, it is almost unspoken.

And of course, every set of people communicates about something some of the time.  So, in a trivial way, communication is very common.

So, of course, we mean superior communication about the most important stuff at the toughest times.  Or something like that. The communication in great teams is in some way awesome.

5. They have a tough mission.

This seems to be essential.  The situation or a senior manager or they themselves give them (as a team) a tough mission. Something that is hard to do.  Something that they will fail at unless and until they come together as a real team.

And then, usually, they do come together, they do overcome their 'individual-ness' and become as good a team as they can become.

They say the mission forces them to become a real team.

6. Let them self-organize.

You must. It sounds hard. There is no other way.

You must let them fail some, and learn, and become self-reliant 'as a team.'

7. Don't let them flounder.

You are saying to yourself: "But, Joe, you just said 'let them self-organize' and now you say 'don't let them flounder.'  Which is it?"

And it is both.  OK, let them fail some.  But as a coach or a manager, you can help them.  Just don't get in the way of the self-organization.  And if they are really floundering, and it is important enough, then you must intervene.  Most people won't let them struggle enough.  The wise coach, the wise manager chooses just the right time to intervene.  Clear enough?

***

There is so much more to the art and science of building great teams.  Tell us all as you learn more.

Metrics and Managers

Dan Greening gave an excellent talk about some aspects of metrics at the Scrum Gathering in New Orleans in early May 2014.  Go here to download his presentation: http://www.scrumalliance.org/courses-events/events/global-gatherings/2014/new-orleans-2014/presentations  (You must at least be a member of ScrumAlliance to have access to that page...sorry.)

Dan inspired me to talk more about metrics.

First point: Managers like metrics.

This is a reality of life.  It is good and it is bad.  In any case, in large organizations initially, we must face that reality. And it is the reality, I think, in even in almost every small organization also.

And, if managers are properly trained in managing, I think metrics can be helpful.  They must of course know that metrics are imprecise and can be 'wrong' (although usually they are directionally correct).  And they must understand that metrics about the past do NOT predict the future.  But, they may give us insights into the future, if used with judgment.

Motivation.  This is a key issue. There are many ideas and theories, but I think we can say this at least.  Whether good or bad (or both), metrics usually have some impact on motivation. Obviously, we want it to be a good impact (and to minimize any bad impacts).  Because of this effect (and because the intended effect(s) is not always the real effect(s)), I strongly urge a significant discussion about the effects, with the right people.  Let me, for now, put off a fuller discussion of this motivation issue.

Which metrics does Scrum give the managers right out of the box?

1. Velocity

This is the average number of story points of work completed per sprint.

I won't here go all the way back to explain story points from scratch, but assume they represent 'units of work'.  And we average over some reasonable number of sprints, to smooth out the variability from sprint to sprint. (We, as managers, should expect some variability.)

And the velocity gives us an index of the productivity of each team.

And this is useful in measuring improvements (ideas for fixing impediments).  We can say "Oh, after we fixed that impediment, the velocity went up 2 story points...."  Or we can say "We have spent $100,000 on fixing impediments, but from that the velocity has gone up 50%.  It has been well worth it."

Velocity is useful for estimating release dates.  We can say: "Those features (stories) add to 36 story points of work, so it will probably take about 2 sprints to complete that release."  (In my example, we have an average velocity of 20.)

Velocity.  Don't leave home without it.

2. Sprint Burndown Chart

Well, this is not so much a metric as a chart.  But a chart built on numbers.

First, it represents a view of work remaining on each day.

There is debate in the community on how to do it, but let's do it the old fashioned way (and the way I still recommend for beginning teams): based on hours remaining on the tasks.  (I have the new teams estimate 'ideal hours' for each task.  And they can re-estimate at any time.  And, as of 9am (or some hour they choose), we add up the hours remaining.  And chart that on the Sprint BD chart each day.

And it forms a jagged line, as we connect the dots, day to day.

How does this help?

Well, it gives the WHOLE team some essential information... that then enables them, as a whole team, to self-organize, self-manage, and self-direct.

For example, if they see they are in trouble, they will focus and fix impediments (more).  If they see they are ahead, they might take on another story (toward the end of the Sprint) or talk about how they might do another story.

How does this help a manager?  (By definition to me, a manager is outside the Scrum team.)  First, it SHOWS the manager that the Team is using the information is has, to build the Sprint BD chart.  Then, if the manager listens a little, he should hear them self-managing.  This is good, and means he does not have to manage them at that level.  Then, over time, as he (or she) sees trends in the Sprint BD, the manager may notice some unusual situations.  Especially in those situations, or especially when the Team appears to be 'in trouble', the manager can know when to offer to help with an impediment or two.

Note: Every company is different, and every manager is different. We are already discussing fairly specific situations.  Some managers, for a variety of reasons, might or might not get involved in these situations.  In part, one wants to know: what is this manager trying to manage?  In any case, we are not addressing these detailed issues here.

3. Release Burn Down Chart

Again, this is not so much a metric as a chart.  But a chart built on numbers.

Here, it represents a view of work remaining at the end of each Sprint.  This is work remaining to get the Release completed. Anything can change each sprint, so this is a new view at the end of each sprint, after all the changes, of the work remaining.

In this case, there is no debate in the community about how to estimate this: use story points.  Well, as you know, not everyone agrees about story points, but all the 'good agile people' I know prefer story points.

Note: there is some debate whether this should be a Burn Down or a Burn Up.  And maybe some other details.  The Scrum Guide is vague about the format. It does say that the Team should measure the work remaining, but it does not say how to show that measurement.  Jeff Sutherland tends to say 'well, how about a Burn Down?'... so, I tend to go that way.

OK.  So, in a 'burn down' chart, the points connected form a jagged line, as we connect the dots, sprint to sprint.

How does this help?

Well, again it gives the WHOLE team some essential information... that then enables them, as a whole team, to self-organize, self-manage, and self-direct.  In this case, they are not managing success 'in the sprint', but rather success over the release period (x number of sprints).

For example, if they see they are in trouble, they might focus and fix impediments (more).  Or remove stories from the release.  If they see they are ahead, they might take on additional stories (probably more toward the end of the Release period).

We certainly hope that the simplicity and visual nature of the Release BD helps the team focus on the top impediments, rather than get lost in trying to fix a plethora of small problems.

How does this help a manager?

First, let's assume the manager wants the Team to be successful.  Then, let's assume the manager is reasonably balanced about how he or she defines success.  It mainly means: the customer is really happy.  And it is some balancing of scope, date, and budget.  So that, for example, not only is the customer happy, but firm 'profitability' is also seen to do up.

So, again, it is similar to what we said before for the Spring BD. If things are going fairly well, the manager does not have to do anything (maybe she can focus on a different team, one that is having some troubles).  Or, if things are unusual (either good or bad), then the manager can facilitate the discussion to lead to a better outcome.  For example, maybe the manager helps with impediments or gets others involved helping with impediments.  Maybe the manager asks this team (when ahead) to take on some extra work to help a related team that is 'behind' (according to the Release BD charts).

Over time, a manager will notice some common patterns to Release BD charts.  And will react appropriately when we see an initial 'burn up' (ie, not get over-excited).  And will similarly not get overly optimistic if the Release BD in the middle of the period suggests we are 'ahead'.

And with the Release BD, we hope each Team and each Manager will learn respect.  Respect for each other.  The manager respects that each team will normally be pretty good at self-managing.  And each Team will realize that a Manager can also be helpful, and will often have a wider of view of things (eg, the firm or the customers) than the Team has. And, in any case, the Manager can be helpful in removing impediments.

***

Obviously, there are many more metrics. No doubt some of you 'always' use other metrics when first using Scrum. But I consider the ones above to be the main three initially.  And we will discuss other metrics soon.

Comments please...

The Scaling Dilemma

Some very useful comments about scaling by Mary Poppendieck.

http://www.leanessays.com/2014/02/the-scaling-dilemma.html

Blinding flash of the obvious

Tom Peter's wrote a blog post, about the blinding flash of the obvious.

Here: http://tompeters.com/2014/04/excellence-excuses/

Suffice to say, I think it is worth the read.

Enjoy!

"It's not too far, it just seems like it is." (Yogi Berra)

I wanted to talk quickly about 4 classic mistakes or issues.  We all must deal with these.

Before starting, I wanted to mention this famous and important quote: "In theory there is no difference between theory and practice. In practice there is." (Yogi Berra)  I forgot to mention this one in the last class, and it is pretty important.  To me, it means that although you may think you understood what I said in class, when you meet that same problem in reality, it will confuse you.  Only later will you understand what I really meant (or maybe, what Jeff Sutherland really meant, about Scrum).  So, be patient with yourself, and do not be surprised when reality confuses you.  But still act.  Better to act and learn than to think too much. (But the advice is not: 'don't think at all'.)

1. "It's not too far, it just seems like it is." (Yes, Yogi Berra said this one too.)  To me, this means that when we start Scrum, it may feel impossible.  Some things may feel like we will never get the people or the firm or the situation to do them.  Or that we ourselves will never learn how to do them.  But, often you soon find that what seemed impossible can happen rather quickly.   Once you get a little practice and a little help.  More automated testing comes to mind at this moment.

2. "I have it all figured out."  Of course, we all fall victim to this one. No one has it all figured out.  So, specifically, some people leave the 2 day CSM class thinking they have it all figured out. This also is a delusion.  The glass is not empty (or, the work is not impossible), but neither is the glass full (ie, it will not be easy).

3. "I don't need any help." Well, that you will only really learn by doing is quite true.  But you will learn more and faster if you get a coach or other help from outside.  This is true if you wish to be a professional in any good sport (and Scrum is a sport that we want to play professionally and we want to win).  No, I am not saying that you only have to get help from me.  There are many to get help from.  But to get better, you will need some help.  And help from outside your company.  (I will not explain that now.)

4. When you get to the top of the mountain, you will then see a bigger mountain. -- This means that once you start to master the basics, you will start to see that the basics were actually far more complex than I told you.  And you will see also there, both in the basics and in the more advanced moves, there is far more to learn.  This is true, of course, with any good sport.  But, it does not help for me to talk much about that next mountain.  Wax on, wax off.  Focus on what you need to learn today.  Leave until tomorrow the troubles of tomorrow.  Focus on today and get it done, and learn.  If I had made it too complex (and maybe I did), you would have slowed yourself down by thinking too much and trying to be too perfect to soon.  KISS.  Keep is stupid simple.

There are several reasons I have put these 4 together, or all of these things together.  In part, because of a recent in-house course with a client.  But that experience alone does not explain all the comments (guys...it is not all about you).

I hope these comments are useful to anyone who may read them.

Impediment List - Inhouse Course May 15

I am a strong supporter of identifying small things that we can take action on, one at a time, to get better.  In Scrum, we call this an impediment list.  This week, the class identified these impediments. I think I have it right....

1. Lack of governance
2. 0% transparency
3. Actively disengaged team members
4. Competing goals
5. Adversarial sponsors
6. Poorly understood technology
7. Losing people mid-project
8. Too many cooks
9. No change management
10. No requirements
11. Individual contributions [not team contributions]
12. Finger-pointing
13. Lack of support
14. Ill-defined teams / structure
15. Lack of team collaboration (incl vendor-client)
16. Unrealistic estimates
17. Exit criteria [lack of??]
18. Too high expectations
19. Insufficient funding
20. Silos
21. Changing scope without adjusting (R or T or B).
22. Poor communication
23. Lack of Buy-in
24. Absences from meetings
25. People availability
26. Poor estimates of time
27. Poorly defined tasks
28. No direction
29. No / lack of leadership
30. No understanding of benefits
31. Personal agendas
32. Command and conquer
33. Constant distractions
34. Unrealistic expectations
35. Business ownership / partnership
36. Lack of communication
37. Lack of buy0in / ownership
38. Disengaged team
39. Unrealistic value
40. Skillsets
41. Lack of coordination
42. Hidden assumptions
43. Complete assumptions
44. Just get 'it' done - don't know what
45. Unhealthy communication
46. Confusion
47. Lack of involvement from customer
48. Unclear purpose
49. Poor definition
50. Poor team dynamics
51. Single points of failure

There is some duplication, I think, for many reasons.  But perhaps useful in suggesting relative priorities.

A couple of key points:

• We have a list to prioritize and act on the most useful stuff first
• Prioritize mainly by 'how much is it slowing down the team'
• Use cost-benefit analysis to some degree (maybe only intuitive)
• Drive one to completion at a time
• Make them small.  No bigger than one sprint.
• Get the managers to help you (and the Team as well)
• Show results

Velocity: What if a story is partially completed in one sprint?

Question from Martin: If you had a user story (Story X) with 4 story points at the start of the sprint which was not completed by the end of the sprint but the majority of the work was done (eg just 2 small bugs remained) would you recalculate the story points when adding this into the next Sprint – for example effort was now only 1 to complete the story. How would this have an effect on velocity planning?

Answer: We don't play horseshoes.  (Do you know that game?) There is no partial credit in Sprint N.  And, if everything is completed in Sprint N+1 (according to the Def of Done), then the Team earns FULL credit in Sprint N+1 (4 story points).

But, you say, that is unfair!

Well, in a way.  So, yes, to get a fair velocity estimate for Sprint N+2, you must use the average over the last X sprints (people argue how large X should be....let's say 4).

If they Team says: "Well, if we had divided that into two SP2 stories, and earned 2 more SPs of velocity in Sprint N..."  You say..."Yes, but you didn't."

This gives the Team a big incentive to have smaller stories (which virtually 110% of the time, smaller stories would make everything better).

Why?  Well, it does seem like making the stories smaller takes more time.  To do that, to put story points one, etc, etc.  And there is some truth to that.  BUT...by making the stories smaller, it turns out that the feedback (and other factors) are much much better.  So, net net, there is a savings of effort. If we are smart, and use the feedback (and other benefits) well, professionally.

Remember what Yogi Berra said: "It ain't over till it's over."  Meaning, for us: We never know if our work is really complete until it fully matches the Def of Done.  Sometimes they say 'there are only 2 small bugs remaining'.  But only after they are fixed and re-tested do we really know the bugs are small.  This is just so true for our kind of work.  You probably see it every day on your team.  (Give them specific examples.)

***

Next issue: How much work should the Team take on in Sprint N+1?

Answer: Let us assume that they can predict with reasonable accuracy that Story X has only 1 SP worth of work 'remaining'.  Let's assume that the average Velocity is 20.  And that Story X will be done in Sprint N+1.  Then, of Sprint N+1, the Team will 'use' 1SP for Story X and then have 19 additional SPs of 'capacity' for that Sprint.  Still, they will end up earning 23 SPs (assuming they get everything done this time). That is 19 SPs for new work, and 4 SPs for Story X.

Help enough?

What is really important?

Niels asks: "Is it really important to have a SP estimate before the first Sprint starts?"  I think he means an estimate of the initial team velocity before the first Sprint Planning Meeting.

Answer: The short answer to his immediate question: Yes, it is important.

Why?  It makes it a tighter meeting (SPM, Part1), and therefore the business stakeholders are more likely to show up regularly. This is good because they understand the Demo far better if they came to the Sprint Planning Meeting.  They can see, often enough, that the key problem is them: they (a) did not give the PO enough time, (b) did not let the PO talk to their people enough, and (c) don't really understand what they want.

But let's look at the bigger question inside Neils' question.  What is really important?

Of course this is a question that has puzzled mankind and Socrates for many years.

In terms of Scrum, I would say that delivering Business Value to the customer is most important.  And then other things are important to the degree they support that.  Among them, that the Team should have a better life.

Having an initial velocity estimate is not the most important thing in the world.  But it helps, and the cost is low.

People can also misunderstand the initial estimate, and you should discuss that also.

How does the initial estimate help?  The initial plan for the release is somewhat more realistic.  The initial Sprint Planning Meeting is less chaotic.  The business stakeholders will find Part 1 of the meeting somewhat more useful (less disorganized).  The work taken into the Sprint will be closer to what the Team can really do.  The Team is somewhat more likely to feel positive traction and 'success' after the first Sprint.  All these things help.

But let us not mistake these positives for our real goal.  Our real goal is to satisfy the customers with high business value.

What to tell the Executives - Part 2

Last week I discussed this issue with the Agile-Carolinas group.  Wonderful conversation.  Many great comments.

One thing I was struck by are the many many different types of situations.  And the different things we need to address, depending on the situation (including the people).

I also focused on the "3 Asks".  It is one thing to talk at the Executives (I tease myself for this).

But you make it more real for them if you ask them to DO something.  So, in my discussions, I have asked them to act on 3 ideas:

1. Much less WIP (work in process)
2. Support real teams
3. Help remove impediments

Oddly but also rather appropriately, I was asked what a 'real team' is.  And that indeed is the problem.  Lots of people use the word 'team' for about any collection of people.  They use the word loosely, with no real definition.  But in fact a real team is a special situation.  So, I gave a quick definition.  I think I will do a later post here and give Katzenbach and Smith's definition of a real team.

Again, the deck I used is available here:  http://www.slideshare.net/jhlittle

Estimating Initial Velocity

Here is a method for estimating initial velocity that may work for you.

I expect you to use it in the context of Agile Release Planning, probably as I define it.  But probably this is not necessary.

First we take some assumptions or identify the facts.  Imagine the following situation:

Implementers: 5

Sprint Length: 2 week

Ratio: 1 SP equals about 1.5 ideal person days.  (This is based on a sample from your product backlog or your reference story set.)

Focus Factor: 60%.  This means that although they are 100% allocated to the Team, as they work, they will only get about 4.8 good hours per day.  The rest of the time people are asking them questions, they are reviewing email, they are going to important company meetings, etc.

Start-up cost: 40% the 1st sprint, 20% the second sprint, maybe 0% the third sprint.  I give 3 reasons for this Start-up cost:

1. The team is learning Scrum
2. The team is forming, storming, norming, and then finally performing.
3. The team always wants to over-commit.  I find this to be the case.  Some people do not.

In any case, experience shows that taking out 40% then 20% then 0% is a good rule of thumb.  If your team is more experienced, maybe you take out less.

***

Now we start to calculate.

5 people and 10 days = 50 person days

50 X 60% = 30 ideal person days

30 X (1 - 40%) = 18 i.p.d remaining

18/1.5 = 12 SP for Sprint 1.

***

30 x (1 - 20%) = 24 i.p.d

24/1.5 = 16 SP for Sprint 2.

***

30/1.5 = 20 SP for Sprint 3.

***

So, those are quick guesses.  You can make the calculation more sophisticated, in the sense of catering for more factors (vacation, special situations).

In any case, these are still guesses.  You will soon discover the Team's real velocity from real sprints.  Use that soon.