Category Archives: managing agile

Predictable project or innovative project?

Posted on by
Reply

Mike Cottmeyer spoke at Agile Carolinas last night. And said many good and useful things.

One thing he talked about is this:

What kind of project do you have?  At one extreme, do you have a project that is pure innovation?  Or, at the other extreme, do you have a project that it completely ‘predictable’, and the main problem is good professional execution?

By ‘innovative’ we mean that the project or effort starts off with barely a vision, and we discover ‘what we want to be when we grow up’.  Barely a vision, and only a minimal, inadequate sketch of the scope.  And we innovatively get a bucket of money to go discover some business value in that general area.

Predictable means that the managers feel, at least, that the scope and the business value are pretty well defined. They feel, at least, ‘this is clearly what I want you to do….just do it.’  Usually at a fairly high level, but in their minds, it is a known, predictable thing.  Nothing close to ‘pure R&D.’

Now, in practice, if you constrain a poet into sonnet format, give him a scope or domain of love and summer time, still, to him, he has realms and realms of room for creativity.  In fact, if you only said ‘write a poem’, he would be far less creative. But let is avoid for the moment the contradictions of creativity, beauty and innovation.

***

His (Mike Cottmeyer’s) main point is that in large organizations, the agile teams are given mostly more predictable projects.

I would state the same thing slightly differently.  But it is really the same basic idea.

There is a continuum.  At one extreme, we know everything up-front. At least all the features needed.  Down to the sprint-sized story level.  And, if we were truly good, and all other factors predictable, we could accurately predict when the product would be released, or the next release.  A lot more accurately.  Etc.

At the other extreme, we no knowing up-front. Everything can and will change.  Everything is unpredictable. So, virtually any up-front planning is useless.

Which raises the issue we are driving at.

How useful is any up-front work?

And Mike Cottmeyer says (or I say he says), and I agree, that in large organizations, we at least think we know a fair amount up-front.

So, I will say most projects are between 30% and 70% known on Day Zero. By known, I mean as an example that we could identify 30-70% of the detailed stories accurately.  If we took the time.

The key point: We know a damn sight more than zero. And still a damn sight less than 100%.  In my experience.

My conclusion: We must do some up-front planning. In a timebox.  And, as we learn, we must re-plan.  I call the ‘re-planning’….Release Plan Refactoring.

And we must help the Scrum Team, and any other layers or people involved, learn how to manage in this ‘partially known/partially emerging’ situation.

Part of the learning is how to become more predictable, at least at some level.  And how to manage innovation and disruptive learnings.  These may seem very opposite skills, but in fact they are similar.

But let me go back and say it again. If we know nothing today that will remain true through the effort, then almost any up-front planning is waste.  Maybe not completely, since we must acknowledge man’s irrational need to believe he knows and is in some control of the universe and his own life. So, even if we know nothing that will remain true, maybe, just to satisfy this human fantasy, we need to discuss some things upfront.  Or the morale of the team will suffer.  But mostly any upfront planning is waste.

Again, from the other side.  Any classic waterfall person or manager who de facto implies that we know almost everything upfront needs to be read a bedtime story and put to bed early.  That person is still a child, and we should get them out of the office.  They are a hazard. We never know enough to predict very accurately.

Will some effort on estimating and planning enable us to improve the probabilities of making some useful business decisions?  Yes.

Do we know enough to enable us as managers, in justice, to ‘hold the team accountable for their estimates’?  No, virtually never.  And to try to do so is usually foolish, counter-productive, immoral and rather stupid.

So, again, I think we are in a middle state. We know well more than nothing and well less than everything.  And, in both ways, we must accept the consequences of this level of knowledge of the future.

6 Myths of Product Development

Posted on by
2

I was going through the articles I have, and this one struck me.  A HBR article by Stefan Thomke and Donald Reinertson.  Reinertson is known well in the lean-agile community.  And it is an excellent article.  Go here to buy it for $6.  Well worth it.

Here are the myths or fallacies:

1. High utilization of resources will improve performance.

By ‘resources’ they mean mainly people. Speed of delivery is much more important.

2. Processing work in large batches improves the economics of the development process.

Hence, small stories in small sprints. And get fast feedback from business stakeholders.

3. Our development plan is great; we just need to stick to it.

For many reasons, during the course of ‘development’, the needed features will change. Hence, the plan must also change.

4. The sooner the project is started, the sooner it will be finished.

Reduce WIP.

5. The more features we put into a product, the more customers will like it.

Deciding what to omit is as important as deciding what to include.

6. We will be more successful if we get it right the first time.

Demanding that teams “get it right the first time” just biases them to focus on the least-risky solutions.

***

This article is good in helping managers see what lean-agile-scrum is all about.

 

Do high benefit/cost work!

Posted on by
1

Tom DeMarco wrote an article a while ago: “Software Engineering: An idea whose time has come and gone?” (2009)  I guess I am just catching up on my reading.

One topic is: are metrics useful.

I think the real issue is: how useful is it that we ‘control’ projects?

His comparison is:

1. If we have a project that probably will cost $1 million and returns a benefit of $1.1 million, then we must control cost carefully. Or the project will be underwater.

2. If we have a project that probably will cost $1 million and returns a benefit of $3 million, then some variance in cost is not important.

His contention (and mine) is that there is plenty of work in category 2.

This does not mean have no budget and do no planning. It just means that we should not look at planning and control as the main drivers of success. The main drivers are: identifying the problem well, and delivering a truly innovative solution.

Early Warning System

Posted on by
Reply

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.

Making Change Happen

Posted on by
Reply

I was delighted the other day to have a brief conversation with Mary Lynn Manns, who is the co-author of Fearless Change, an excellent book on making change happen.

And I told her I had this idea: We can let change happen to us. (This is mostly to be passive in the face of bad change.)  Or we can make change happen (the good change).

This dilemma was expressed by Shakespeare:

Whether ’tis Nobler in the mind to suffer
The Slings and Arrows of outrageous Fortune,
Or to take Arms against a Sea of troubles,
And by opposing end them…

We mean something slightly different.  Not just to oppose the negative changes.  But to advocate for positive change.

It takes guts.

I think, for many, it does not feel like guts. It feels like this: “I have to make this change happen, and I don’t care if I get nicked or scratched along the way.” The nicks and scratches are a ‘small price to pay’…is the way they feel.

Anyway, we are better people for making the good changes happen.  It makes us better people.

To make it happen, we must be by turns aggressive and patient.  By turns, emotional and thoughtful.  By turns, with laughter and with all seriousness.

How do we make this happen?

Well, this change and we ourselves are the stuff that dreams are made on.  There is no science here. But there are still many good ideas, and some of these ideas have been tried many times.  And in the hands of the professional, they are usually or often successful.

Mary Lynn Manns and others call them patterns.

The first pattern is Evangelist. That would be you.

The Evangelist comes up with the good idea (somehow).  (Hint: I think the first idea to implement is Scrum.)  And then starts to…well, to evangelize. To get others to try the idea.  To help the idea.

A couple of more patterns:

Ask For Help: The Evangelist asks others for help with the new idea. Maybe help defining it. Maybe help implementing it.  Maybe help evangelizing. Also, have you noticed how wonderfully seductive it is to be asked for help.  Who could possibly have more taste, brilliance, and acumen than the person who would ask me for help?

Innovator:  Usually you have in your group some Innovators. Ask them especially for help.  Get them on your side. In part, they are the ones most likely to have a positive attitude toward trying new things.

Just Say Thanks: Again, it is remarkable how a few bits of good manners can get people to go along with a new idea.  Saying ‘thanks’ for the help can…well, help a lot.

Step by Step: Some of us want to make one big grand change. And be done with it.  But the experience is that it is almost always best done, in some sense, step by step. One smaller change at a time. And they become added together into something quite big.

Small Successes: This is a similar idea, but somewhat different. As you have successes, even if small, be sure to celebrate them.  The small celebrations will delight the change’s supporters, and confound its enemies. (Mark Twain said: When in doubt tell the truth. It will confound your enemies and astound your friends.)

***
In the book Fearless Change, Mary Lynn Manns and Linda Rising have gathered much more detail on these patterns. Indeed, on a total of 48 patterns.

You will find patterns you have done (but probably not done recently).  You will find patterns you have heard of other people trying (but you have never used). And you will hear of completely new patterns.

The main problem is: use one pattern each day.

I think, if you do that, you will win.

Release Planning: Effort (2)

Posted on by
Reply

Now we come to the point of describing Planning Poker.

This has been done before, we will be brief.  It is described at greater length many other places.

***
Some basic characteristics:
* We find the 5 best experts on effort for this work.  In all most all cases, this means the team of pigs.
* Usually the Business Stakeholders (as I call them) will not stay around for this work.  This is ok. Not ideal, but ok.  We will bring them back in later.
* We use the planning poker cards with the Fibonacci scale.
* The approach is wide-band delphi.  Delphi means we use the best experts we can find. Wide-band means that we allow the experts to talk and learn from each other.  This bears strong resemblance to the knowledge creation ideas from Takeuchi and Nonaka.

The basic technique

We have 4-7 experts.  These are typically the people who will be building the product. We try hard to get all of them, so that none of them feels left out.

The Product Owner is typically not one of the voters, but he/she is there. The PO has to make sure that the team is understanding each story correctly.  Typically the PO is a business person and in any case is representing the Firm and the Customers.  So, when those kinds of questions come up, he must be there to give them the best possible assumption to work with.

The ScrumMaster (SM) is there to facilitate the meeting or the work.  Ex: To try to get the quiet ones to talk more and the talkative ones to talk less.

In this discussion, we will assume all the PBIs (Product Backlog Items) are in the User Story format, so we will call them stories.

The Experts must now choose the reference story.

Imagine that the team has 50 stories that cover about 6 months worth of work.  The Experts choose from that set the smallest story.  Well, except that it should not be too small. Ideally it is about 1 ideal person day (after adding together all the ideal hours from all the required skill sets).

The reference story is arbitrarily given a 1. Meaning, it has an effort value of 1 Story Point.

Note: For those who are just reading this post, an earlier post talked about how the Team must have a strong DOD (definition of done). The DOD should make clear what things are being done in the Sprint to get the story ‘done, done’ as we often say.  So, it is the effort of these things that we are estimating.  Earlier we talked about a minimal DOD.

OK, now the team estimates the relative size of all the other stories in comparison to this reference story.  This happens in this way:

Select the (next) highest value story.
Discuss it briefly to assure everyone understands it the same way. PO describes story. Experts ask him questions.
Someone asks “any more questions?”  If no….
Each Expert privately selects a Planning Poker card that best represents his feeling of how much bigger the new story is in comparison to the reference story. For example, if 7 times bigger, the choice is between a 5 card or an 8 card.  Likely, the 8 card will be chosen…
If all Experts are within 3 cards of each other (eg, all have either a 5, 8 or 13), then average the numbers. Example: 5, 5, 5, 8, 13 …. averages to 7.
If the Experts’ votes are more dispersed (ex: 3, 5, 8, 13, 20), then the two extremes talk (mostly). In this example, the person with the 3 and the person with the 20 both talk about their assumptions, etc.  If the assumptions are business-related, then the PO can decide which assumption is correct.
With the new information, each Expert votes privately again.
Voting and discussing can go on a couple of rounds.  Almost always, the final answer for a card is the average after the Experts get within 3 consecutive cards of each other (Ex: votes are 2, 3, or 5).
Once the number is decided, it is written on the card (story) in such a way that everyone knows that it represents the story points (color and placement on the card usually make that clear).

A few additional comments:
The discussion is actually the most valuable thing.  The numbers drive a better conversation about the more important stuf
Sometimes important assumptions are identified. In that case, the assumption should probably be recorded (eg, on the back of the card?). Later, if we discover that the assumption is incorrect, we can refactor the story points for the related stories.
Sometimes the Experts will want to address certain general issues.  Issues might be architecture or design related. This is where the SM has to use good judgment. Typically let them discuss for ‘a while’ but not too long. Maybe make one or two drawings.  Make and document a few assumptions, and then get back to Planning Poker.  Sometimes one or two people on the team want to discuss these issues too long. In this case, the SM must use good judgement and get the Experts back to planning poker.
You will  hear of people suggesting that the Experts must agree on 1 Fibonacci number (eg, 8) for a given story.  This is _not_ recommended.  First, it gives a strong incentive for people to too quickly start to shade their numbers, rather than vote what they really think.  They find that George, the senior guy, is stubborn, and to avoid conflict and to keep things going, they decide, almost subconsciously, to start voting a closely to what George says as fast as they can.  The research shows that the average is more likely to be the correct estimate. And it actually takes less time to reach that number (if everyone is voting honestly).
Usually one or two new stories are identified while we are doing planning poker. This is normal. Occasionally it turns out to be the most important story.

At the end

It usually takes about 1.5 hours to estimate 50 cards well.

Once all the cards have been estimates (for effort), all the cards should be put on the wall. And then the whole Team should gather around. And see if they can identify one or two ‘stupid’ cards.

It is very common that 2 or 3 stories that were estimated early on will need to be re-estimated, in the team’s opinion.  This is fine, good even.  And normal.  They know, as a team, are much smarter than when they started planning poker.

Cost-benefit analysis

Now one or two people in the team calculate the R ratio for each story.  BVP divided by SP.  For each story.  The R should not be more than one decimal place.  This gives:
the low hanging fruit
the bang for the buck
the return on investment
..however you want to put it.

We next suggest that the PO organize the story cards based on the R number. Highest R first.  Lowest R last.

We ask them: What do you think?  Is this the right way to do the work?  Often they say: Well, it is a good start but we need to make some changes.  Which is 99% of the time, the right answer in my opinion.

What ideas do we use to re-order the work?  More on that in a post soon.

The importance of a real team

Posted on by

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.

What to do with managers?

Posted on by

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.