Susan Prior drops in on Kate to talk about some new products she would like developed.

“Hi, Susan,” said Kate. “You wanted to talk with me?”

“Hi, Kate. Yes. I’ve got some product ideas that I think we should invest in, and I wanted to talk with you about getting started. Dan is interested and said I should get your input.”

“Sure. What’s up?”

“There are three new products I’ve been talking about with my people and with customers. They’re all getting good reactions from prospects we’ve talked to. I think they would each bring us about a million dollars in the first year after release. I can show you the figures.”

Susan and Kate went over the figures, and talked about the three projects, which were codenamed Emerald, Obsidian, and Ruby.

Kate said: “The revenue looks good for each of these. What do you know about costs?”

“Gil and Jim looked at the specs and agreed that each one of these is about 15 person-months to develop.”

“OK,” said Kate. “What are you thinking you’d like to do?”

Susan said, “I have three people in Marketing who are working up feature stories. I would be the official Product Owner on all three, at least through first release. Development can free up six people soon. I’d like to get those six people committed to these projects for nine months to a year to get the products out.”

“Hmm. How did we get from 45 person months to 72 all of a sudden,” Kate said. “That’s a lot of money, from 375,000 to 600,000 dollars.”

“Well, I figured in a little extra in case Gil and Jim under-estimated, or in case they are late.”

“I understand, though I’m not sure I agree. And why are you going for all the money and time for all three projects at once?”

Susan said, “These are all important and valuable projects. We should get them all under way right away.”

“You’re asking Development to work on all three of them at once? Two people on each or something?”

“No,” said Susan. “Gil and Jim say the critical mass for each product is five or six. So I’ll have the team work on all three products.”

Kate put on her confused face. “All three? Wouldn’t it be better to work on them one at a time? Most important first?”

Susan said, “No. They’re all equally important and equally valuable. They should get equal priority.”

“Equal? Are you sure?”

“Well, as closely as we can tell,” said Susan. “Each of these projects takes about the same amount of time and will bring in about the same revenue flow. So they should get equal priority.”

Kate said: “Let’s test that thought. What if we could only afford one? What should we do?”

“I knew you would do this. This is my chance, and you want to wreck it. You’ve always hated me ever since the beginning.”

“Calm down,” Kate said. “I don’t want to wreck anything. And I don’t hate anyone. I can’t afford it, it poisons my soul. I just asked a question. What if we could only afford one? What would be best to do? Would you like to take a break to think about it?”

Susan steadied herself. “No, I’m OK. I’m just so excited and scared about this. These ideas are really good. They could make a difference to the company and I can show what I can really do.”

“I’d like that, too. You got off to a bad start with the team on Empire. But I know they are willing to work with you on this,” Kate said.

Susan asked, “You know? How do you know?”

Kate laughed: “I know almost everything around here. People tell me things. I think it’s because I spend so much time in the coffee room.

“Gil and Jim have both said, several times, that they respect your ideas and would like to see them get implemented.”

Susan calmed down some more. “They did? They never told me.”

Kate laughed again. “They’re programmers. They never say anything personal to anyone. It’s their job.”

“Good point. Anyway, if we could only do one, it should be Obsidian.”

“Why Obsidian?”

Susan said, “Three reasons. It’s a bit simpler, the prospects we have talked to seem more enthusiastic about it, and we understand it better.”

Kate thought, then spoke. “Those seem like good reasons. Thanks. Now, thinking again about doing these as you propose, let’s look at some pictures.”

This time Susan laughed. “I knew I could never get out of here without pictures.”

“It could be worse. I could make you listen to me singing. OK. Let’s look at a nine-month plan.”

“OK,” Kate said. “Here’s a planning area. We have the three projects, Emerald, Obsidian, and Ruby. They’re all about the same size in stories, and you’re planning an ideal nine-month project. I won’t show any contingency here, just for clarity. OK?”

“Yes,” said Susan. “We may need the contingency, though.”

“Don’t worry, we’ll talk about that later. Now here is the way features will grow over the nine months, according to plan.”

Kate added feature lines to the chart:

Kate went on. “The features all grow at about the same rate until the projects are all done after nine months. That’s the starting picture, agreed?”

Susan nodded. “Yes, exactly. The developers would work in parallel on all three products”

Kate said, “In parallel. Why is that good?”

“So we could see progress on each product.”

“And why do we need to see progress on each product?”

Susan thought. “Well, so that if anything goes wrong we can do something about it.”

“OK, I guess. Now when do we start making money from these products?”

Susan said, “If it goes according to the plan there and we don’t need the contingency, we start making money shortly after the nine months is up.”

“Shortly after,” Kate said.

“Well, we would have to roll them out with advertising, documentation and training and such.”

“Those couldn’t start sooner?”

Susan said, “Well but what happens if  the developers are late?”

“You keep asking that,” Kate said. “In my view developers are never late. Products are late sometimes, but never developers. I suppose that sounds like crazy talk.”

“Frankly, yes,” said Susan.

“OK, we’ll defer that for a moment. Returning to the picture, we start earning money at three million a year, starting nine months out, is that right?”

“Yes, that’s right,” Susan said.

“OK. Now take a look at this drawing instead.” Kate erased some lines and drew some new ones:

“Susan, now I’m drawing a picture of what happens if we do the three projects one at a time. The new vertical lines are three release dates, at three months, six, and nine.”

Susan said, “But what about contingency?”

“I’ve left that out, as I did in the previous picture. We’ll talk about it though, don’t worry. Now in this scheme, we focus the developers on first Obsidian, then Emerald, then Ruby. Look what happens to Obsidian development:”

Susan said, “Yes. It gets done right away. But the others aren’t even started. That’s risky, isn’t it?”

Kate said, “I’m not clear on why it would be, so marshall your thoughts. But tell me what happens to company revenue with this scheme.”

“Well, we start earning after three months instead of nine.”

“Do we make more, or less, or about the same,” Kate said.

“About the same. Maybe more, because we are in the market sooner and might get more early adopters.”

“What about the impact on this fiscal year, and on our ability to fund projects?”

Susan scratched on a scrap of paper for a moment. “Well, we’d be to market six months sooner and in the first six months I think we get about 40 percent of the 12 months revenue for Obsidian. If we start right away, that would all fall in this fiscal year.”

“Yes! That would be $400,000 and that’s just about the low-end cost estimate for all three projects. What does that do to our concern about deferred risks for Emerald and Ruby?”

Susan thought. “OK, I see. Total cost of those two projects is scheduled to be less than $300K. Even if they completely failed, Obsidian’s first six months revenue would cover the costs. But again, what if development can’t get Obsidian done in three months?”

Kate smiled. “Go with me a bit longer while I finish this picture. Here’s the picture of the other two projects getting done sequentially after Obsidian:

“So here I’ve just assumed we’ll do Emerald next, then Ruby. It could be done the other way. So Emerald is done after six months. What happens with revenue there?”

“If things go according to plan, we think Emerald would bring in about 150K in its  first quarter out,” Susan said.

“Yes. So even that revenue is a big chunk of the cost of doing Ruby, and of course we’re already covered by Obsidian. So by the end of the three projects, we would see $500,000 in revenue, and it would all fall into this fiscal year. And the total cost of the projects you are asking for is around $375,000 if we use the development estimates. Even with six developers, we are looking at expenses of about 3/4 of 600K, or 450K for the nine months. See the difference?”

Susan stared for a moment. “Yes, sure. Done your way, the same projects actually break even this year or earn a small profit. Done my way, we spend $450,000 before we get anything.”

Kate said, “Let’s not think my way your way. Done in parallel, the projects burn through almost a half a million dollars this year. Done in series, they burn $150,000 in the first quarter, then start earning back, and we are back to even by the end of the fiscal year.”

Kate smiled. “If it was your money, Susan, which way would be ‘your way’?”

Susan said, “I get it. My way is to do this in series. That’s what I recommend. Yes, totally. I’m sure that’s what I meant all along. Serial.”

Kate laughed. “I thought so. It’s almost lunch time, are we done for the morning?”

Susan thought. “I think so, yes. I’d ask to have lunch with you but I need to think a bit first. I’m still worried about contingencies and risks.”

“Good,” said Kate. “I’d like you to think about that. As a hint, think in terms of what you can do as Product Owner to manage the risk. But keep in mind it’s your money, and you can just barely afford the $150K a month for your six developer team.”

“That’s scary,” Susan said. “I guess that’s what you feel all the time?”

“Well, it’s the problem I have all the time, Susan. But I’m not very scared. See if you can figure out why. When shall we meet again?”

“I’d like to come in again tomorrow, if that’s OK,” said Susan.

“Sure thing,” said Kate. “I’ll be here. Thanks, this was fun.”

“It was,” said Susan. “Oddly enough, it was. Thanks, Kate.”

“You’re welcome, Susan, and thank you. We could use another three million in revenue.”

A pizza of radius z and thickness a has volume pi*z*z*a

Per Jens Ohlig, twitter “johl”

“Kanban is better than XP because Kanban has more WIP.”

“XP is better than Kanban because in XP we have actual programming.”

Sometimes it seems that all this revolves around personalities. I know of a small number of people who appear to me to think Scrum is bad because they don’t like Ken. There must, therefore, be hundreds of people who think XP is bad because of Yours Truly.

Is It Still Scrum If …

Trouble with clouds is that they change. They even run into each other as the wind blows them around. That cloud you stupidly thought looked like a bunny ran into my cloud that looks exactly like a dinosaur. Now it looks totally like New York, and you foolishly  insist that now it is a big dinosaur-eating bunny.

“Is it still Scrum if we use a kanban board instead of a burndown?”

“Is it still XP if we don’t break things down into tasks but just use stories?”

Who the hell cares???

The question we ought to be asking is whether, if we adopt this idea from wherever we found it, will we do better than if we adopt this other idea. The absolutely best way to determine this is to try it. We can get ideas from experts, even if they happen to be proponents of Other Named Clouds Which Shall Be Anathema.

Ad Processem: A Continuing Kind of Fallacy

The process wars have gone on more than long enough.  It doesn’t matter who had an idea, or what process originally contained an idea. What matters is what ideas we apply skillfully and wisely to our situation in order to improve it.

I’ve been helping software development teams improve for a long time now. In so doing, I draw ideas from the whole range of the Fuzzy Cloud Cluster named Agile. I try to give credit where it is due to the individuals who invented this idea, if I know them, or to the authors who best describe the idea.

But that Named Cloud that looks like a Rat today? I don’t think we should care much about that, because the wind is blowing away the front part of it and very shortly no one is going to give a Rat’s Ass about what it used to be.

Graham Calls on Sotomayor to Apologize for ‘Wise Latina’ Statement

1. Just get done what you can, velocity is velocity;
2. Crunch really hard because you’ve made a commitment;
3. Renegotiate with the Customer / Product Owner;
4. Stop doing iterations: use a Kanban approach instead.

It’s this last one we are here to talk about.

There is as yet no solid definition of Kanban for Software that satisfies me, and what people are talking about here is in essence a continous flow kind of approach, usually with limits on the amount of work you have “in process” in various stages of the project. See Kenji Hiranabe’s article for example.

I take the idea, tweeted by John Goodsen of RADSoft, among others, to mean that if we didn’t have a defined edge to the iteration, then no one could complain that we had failed if we got only nine out of ten things done that we “promised”. As John tweeted:

It’s about falling short because of iteration planning - remove iteration planning and you remove the entire wasteful exercise.

I’ve certainly seen teams whose management or product owner would berate them for falling short of the iteration “promise”, and this can lead to some very bad results. The initial response will be to “under-promise”. Not “under-promise and over-deliver” — they’ll say that, perhaps, but they won’t do it. No one does.

When the team tries to under-promise, this same manager or product owner will push them to commit to more: it’s part of that management pattern. Most teams will cave and try to do more. They want to be cooperative, they want to be appreciated, and so on.

This will not work. They’ll fall short again. Management will continue the pressure. Finally, the team will turn their secret screws and start producing code that is shiny on the outside and rotten on the inside. Velocity will continue to decline, pressure will continue to rise, and things will get bad. 

On the surface, we can see that a Kanban approach might fix this, because there is no defined point at which to apply this undue pressure. It’s not a bad idea: it might even be a good one, at least in the interim, for reducing the pressure.

Iterations provide rhythm

There can be a pleasant rhythm to the iteration, and there are things that fit naturally into it. It can be very pleasant to lift our heads up, look around, plan the week, then at the close of the week, lift up again, look around, and see how we did.

There’s work that needs to be done, such as reviewing the backlog, reviewing the product, perhaps some kinds of testing or other wrapup work that are not yet fully continuous. Some of those probably should not be continuous, though many of them should be. 

Now Kanban advocates will say that Kanban is better (what else would they say?) because it lets you have whatever rhythms you want rather than “imposing” one. Uh huh, yeah, and that’s why people who don’t cut the grass every week have yards that look like forests. 

Whack-a-mole

In my experience, a continous flow model becomes very relentless. There are always 7 things on your list. As soon as you get one off, another one pops up.  Every day begins to look like every other. 

I don’t know if this is inevitable or not. My experience suggests that it is at least very likely. 

Bottom line?

The small batch flow of Kanban has advantages, there’s no doubt about it. Certainly the Kanban board alone shows us that. 

I am not convinced at all that it’s always the best way: I don’t expect that there is an “always the best” way. 

If a team is getting too much pressure to sign up for more work, and too much hassle about not “keeping its promises”, Kanban might take off the pressure and let something good happen.  My guess, however, is that just moving to Kanban in such a situation might be ignoring the real problem. 

But we don’t know. It’s another trick in the bag. I hope teams at various levels will try it and tell us just what they did, and what happened.

When I say “story” test, I mean a test which has been provided to help the customer see that she has gotten what she asked for.  Here’s an example, in a classic story format:

• As a purchaser,
• I want to see an itemized bill for my order,
• So that I’ll know what I’ve ordered and what it will cost,
• For example:
  • CD: “Beatles White Album” $12.00
  • Book: “XP Installed” $14.00
  • Shipping: $4.00
  • Total: $30.00

We use examples like this to ensure that we understand what our customer wants, and we show the results to our customer so that they’ll see what we’ve done. Ideally, they’ll see that we’ve done what they want; sometimes they’ll see that we’ve done something that they don’t want.

When should such a test be automated?

Frankly, the answer is simple: any test which is going to be done more than once should be automated. 

There are a few kinds of objections to this fact (;->) that I’d like to talk about.

We shouldn’t automate the test because we might see something different the next time we run it.

Yes, if we’re going to look for something different, we quite likely shouldn’t automate it. Therefore we are not planning to do the same test more than once. The rule does not apply.

We shouldn’t automate the test if it is only going to be run once.

We cannot ever know that we will only need to do the test once, even if we plan to throw the code away after running it once. Why? Because we don’t know it will pass the test the first time. If it doesn’t pass … we’ll need to run the test again.

The more common case, of course, is that the feature is being written to be left in the system. Therefore there is a chance we’ll break it. Therefore we need to run the test more than once. Oh sure, we can guess, estimate, assume, possibly even sometimes calculate that we probably haven’t broken this feature. Would you stake your life on it, for the rest of the duration of your project? I wouldn’t.

There is no test that is guaranteed to be needed only once.

We shouldn’t automate the test if it would cost more to automate than to perform it manually as many times as we will perform it.

The whole point of automation is to make things faster and more repeatable than human manual processing. Will it take longer to automate this test than to do it repeatedly by hand? Well, we’re not very bloody good at automation, then, are we?”

It comes down to this:

Every story test, by definition, needs to get the same answers every time. We can never be sure that a story test will not be able to be run more than once, and most of them clearly do need to be run more than once.

Therefore the only excuse for not automating these repeated tests is that we aren’t very good at automation. 

I’m not very comfortable saying that the reason I’m not going to automate my next story test is that I’m not very good. Are you?

This is after the Prezi.

In an interview, Ken Schwaber said “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.”

I think that’s true.

On his site, Alan Shalloway converted that quote to “The Scrum community acknowledges that only 25% of teams adopting Scrum will get the value they hope to get from it.”

I think that’s exaggeration. 

Alan titled his article “Challenging Why (not if) Scrum Fails,” and refers  to “the high failure rate.”

I think that’s distortion.

My work, primarily, is helping Scrum teams get higher on the benefit scale. Every single Scrum installation I’ve visited has been pleased with progress, and wanted more.  

I think that’s important.

Alan’s point …

… and he nearly has one, is that Scrum (itself) does not change (itself). He asserts that Scrum should change, and that he knows how it should change. He thinks that Lean and Kanban and a few other things perhaps should be added to Scrum, and that somehow it would evolve.

Sorry, but that’s not the Scrum model.

 Scrum is about “Inspect and Adapt”. Scrum installations change. They are mandated to change, required to change. They are required to use every resource of their minds to see obstacles and impediments, and remove them or get around them. That’s the essence of what Scrum is.

Scrum is not a process based on a mass of  rules, principles, laws, and practices. It has a few roles, a few meetings, a few rituals. These frame a team’s work in a way that lets obstacles become visible. Scrum challenges the team to figure out what to do.

And that’s the end of Scrum’s job … and the beginning of the rest of your professional learning.

Teams using Scrum need to learn whatever will help them perform as well as they want to. Is Lean valuable? Certainly: many Scrum teams are applying Lean. Is Kanban valuable? Absolutely: there are probably more Scrum teams using Kanban boards than there are Kanban software teams in total. 

There’s a huge amount of material one needs to learn to be really good at anything, including software development.  There are many theories and principles that will help. The entire Agile / Lean / Scrum / XP / Kanban / Whatever community is engaged in finding better ways to be good at what we do.

It seems to be part of man’s history for a couple of people to get a hold of part of the same idea, then try to tear each other down for being wrong. I’d like the world better if it worked some other way, and mostly that’s what I try to do.

Would you like some help improving what you’re doing? I can help, and I can recommend others who’ll also help. 

Now then. I’m going out in the sunshine. Have a great day!

Sunshine car: Montego Blue 335i Convertible

However, cost matters also. Suppose without loss of generality that your highest value stories have value 100.  Suppose that stories vary in cost between 1 and 3. And uppose we have time to do 30 points of work.

We can do 10 3-point stories and get value 1000. Or we can do 30 1-point stories and get value 3000.  

3000 would be more. Story cost does matter. 

Left to the reader …

Suppose that, like most organizations, you don’t really know much about the value of your stories. Should you do high-cost ones, low-cost ones, or what?

Look down this page about half way for the important info …