The importance of a real team

Posted on by
Reply

Scrum requires a real team.

The word ‘team’ is often used, often in different ways.  So, let us define it.

According to “The Discipline of Teams” by Katzenbach and Smith, this is what you should look for:

1. A meaningful common purpose that the Team has helped shape.

2. Specific performance goals that flow from the common purpose.

3. A mix of complementary skills. Including technical/functional, decision-making, and interpersonal.

4. A strong commitment to how the work is done.

5. Mutual accountability.

For more discussion, see The Discipline of Teams.

The team needs to be small (~7), stable, cross-functional, and self-organizing.  The team is in it together.  And should help each other.

In general it is best if the team is fully dedicated to one missson, one purpose, or at least the one team’s goals.

All of these team characteristics together are key to starting Scrum.  Got to start with a real Team.

Note: Not everyone wants to be on a Team.  And for sure, not everyone walks into the office knowing how to act in a real Team.

Meet the Meeting Killers

Posted on by
Reply

Here is an entertaining article in the WSJ.  About people “types” that kill meetings.

Scrum of course has some meetings. It is trying to minimize meetings, and make meetings better.

But as soon as you have people and meetings, you can have some….umm…interesting times.  So, may your meetings not be interesting this way.

What to do with managers?

Posted on by
Reply

First, unlike some in the agile community, I think managers can and should be useful in lean-agile-scrum.

Still, there is a lot of evidence, on many levels for two propositions:
1. Some managers can be very detrimental to a lean-agile-scrum implementation.
2. Many managers have not been well trained in how to manage. In fact, what they have been taught seems to be, to a large degree, the wrong stuff. (At least, it seems, in the US.  In other countries, this may be better.)

So, we agile advocates have a long way to go to get all of management ‘fixed’.  I mean both middle and senior managers now. (Yes, the solution for the middle managers might be somewhat different than the solution for the senior managers.)  On the right page with the right attitudes and practices that are consistent with lean-agile-scrum.

So, a few quick ideas on how to fix this:

1. Check out the “Stoos” group. A few are a bit too radical for my taste, but that group is working on ‘management’.  They have useful ideas on this problem.

2. Respect change. It is hard. It does happen. You cannot always make it happen, especially on your own schedule. But sometimes, either before or after you want, people will change. And even in the direction you want, due (partly) to the efforts you made.   …Do not let yourself get depressed, do not give up.

3. Respect the people you are trying to change, and that, at least in some ways, their concerns are legitimate.  At least from where they are coming from, there is typically some internal logic to the way they think.  … I find this is hard, because I can so palpably feel the damage these people are doing. It feels like they are trying to be evil sometimes.  Certainly stupid. And I grow impatient.  But mostly there are not (evil); they are usually trying to do they best they know how.

4. Look (again) at the standard change books. Kotter’s books. Fearless Change by Manns and Rising. Others (if you prefer). Many great ideas about getting people to change.  Most of the following are discussed well and at length in these books.

5. Make the case. Repeat it often.  It starts with a Sense of Urgency.

6. A sense of urgency, to me, starts with one person having a passion that, dammit, things have to get better. And conveying that passion. Maybe in a quiet way. Certainly in a respectful way. But in more an emotional way than a ‘numbers’ way. Although numbers usually need to be in there as well.

7. Use some experiences. Maybe from articles. Maybe from nearby firms. Maybe from your own firm. Data of one sort or another.  There are tons and tons of great articles about lean-agile-scrum now.

8. Five books for managers.
Toyota Production System by Taiichi Ohno.
Radical Management by Stephen Denning.
The Power of Scrum by Jeff Sutherland et al.
Software in 30 Days by Schwaber and Sutherland
Drive by Daniel Pink.

9. Motivation. Often the key, I think, is they misunderstand motivation. Particularly motivation for knowledge workers. This is why I think Daniel Pink’s book is so useful.

***
Please comment here. I think this is a hard problem. If we knew the answer well, this problem would be a lot better now.  So please suggest better things.

We are also discussing this topic in the Agile Business yahoo group. Please join us.

Why our CSM (Scrum) course + Workshop is unique.

Posted on by
Reply

We believe our CSM (Scrum) course plus Workshop is unique.  And better.  For the following reasons.

1. We focus on results. We want you, your team and your customers to get real results. In a big way.  In 3 words, more satisfaction, more money, more fun.

2. Therefore the teaching style is not toward remembering explicit knowledge.  The teaching style is to enable you to change your own mind, so that you want to take action.

3. We focus more on ‘why’ each Scrum practice is done.  We think that this ‘music’ makes the dance steps of Scrum more powerful, more effective.

4. We have learned from 8 co-trainings with Jeff Sutherland.

5. We are more business-oriented than most Scrum trainers.  And still protective of the Team being asked to do a Death March and yet call it Scrum.

5. While we offer some serious challenges, and ask you to challenge yourselves and your company to truly achieve the results you deserve, we are also realistic.  We appreciate that Scrum will be tough. We offer sympathy.  But not too much.

6. Attendees say the Workshop converts the ideas of the course into action. So that the Team can get off to a good start.

Killing Babies or Sizzling Steak

Posted on by
Reply

I thought I would share this story, with one or two key metaphors.  Perhaps useful to you.  I use them in classes quite a bit.

***
OK, the PO is trying to optimize on the Pareto idea (80-20, the vital few).

At the beginning of the project, the team looks at the release plan and says: “OMG, if we try to get all that done by Aug 15th, we’ll die!”  So the PO, realizing that even more (new) work will be identified later, gathers the business stakeholders for a meeting.

“Guys [speaking to the business stakeholders], we have to cancel from the release the bottom 30% of the stories. We just won’t get them done, or at least can’t guarantee them by that date. And we know new stories will be identified by then. I need your agreement they won’t be in the Aug 15th release.”

They look at him in disbelief.  And then the BSHs (business stakeholders) get upset.

“What the…! You haven’t even started work!  I fought and fought with my team to exclude other stuff and I fought to get those babies in the Release. And now, before you even started, you want to kill my babies!”

Suffice to say, it is not a fun conversation and they don’t want to agree.

Now, I do think the PO should make them aware that getting all stories done will be a big challenge. And if the PO can show a true Pareto curve, it is a much better conversation.  But don’t try to get them to agree at this point. Too much pain, too little gain.

***

Now, imagine later. You have built two Sprints of the top stuff. You serve it up very seductively in the demo. You can see the top BSH drooling.

You say: “George, do we have all the top stuff built for you?”

“Well, I need story 23 and 47 too. But yes, this stuff is all the top stuff. And it looks good. I mean, aside from those missing stories, it looks…give me a second to wipe my mouth…it looks r e a l good.”

“After the next sprint, when we complete some other stories and stories 23 and 47…  George, how about we then serve you up some of this sizzling steak, fresh-off-the-grill? We give you a release then?”

“Well, how about the broccoli and the mashed potatoes and the creme brulee?”

“Yes, we can give you those later, in later releases.  And how about we release you the sizzling steak _now_ (well, next sprint)?”

Now it becomes George, and not you, who gives the other BSHs the look… “guys, I think this is the best for the firm… I need you to TOFTT and let us do this release now… you’ll get your stuff real soon.”

And he looks at Mary (the 2nd BSH): “Mary, we already have a bunch of your stuff in there too. What do you think?”

Mary: “Well, it does not have everything our group needs, but, yes, I think we could make use of what’ll be there by the next Sprint. Are we really gonna get the later releases?”

Geo: “I think so. Heck, they never had this much working software before by this time.  I think we can trust those SOBs now.  Sorry, Mr PO, I meant SOB in the nice-est way.”

Mary: “OK. How about the rest of you guys?”  ….

***

So, you can see that it is a totally different conversation. But with the same effect. That we execute and release more on the Pareto idea than on the 100% – 100% rule (where we often die in the death march).

And all because we served up the sizzling steak seductively.  We did not win on logic, but on the emotion of the drool.

Now, serving it up seductively is a fine art.  Seduction.  Well, there is Joe the geeky PO and then there is Casanova or Mata Hari. (Ok, yes, an exaggerated comparison…)  Do I need to ask which one is going to serve up the sizzling steak more seductively?  Thought not.

Now, one of the key benefits of the ‘sizzling steak’ technique is that the Team now has a better life (no death march, seen to be victors). Which means they are more creative. Which means everything should be better.

***
The story and the metaphors work for me. YMMV.
It does help if the key person is not a vegetarian. And even likes steak.

Later, they will say “Oh, yeah, I liked the story about the sizzling babies.” And then they will laugh.  But they might remember it longer.

Release Planning: Product Roadmap

Posted on by
Reply

I did a session today at the Atlanta Scrum Gathering about ‘Joe’s Approach to Release Planning’.  Jason Tanner asked “what about the product roadmap?”  And his question made me realize that I have not said enough about that.

My quick thoughts.

1. You need a product roadmap. For almost all products. Well, at least almost all the products I have worked with over 20+ years.  I suppose I am not an expert on iPhone Apps, for example. Maybe they are an exception.

2. What time span should the product roadmap cover?  Yikes. This is hard question with no perfect answer.  Longer than the implementers want to think about and shorter than the ‘planner’ type wants.  OK. For most products, about 1 year.  For fast changing, fast delivery products, less than one year, maybe even only 3 months (assuming say monthly releases).  For ‘big’ products, you might need multiple years.

3. The purpose of the product roadmap is not to be right. But to generate useful thinking about ‘longer term stuff’, and provide some context for shorter-term thinking.

4. YAGNI.  First, You Ain’t Gonna Need It has proven to be a pretty good principle.  Stuff happens, and all the knowledge created to go down path A is now useless.  This principle always tilts things towards less investment in longer term planning.  But of course, this principle is not the whole story.

5. Purpose: Human beings seem to be more motivated, seem to enjoy life more if they feel there is a purpose to their lives. And a product roadmap is an example of something that can and should be used to put things in the context of purpose.

6. Identify hard-to-reverse decisions.  Many decisions or actions are easy to reverse. Some are quite hard.  The harder a decision is to reverse, the more costly, the more it is worth some time to think about it and decide with a higher chance of being right.  A product roadmap can help us identify those kinds of decisions, and put them in a context.  For example, help us understand when those decisions must be made.  What I am saying here is very similar to the Poppendiecks’ ‘decide at the last responsible moment’ concept.

7. Practical. For a team just starting Scrum with a fairly normal product, if the group seems ok with it, I like to plan about 6 months worth of work (typically one or two releases, at least as initially conceived). And stop there for now. And start Sprinting.  And then later build out the rest of the product roadmap.

Why? Because they don’t really understand the power of agile and agile adaptive planning until they do Sprints. And until they do the Release Plan Refactoring.   It’s a think-do feedback loop. They need to experience it sooner.  Then, having that tacit understanding, they start to plan better with less BS. And with more purpose.

***
Comments?

John Kotter Explains the 8 Steps to Create Successful Change

Posted on by
Reply

Here is a slide show and voice over by John Kotter (our big expert on change) talking about how to get organizations to change.  Watch and listen here.  About 7 minutes.

Of course, your organization is smarter about change than John Kotter, so your colleagues do not need to see this.  (smile…I might have been sarcastic.)

In fact, my premise is that no organization is professional about introducing ‘different’ changes within the organization.  (Example: I don’t know Apple well.  I am impressed by how much their products have changed things. But I am far less confident about how well Apple itself has changed internally. Still, maybe they are the exception that proves my point. As a small example so far, they seemed to have adapted well to the new leader. Oh yeah, Tim Cook is his name.)

Taking Ideas on a Test Drive

Posted on by
Reply

I am a strong proponent of “show me the money.”

In other words, there are lots and lots of ideas that sound good. And only a relative few that are really worthwhile. And we only know by trying to put the idea into action.

But even this basic scientific idea is not complete. I would agree that not all ideas are subject to proof in a scientific way. Even though scientifically it might be proven that murder were ‘correct’, morally I still am going to think true murder is wrong.  (No, Virginia, we are not going to have a debate on all the possible situation and moral permutations of killing a person.)

Here is a WSJ article about a new book, Uncontrolled by Jim Manzi.  Haven’t bough the book yet, but the article makes it sound interesting.

And this is what lean-agile-scrum does. We try to do a series of small semi-controlled experiments.  To see if we are really on the right course.

If you have a problem reaching the WSJ article, contact me and perhaps I can send it to you.

A list summarizing Scrum

Posted on by
Reply

Revised May 6, 2012.

***
The list below is not self-explanatory, but it covers the key ideas one has to know and execute on to do Scrum professionally.  Of course, becoming proficient at doing them at the highest level (at the rugby World Cup level) is a lifetime’s work.  Rugby is a simple game with simple rules, but to reach the highest level of play is very difficult.

This list could be used as a starting point for defining ‘agile’ or ‘scrum’ in your firm. I am suggesting such a definition could drive useful conversations.  And it fits on one page (a key criterion).

A list that summarizes what Scrum is:

Roles:
Product Owner
ScrumMaster
Implementor (‘Dev Team’ role)

Events:
Sprint – 4 weeks or less.
Sprint Planning Meeting
Daily Scrum
Sprint Review
Sprint Retrospective

Scrum Artifacts:
Product Backlog
Product Backlog Items
Sprint Backlog
Working Product
Increment (of working product)
[Sprint Burndown chart]
[Release Burndown chart]
Definition of Done
[Public Impediment List]

Key Ideas:
Scrum is a process framework
Deliver business value faster
The Product Owner is maximizing the value delivered by the Team
Inspect & Adapt
Transparency
Self-organizing
7 plus/minus 2
Build iteratively and incrementally
Working product at the end of each Sprint
Potentially shippable product increment
Need for feedback
Always learning
Always adapting to good and bad change
Usefulness of high quality
Scrum hates technical debt
Knowing work remaining in a Sprint (daily)
Knowing work remaining in a Release (every Sprint)
Protecting the implementers from disruptions
Protecting the implementers from the Death March
The ScrumMaster drives the removal of impediments
Must add other practices (e.g., engineering practices) to Scrum to do work
Scrum does not include agile release planning (but you probably need it)
Scrum is consistent with the Agile Manifesto and Agile Principles
The Team should be having more fun (and be more creative)
Sprint Planning Meeting, parts 1 & 2.
The Product Owner orders the work in the PB; the implementers decide how much they can do in a Sprint.
Sprint Goal
Sprint “commitment”
The 3 Daily Scrum questions
Purpose of Daily Scrum: self-management
Demo working product & get feedback
Servant leadership
Chickens can help
Just-enough, just-in-time, documentation

***

Your comments please.

Here is the file: http://agileconsortium.pbworks.com/w/page/53405031/List%20summarizing%20Scrum

Release Planning: Effort (1)

Posted on by
Reply

Now we move on to Effort in Release Planning.

For those who have not been reading here before, this is a continuation of a series that starts here.

***
Estimating the effort of a Release Plan is not quite what I wanted to do in this part.  What I want to do is estimate the relative effort of each User Story that we have so far.

So, imagine that we have 50 user stories representing roughly (per gut check) about 6 months worth. Ballpark.

Now we have to do two things:
* Establish a Definition of Done for the Team.
* Do Planning Poker, which estimates a “story point” number for each user story.

Definition of Done

Stealing from Taiichi Ohno, I suggest we do this differently than I see many people do.

What others do is a list that describes what ‘done, done’ means once we get there.

Maybe they say:
* Coded
* United Tested
* Basic documentation written and reviewed
* Functionally tested
* Small regression test
* No bugs
* Product Owner Review (any issues fixed)
* No increased technical debt
* Promoted to the QA2 Server

What I don’t like is that there is no clarity how we got to this state. Or even if we really can get to this state.

What Taiichi Ohno proposed is that we ask the workers to write down the process that they currently use.

Once the workers do that, they themselves can see that it has weaknesses. And once the process is (more) visible, then everyone can help improve it. But especially the workers themselves will improve it. And so, they start to ‘own’ the process.  Which makes for better motivation. And better results.

Some in agile are concerned. Their concern is that we have locked the process in stone. And have made people into machines.

And this is actually the opposite of what we are doing.  We are making the process visible so that it can be improved.  So that it can be changed.  NOT so it will remain the same.  Now, by making the process visible, we do enable anyone who sees the process to open his mouth. And if the Team is not strong enough, then a ‘bad’ manager could try to force them into his process. But this seems unduly negative in the general case.

Let’s make our suggestion more concrete.

[Insert picture of sample DOD.]

So, before or during the Sprint Planning Meeting, the team can do many things to ‘get the stories ready, ready’. But what we want to estimate in story points are the things that happen during the Sprint.

We recommend that the first thing done in the Sprint is that we have a conversation about Story 1. The conversation, in classic form, is between the PO, the Coder, and the Tester. (Technically, with all the people with all the skill sets to get that story done, done.)  In this (short) conversation, all 3 people try to assure they are on the same page about the story.

Then we list everything that the Team says it can and will do to get Story 1 to a done in the Sprint.

In my opinion, the last step (or near the last) must be PO Review, meaning that the PO looks at the working product and gives feedback. If the PO feels the customer will not like it, he gives that feedback and the implementers must fix it. In the Sprint, in my opinion.

And anything done after the Sprint to make that story into something that can go in the live production product, all that work is listed as well. Below the line. And it represents, in my opinion, all the bad news getting better with age. But we have to accept that we can’t always get to “live, in production, in use by the customer” within the Sprint.

We think this approach to DOD gives much more clarity or transparency.

And starts the Team on the road to becoming more professional. And enables the Team to improve their own process.

***
In the next post, we will go into Planning Poker.