Ripping the Planning Out of Agile

October 10, 2014

needle-31827_640

Recently I was following some twitter feed about #NoEstimates. I’m no expert, but it seems to be a conversation about the fundamental value, or lack of value, that planning provides to teams. What they seem to be arguing is that planning represents a lot of wasted effort that would be better spent elsewhere.

Fundamentally I would have to agree. I’ve wasted a tremendous amount of time arguing about story points, burning down hours, and calculating person days – all for what seems like very little benefit.

What I would rather do is spend more time talking about the problem we are trying to solve. I really value a deep understanding of the system and the changes that we intend to make to it. If I have that much, then I’m well situated to deliver fast enough that nobody’s going to give me much grief about not having estimates. That’s my theory anyway. The sooner you can deliver working software, the sooner people will shut up about estimates.

But often we never do talk about the problem at anything other than a very superficial level. We spend most of our time trying to size the effort according to some artificial schema that has nothing to do with the work or any real empirical evidence at all.

So what if there were no plan? What if we took Scrum and did everything but the planning? You show up Monday morning and you have no idea what you are going to work on. The team sits down with the customer and talks about their most pressing need. They work out what they need to build, make important design decisions, and coordinate among themselves. At no point are there any hours, or points, or days. What would happen to the cadence of the sprint if we removed the planning? Basically, we would have our daily standup, and then we would review our accomplishments at the end of the sprint and look for ways to improve.

That sounds pretty good actually. Like anything else, I’m sure it has pros and cons:

Pros: Save time and energy otherwise wasted on estimation, and use that time instead for important problem solving work.

Cons: Stakeholders really like estimates. It’s like crack. They start to shake and twitch if you take their estimates away. Not many will even let you talk about it.

It might be worth a try sometime. It would certainly make an interesting experiment for a sprint or two. What if the sprint were focused entirely on the improvement cycle instead?

Advertisements

Coping with a Fear of Inaccuracy

September 24, 2014

“Even imperfect answers can improve decision making.” – Donald Reinertson

When I read this from Reinertson’s book on flow, I realized that I had found the reason that people have so much trouble with story points. It’s a matter of overcoming their fear of inaccuracy. They are under the misguided belief in the accuracy of using hours or days to estimate work on projects. They’re basically afraid of being wrong (aren’t we all?) and that is the source of a lot of resistance to change. Being wrong sucks. I get that. Nevertheless, I’m wrong a lot.

Fortunately, wrong isn’t always boolean (unless you happen to step in front of a swiftly moving bus). There are shades of wrong. You can be just a little wrong, your aim just a little off, and still be headed in the right direction. Or you can be a lot wrong (the bus). That’s where frequently re-examining your decisions can help you catch the stuff that’s a lot wrong and fix it. What about the stuff that’s a little wrong? Don’t sweat it.

In the software world, a little wrong is still pretty useful. There is a tremendous amount of error and missing information. Compared to that, being slightly wrong isn’t so bad. Being slightly wrong gets you started – at least in mostly the right direction. You’re going to fine tune it anyway, so there’s really no need for decision making precision. That will come later, when you know more.

To me, the ability to overcome our fear of being wrong stems from an all-or-nothing mindset. We can’t allow ourselves to be even a little wrong for fear of failure. As Reinertson rightly points out, there is a time and a place for precision in decision making, but it’s not ALL the time.


Planning Feedback: Don’t Panic!

September 9, 2014

Ring the Alarm

So the other day a VP asked our team for an estimate on a project. Now, putting aside whatever feelings you may have about the usefulness of estimates, we did a little planning, a little investigating, a little debating, and came up with an estimate for the project. I brought the estimate back to the VP and then the fireworks began. Apparently he had been thinking of a different number than we had given him. He wanted it done in half the time that we had forecast.

Whoops.

Now at this point in the story a lot of teams will panic and come back with one of two reactions:

  1. Fight – “We can’t do that! That’s not Agile” (or some variation on that tired theme)
  2. Cave – “We have no choice…”

But wait a second, there is a middle path. You can agree, but ask what can be compromised in terms of scope or other project constraints. You see, a new project is not just a learning process for you. Its also  learning process for the customer too. When  you get that first feedback, DON’T PANIC!

There is one important part of the planning process that I often see get lost: iteration. Doing a single round of planning and then presenting it to your customer as “Take it or leave it” isn’t what I’d call much of a dialog.

What we should be doing is some lightweight planning then review with the customer. “That’s horrible!” They cry, and then you say, “So what number were you thinking of?” And they return with something totally preposterous. OK, that’s cool. “Is there functionality we can drop to hit that date?”

No.

Of course not. So you go back, you scratch your head, cut out all the fluff you can find…and you still are way off the desired estimate. So then you take it back to them and say, “Hey look, I know this isn’t what you wanted, but here is the ABSOLUTE minimum we can get away with.” At which point, the customer looks at you with a tear in their eye and says these magic words, “What CAN you give me?”

Now you have a real negotiation! It may not always play out this way, but hopefully you get the point. You can’t freak out when they give you that first reaction. Stay cool – this is the first time they’ve had to test their fantasies against your capabilities. They need to learn too. So give your stakeholders a chance to work together with you on figuring out just what is possible. Negotiate. The more iterations you go through, the better your chances of coming to an agreement that everyone agrees is the best.


If Everybody’s Happy, You’re Doing It Wrong

August 11, 2014

So there you are, wrapping up another successful release planning session. Sprints are all laid out for the entire release. All the user stories you can think of have been defined. All the daunting challenges laid down. Compromises have been made. Dates committed to. Everyone contributed to the planning effort fully.

So why isn’t everyone happy? Let’s check in with the product owner: The product owner looks like somebody ran over his puppy. The team? They won’t make eye contact and they’re flinching like they’ve just spent hours playing Russian roulette. What’s up? Well, here’s the dynamic that typically plays out:

  • The product owner has some fantasy of what they think they will get delivered as part of the release. This fantasy has absolutely no basis in reality, it just reflects the product owner’s hopes for what he/she thinks they can get out of the team (it’s just human nature). This is inevitably far beyond what the team is actually capable of. My rule of thumb? A team is typically capable of delivering about 1/3 of what a product owner asks for in a release. That’s not based on any metrics, its just an observation. However, more often than not, it seems to play out that way.
  • The team is immediately confronted with a mountain of work they can’t possibly achieve in the time allotted – even under the most optimistic circumstances. It’s their job to shatter the dreams of the product owner. Of course, strangling dreams is hard work. Naturally enough, the product owner doesn’t give up easy. They fight tooth and nail to retain any semblance of their dream.
  • After an hour, perhaps two, maybe even three or four (shudder), the battle is over.

I’m going to go out on a limb here and speculate that this is no one’s idea of a positive dynamic. But it seems to happen pretty often with agile projects. It sure doesn’t look like much fun. I’m pretty sure this isn’t in the Agile Manifesto. So how do we avoid this kind of trauma?

  • The product owner needs to be a central part of the team. They need to live with the team, be passionate about the product, and witness to what a team does daily. Fail to engage in any of this and a product owner loses touch with the work the team does and loses the ability to gauge their capabilities. Doing all of this is hard. There’s a reason that the product owner is the toughest job in Scrum.
  • The team needs to embrace their product owner as an equal member of the team. You have to let them in. Work together. Let go of the roles and focus on the work.
  • Prepare for the release planning in advance. There is no reason for it to be a rude surprise. Spend time together grooming the backlog together. As a team.
  • Don’t cave to pressure from upper management. Behind every product owner is a slavering business with an insatiable desire for product. Ooh, did I just write that?

Release planning doesn’t have to be a nightmare. OK, in theory…


Paired Presentations

May 15, 2011

Often when people talk about public speaking, they are typically referring to an individual speaker. You don’t see much advice for people who present in pairs. When it works out, it is a beautiful thing where the whole is greater than the sum of the parts. When it fails, usually one speaker or the other takes the brunt of the damage. Here are some things that I recommend doing to insure a paired speaking engagement is successful:

  1. Keep it simple and let each speaker own a portion of the presentation on his or her own. This avoids a situation where one person does all the talking and the other just chimes in from time to time. I feel that both speakers need to be perceived by the audience as experts in their own right. It doesn’t even have to be a large section of the presentation that you own – just some section that is all yours. I feel like this works well with people who are new to presenting – I can include them for whatever period they feel most comfortable. The anti-pattern here is where a second speaker in a pair only chimes in from time to time. This leaves them only offering the occasional comment. This can leave a perception of that second person as interrupting the first speaker.
  2. Rehearse together – I know it’s hard to do, but you will both find weak areas in each other’s material. When I’m working on speaking material, I tend to get these ideas that I think are totally brilliant. We’re talking about genius stuff here. I can’t tell you how often I have shared this brilliant material with my partner only to discover that it falls completely flat. It must be an echo chamber in my skull (it is empty anyhow). Better to have a lame idea shot down by my partner than some poor unsuspecting audience. Often, the idea just needs refinement.
  3. The 3 secrets to a good presentation with a partner? Support. Support. Support. Focus on the other person in your presentation. If they rock, then you both are very likely going to look brilliant. If they suck, you haven’t got a chance. Be there to encourage them when the practice doesn’t go well. Be there to provide ideas and alternatives. Be patient when they are struggling and time is running short. Make them feel welcome and like a key contributor.
  4. Have a victory celebration afterward! It’s not often that I get to share a presentation with someone. Two people qualify as a party in my book, so go for it! Celebrate the accomplishment! It’s a big deal when two people can collaborate together successfully to provide a rich experience for an audience. Not many people can do it well.

I’m sure there is a lot of good advice for people who are co-presenting and I’d love to hear it. These are just a few things that I’ve learned by trial and error (a lot of the latter).


On Human Thought and Planning

January 3, 2010

Over the holidays I’ve been reading “The Design of Everyday Things” by Donald Norman. It’s a wonderful read, but dense – it’s definitely “armchair and a pipe” material – you can’t rush it.  I came across this interesting quote regarding the nature of human thought:

But human thought – and its close relatives, problem solving and planning – seem more rooted in past experience than in logical deduction. Mental life is not neat and orderly. It does not proceed smoothly and gracefully in neat, logical form. Instead, it hops, skips, and jumps its way from idea to idea, tying together things that have no business being put together; forming new creative leaps, new insights and concepts. Human thought is not like logic; it is fundamentally different in kind and spirit. The difference is neither worse nor better. But it is the difference that leads to creative discovery and to great robustness of behavior. [p.115]

In this paragraph Norman is talking about the fickle nature of human thought. When he refers to planning as a close relative of human thought, I couldn’t help but think of project planning. As Norman suggests, human thought is not the orderly process we might like it to be. If that is the case, then project planning is not the neat and tidy system that some people would like to sell you. If thought and planning are truly akin to one another, as Norman suggests they are, then I would suggest that any system that attempts to turn planning into some sort of logical, deterministic process is destined to fail. The intriguing idea here is that planning needs to accommodate creativity, intuitive leaps, non-linear processes.

I think there are a lot of people who grasp this notion, and I think there are many others who have a great deal of difficulty with it. Those who don’t accept this notion tend to try and wrap more and more layers of process around the problem. Those who accept the need for creativity and intuition in planning – people who are more comfortable with uncertainty – are more likely to treat the planning process as a dance: You know what the steps are supposed to be, but you are prepared to change at any moment.


The Planning Meeting from Hell

May 13, 2008

I was facilitating a planning meeting with the team a week ago and it was not going well. We had our stories all ready to go before the meeting. The stories were well formed. All we had to do was come up with a list of tasks for each story. How long could that take? An hour?

An hour later we finished the first of nine stories. It had taken us an entire hour to identify 3 tasks! It was like pulling teeth. I’d ask the team to provide a list of tasks…silence. I’d take different approaches, “how do we break the story down?” I’d suggest different kinds of tasks…silence.

I swear to God I don’t beat my teams with a stick. But the silence was ominous. Why couldn’t they come up with even the simplest tasks? I racked my brain trying to figure out what I was doing wrong. Was I intimidating the team? Was someone else?

Then it hit me. They didn’t know the architecture of the product! Of course they didn’t know what tasks they would need. They simply had no clue! I spent the next week working to make the architecture of the system visible to the team. Information radiators with diagrams of the static class design. Interaction diagrams, you name it. The next time we had a planning meeting, the tasks came quite naturally.