Private Estimates, Public Progress

I remember back when being on one of those gigantic, long-lived software projects when I was a wee programmer. Professional project managers had laid out the entire thing before we started coding. Enlightened professional project managers—they only assumed 4.2 hours of coding per programmer per day.

When the whole thing was axle-deep in mud about two thirds of the way through, some bright person realized that we could restore the “deadline” by increasing the coding schedule to 5.3 hours per programmer per day. Never mind that everyone was already going flat out. Change one number & everything was “alright”. For now.

I draw a merciful curtain across this story. You can guess the rest.

One lesson I took from this episode was that playing with the map didn’t change the territory. Another lesson was that for every reality-defying management move there is a counteracting engineering move. And for every reality-defying engineering move there is a counteracting management move.

Inside A Week

As I’ve started to publicly reiterate many of the themes of Extreme Programming (XP), I’ve started receiving the same simplistic ad hominem criticism that made the last time around so much fun. “You’re just anti-accountability”, “you just want everyone to take engineers’ word for everything”, “you’re anti-measurement”.

I’m not going to pick apart the fallacies involved, so I’ll just say, “Huh uh”. I’m interested in exploring ideas that work. So, here’s a planning process that works.

On Monday morning the whole team (engineering, product, customers, testers, designers, managers, marketing, sales, whoever is on the team) & answers the question, “What is most important for us to accomplish this week?” Then ask, “What can we actually accomplish this week?” Figure on that.

On Friday afternoon (or Thursday if that’s the end of your week) get together & say, “How did we do? How did we react to surprises? Customers, how are you feeling? Engineers, how did the work flow? Product, how are customers acting in aggregate? Designers, how did your work flow & how are customers reacting? Sales, marketing, support—sup? Everybody have a great weekend. Get some rest. See you Monday!”

Consequences

I’m proposing an investment here. You’re going to spend an hour or two on Monday & another hour Friday, almost a tenth of your available hours. What do you get?

• Energy. A team used to delivering comes to work ready to deliver. Aren’t delivering? Sign up for less.

• Scope. You create value by answering the question, “I need to do this. How much of this do I need to do right now?”

• Collaboration. “Oh, we’re adding a field to Contract? I’ll work with you on that because I did it last time.”

• Alignment. Everyone can see & negotiate each others’ priorities. This isn’t easy. It takes building & maintaining relationships across sometimes-divergent incentives, personalities, & perspectives. If it was easy, regular people could do it.

• Adaptation. If scope is falling short of desire, I’d rather know that today & communicate that today rather than sacrifice all the above benefits maintaining a lie.

Don’t

This kind of weekly rhythm & habit of delivery takes months to build. Once it’s in place it tends to continue, but it’s also fragile. You can send it back to the waterfall death spiral easily. Please don’t:

• Add weeks up. Weeks aren’t additive any more than recipes are additive. “I like oatmeal chocolate chip cookies. I like ceviche. I’ll add them together!” Doesn’t work like that. “How much will we get done in the next quarter? Let’s add up the last 13 weeks.” Whether you use story points or time tracking or fibonacci or task counting, the answer you get from, “What’s this week’s worth of work?” doesn’t combine with any other week, any more than you’re eating lime chocolate chip halibut walnut cookies.

• Compare weeks over time. Weeks aren’t fungible. You can’t use the numbers from a month ago to make any confident conclusions about how you’re doing today. Observe. Judge. Experiment. But ffs don’t say, “You only delivered 12 story points last week, down from 18 the week before. Get back up to 18 or heads will roll!”
  You’ll never get another honest plan or report after that.

• Compare weeks across teams. Whatever process a team uses to ask & answer, “What’s this week’s worth of work?” doesn’t compare to another team’s process. Even if they seem to use the same mechanism, they aren’t. My delicious meal is your light snack. (All these food metaphors are reminding me I need to eat breakfast.)

Scenario: VP Demo Friday

Nick Maravich was good enough to send me the following scenario:

When the SVP has a meeting on Friday which depends on 2 or 3 items in the backlog getting done and it is Monday - what is the right message here?

First question, what does the SVP do now if Friday comes & all 3 items aren’t done? That happens, right? The SVP adapts the meeting. It’s not like they expect you to be perfect. Not in their heart of hearts.

We say, “3 items” like that’s a fixed quantity, like “3 kilograms of bologna” (again with the food). It’s not a fixed quantity. We will discover what scope matters & what scope doesn’t as we go along.

Okay, so what do we do? Ask, “Which item would you like to see first? Let’s demo that together on Tuesday.” What’s the least of item 1 that would allow the SVP to add value? Okay, maybe that’s enough of that for the Friday meeting. Get started on 2. Demo that Wednesday. Oops, it’s going to be Thursday.

The best we can possibly achieve is as much of the most valuable stuff by the time the Friday meeting starts. Let’s see how close we can come to that.

What if I convince the CFO to support Agile Delivery, but they are asking about deadlines and doing basic math on backlog items? I think this can be done - I think it is ok to do math and arithmetic on backlogs. If and only if I have the right Business Partners that are willing to partner with Agile Delivery and not sabotage it ... knowingly or unknowingly.

I would ask them why they are doing math on backlog items. We’ll never implement all of them. Never. We’ll implement the most important ones. Meanwhile new ones will crop up.

Deadlines are mostly just lines. Nobody dies. If someone wants to say, “By next quarter we’d like X users,” then we can work towards that. Or, “We’d like revenue to be like this,” or, “Costs to go down like that.” Those seem like fine, shared goals. But if the CFO is saying, “Story points per programmer per day needs to improve by 15%. Or else!” then I think they have better things to focus on.

I’m not asking to be trusted. I’m not asking to be let off the hook. I’m asking to work toward shared goals everybody cares about & to be left all the tools in my belt to reach those goals. I think, sweet naive geeky me, that this would be better for everybody.

If I fail to convince the business partners that Agile is pro business then Waterfall wins again.

Our development practices are the shadows cast by the power structures of our companies. We can invite folks to a new power structure but then they get to choose. And if waterfall development is all they need to get their needs met, well, waterfall is what they will get. I just don’t have to participate.