… but I think Sonia Sotomayor can probably make better decisions than Lindsey Graham. Bad move, Lindsey.
What should an iterative-Agile team do if it appears that not all the stories they signed up for will get done? Possibilities include:
- Just get done what you can, velocity is velocity;
- Crunch really hard because you’ve made a commitment;
- Renegotiate with the Customer / Product Owner;
- 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.
OK, let’s talk, for the ten thousandth time, about when story (acceptance) tests should be automated, and when they should not. I’m patient, in a manner of speaking. I can keep doing this until you get it.
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 a test of an embedded Prezi. It has no actual useful content. If this had been an actual article it would have been interesting. Wish me luck.
This is after the Prezi.
There’s a bit of a tempest going around …
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!
Somewhere, somewhen, Arlo Belshee suggested not paying attention to story cost, only to value. Since story value probably varies from some large negative number to some large positive number, value is certainly very important.
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?
I know you’re all very busy right now fighting terrorism, but I thought you should know about some threats that are more serious.
Look down this page about half way for the important info …
Get ready for another amazing CSM Plus course June 2-4 at Calvin College in Grand Rapids. Sign up here.
This is not your standard eyes-front course at all. From the very beginning, participants learn Scrum by doing Scrum. At the end of this class, you’ll know how to do Scrum effectively, and you’ll know that you know.
I’m in the market for some assistance with the nuts and bolts for the site. I’d like to sole-source if possible. Issues and priorities include:
- Prompt support via email and such. Not everything I need is remotely urgent, but I value rapid communication response and clear indications of what will be done when. If I don’t hear what’s up frequently, I am not happy.
- I need dynamic indexes built for the Kate index and the other specialized indexes. That fell through the cracks in the conversion and needs doing.
- I need someone to tell me what I need but don’t know about, and probably do do some of the necessaries such as backups.
- I’d like a simple redesign on the Hot Needle section. Edgier, not fancy. Could pick up the card theme or not.
- I want to understand everything that is done.
- I have lots of little questions and need lots of little answers.
I’m not afraid to spend money in return for good service. My definition of “good” includes frequent communication and transparency of what is going on.
The opportunity is immediate and is open to anyone and everyone who can do the above things, whether or not they have already pissed me off. (Or I, them.)
At our CSM Plus class last week, someone asked how Scrum projects manage risk. We answered with some examples and some would-be pithy wisdom.
Then I heard myself say “Risk is the water in which the Scrum fish swims.” Anything that hokey must be preserved, and here it is. Still, the phrase does capture an essential point, which is that most everything about an Agile process like Scrum deals automatically with risk.
We bring all the necessary contributors to the project together: stakeholders, testers, developers. Everyone.
We build real software in short iterations, based on the product owner’s current understanding of what’s important. We treat the resulting software not as a final answer, but as the next step in discovering and deciding what the software should be.
We see what works, and what doesn’t work. If something seems scary, we work on it, learning whether it is scary and what to do about it.
Swim, little fishies, swim.
Keep those cards and letters coming in. Here’s what we know so far. I’ll update this page as new issues arise and new winners are discovered.Issues So Far
Search does not work, but does on the test site. Lisa’s on it.
All pages from my old blog are presently lost. A few links exist to those. They’ll say something like Page.asxp?display=something. One on the software page has been found. If you see others, feel free to file. I’m not sure yet if I can get those pages back.
Email link on front page goes nowhere, sometimes.
Some of the links on the left side are acting oddly.Winners So Far
Karl Pauls, Jaap Beestra, Dan KaplanPrizes
The offer to spend a day with any winner who can get to Brighton still stands. Some winners do not see the value in this compared to the cost of travel (imagine!) and have suggested other prizes, such as Knuth’s famous check for $2.56 (a hexadecimal dollar) for errors in his book.
I will either do that–so far looks like I could afford it–or, more likely, provide a similar award of little or no value, which will be sent to winners.
Brief report on the WordPress upgrade. Look for issues, win prize.
Silence the last couple of months has been due to an upgrade of the entire XProgramming site to WordPress. The work was done by E.Webscapes Design, owned by Lisa Sabin-Wilson, author of WordPress for Dummies. It looks to have been a success, though of course this is just the first few hours.
I asked to have this done because I noticed that even for serious articles, I was tending to use these blog pages rather than the XProgramming core pages, because it is easier to enter articles in WP than in my home-grown XML toolset. The plan was to do a bulk conversion of the whole site, preserving all the look and feel, and then address look and feel later. What I wanted–and what I got–was for Lisa to just make it all happen, with as little involvement as I could possibly have. And she has done that. Essentially I outsourced this project.
The project has not been without pain, which I’ll write about later on. And now, I think we see how it might have been done more incrementally, which might well have resulted in lower cost, faster delivery, and more time to make things actually better. I’ll write about that as well.
What is interesting is that essentially all the issues I have are with the customer, me, not with Lisa or her E.Webscapes staff. I’m happy with the results now, but there were times along the way when I was not happy, primarily because I didn’t know what was going on. If I had run this project like we teach people to run projects, I know I’d have been happier, and I believe I’d have gotten an even better result.
I’ll write about that later.
Now the prize. The first individual to report any significant problem with the conversion will win a free day with me and Chet, in Brighton Michigan, travel to be paid by the winner. (Out of town winners may optionally wait until we are in your town, at your own risk. I’m not as young as I once was.)
Send issues discovered to ronjeffries at acm dot org, and put [ron] in as part of the subject of your email.