silk and spinach

This week Wayne Allen is starting an experiment: one of his teams is going to drop the “traditional” agile approach of iterations and velocity, in favour of a kanban-style pull system with capped work in progress. The team will do no estimation, and the only metric for the department will be the average number of days required for a story to make it through the whole process.

I hope Wayne will keep us informed on the experiment’s progress and results, because I believe this is the kind of practical research that the agile world desperately needs right now. I suspect this kind of move could only be made in an organisation that has built up a deep reservior of trust in agile (and in Wayne); I wonder what other pre-requisites ar enecessary for kanban development to be acceptable (not to mention successful). I’m particularly interested the reactions of those who want to know what features are coming in which release at what date: Will they have less visibility of progress and planning information than before? Will they get nervous as a result? Or will they adapt their behaviour to the new throughput metric?

Hats off the Wayne and colleagues for trying this, and for anouncing the experiment publicly.

While catching up on my reading of lean blogs today I stumbled on a post by Jon Miller at Gemba Panta Rei, called Give Me 60 Minutes and I’ll Give You a Lean Transformation, in which Jon describes a very simple — and quite theatrical — means of driving improvement:

“This exercise starts with picking a spot in your gemba and standing in that one place for 30 minutes. Find 30 things to improve in 30 minutes. Write them down. Take the next 30 minutes and make at least one of the improvements you wrote down.”

Taiichi Ohno, the architect of lean manufacturing in Toyota, would teach his staff how to see waste by telling them to “Draw a circle and stand in it!” Could that work in a software development organisation?

First, I would note that a software development organisation doesn’t consist solely of programmers at work - all of the usual office activities will also be happening too. The developers may not be the bottleneck, and standing in various different spots around the organisation will thus likely bring different parts of the overall value stream into view.

Second, and as the commenters on Jon’s post point out, a lot of what goes on in an office is “invisible” because it is conducted in the virtual workplace “inside” computers. This is doubly true of software development. But as Jon suggests, the list of 30 problems could include the fact that status or progress aren’t visible, and from there its only a small step to the introduction of things like burndown charts or traffic lights for the build.

So I think the approach is feasible from a purely practical point of view; but what of the psychological / cultural angle? How might a roomful of developers react to someone with a clipboard watching them for 30 minutes every couple of weeks? I feel the person standing in the circle must have the team’s permission to be there - perhaps being a member of the team, one of the developers, most of the time. There’s no harm in the team asking someone else to do the job occasionally, to provide a fresh look and see things the team might miss themselves. But the idea that improvements can be imposed, or that one’s performance and behaviour are being monitored, is anathema. The team must decide it wants to improve, and must decide to adopt the lean kaizen approach; then the team can “appoint” one or more observers to help it find waste in the team’s activities.

On balance I think “standing in the circle” is worth a try, given sufficient introductory training to ensure that appropriate permission is granted by everyone. I’m interested to find out what kind of things appear on the list - particularly after a few weeks of running the technique. Please let me know what happens when you try it!

This week I’ve come across a few articles that clicked together as I read them, and in so doing they reinforced one of my deepest beliefs about software development - or any other profession, for that matter. The articles were:

• Train Wreck Management by Mary Poppendieck, in which Mary chronicles the origins of “management” and “accountability”. It seems that hierarchical management structures were first applied in the mistaken belief that it was one person’s dereliction that caused a train crash, and that in future such things could be prevented by management and accountability. Lean thinking says the opposite - that the train crash was an inevitable consequence of the structure of the system, and that specific individuals should not be blamed.
• Survey Blames Blame for Lean Struggles by Mark Graban, in which Mark notices that a recent survey seems to indicate that employees blame each other for their business failing to adopt lean thinking. Mark’s subsequent analysis of the survey shows, however, that it seems to lead the participants to ask “who is responsible for…?” - so it should be no surprise that the top answers mostly involve job titles! Mark’s response is to design a new survey in “5-whys” style - an effort I applaud, even though I disliked the example embedded in the survey.
• Risk Aversity by Henrik Mårtensson, in which Henrik uses the Theory of Constraints thinking tools to dig into why many organisations are immune to change. One of the root causes, according to Henrik, is that “mistakes” are punished in the average workplace - and so after a while everyone becomes afraid to innovate, or even to change the status quo. A truly lean organisation will reward even the person who makes a change that leads to lower throughput, because at least they contributed, and knowledge about the whole system has been improved as a result. But even the use of the word “mistake” shows how deep-seated is our culture’s desire to blame, and hence to discourage.
• The Secret Sauce of Highly Productive Software Development by Amr Elssamadisy and Deb Hartmann, in which the authors propose that inability to learn is the bottleneck (in the Goldratt / TOC sense) in most software teams. I need to think about their “bottleneck” claim, but I do agree that learning is the key to agile success, and that a learning organisation will out-perform any other in the longer term.
• The QnEK Horse has left the Barn by Hal Macomber, in which Hal opens the lid on a community for sharing QnEK (Quick-n-Easy Kaizen) ideas. QnEK can only succeed in an organisation where “mistakes” don’t exist, where blame is replaced by systemic learning.

For me, these articles all dovetail:

• learning is the key to long-term success
• the system can always be improved
• systemic learning requires a constant flow of improvement suggestions
• blame discourages innovation

It seems clear to me that blame itself lies at the root of many organisations’ problems. The system can always be improved, and is always the source of problems. People should be rewarded for discovering those problems and trying to fix them, especially when they “only” create new knowledge about how to perform less well.

John Brothers has posted the latest edition of the Carnival, entitled I’m running late. This is a perennial topic for all software development projects, and doubly so for those of us who take a lean or TOC view of productivity and change, so props to John for bringing that focus to the carnival this time around.

Speaking of TOC, one recent post that escaped John’s attention is Multi-Tasking: Why projects take so long and still go late by Kevin Fox. Every time I work in a large organisation I find myself writing about multi-tasking - and wondering why “common sense” is so rare…

In Lowering the Water Level Dan Markovitz over at Superfactory draws a sharp analogy between inventory levels in a factory and the time available to a knowledge worker:

“Imagine a value stream or a production process as a river. Reducing the inventory in the process – “lowering the water level” – exposes the “rocks” that represent all of the hidden costs and waste in production. Only by revealing those rocks can you improve the process and reduce the waste.

This metaphor works for knowledge workers, too. In this case, however, their key inventory item is time. Having too much time to do one’s work hides the waste and inefficiencies in the process”

Dan exhorts us to lower the water level by restricting the time we have available for knowledge tasks. Not only will this tackle Parkinson’s Law head-on, it will also encourage us to look for more efficient ways to carry out our regular tasks. And although I didn’t use the same metaphor as Dan uses,this is the motivation behind my ten-minute rules for software developers: restrict the time “allowed” between check-ins, for example, in order to discover new ways of incrementing the working system in small chunks.

Hal Macomber is a lean construction consultant who is currently developing a responsibility-based planning approach for a firm that designs high-tech manufacturing plants. The resulting process will be a hybrid of lean’s Last Planner System with Scrum. And Hal is managing the development of that process using Scrum. He has even hired a ScrumMaster from the world of software development to help with the iterative focus of the project.

I believe this is the kind of application for which Scrum is ideally suited. It brings a clear and simple structure to the process of developing something, and expects the application’s domain to provide the tools and techniques that will deliver value each iteration.

I’ll be watching with interest as Hal’s experiment unfolds.

Several times today my online reading has brought me to Henrik Mårtensson’s Kallokain blog. Henrik has a great knack of taking concepts from lean manufacturing or the Theory of Constraints and creating worked examples to show how they play out in day-to-day software development.

Take for example what Henrik calls the DIP - design-in-process - the software development equivalent of inventory. DIP is any work that has been begun, but not yet shipped to end users.

An easy, and highly visible, way to measure DIP, is to make a Project Control Board. Use a whiteboard, or a large mylar sheet on a wall. Make a table with one column for each hand-off in your development process. [...] At the start of each iteration, write sticky notes for each story (use case, feature description, or whatever you use). [...] Whenever a developer begins to work on a new story, the developer moves the story from the stack of sticky notes to the first column in the table. The developer is then responsible for moving the story to a new column each time the story goes into a new phase of development. [...] The sticky notes in the table are your DIP. Track it closely. If you have a process problem, you will soon see how sticky notes pile up at one of your process stages.

This fits with everything I’ve written about task boards, but Henrik then goes on to show how to calculate the current value of your DIP - ie. the investment you have made in the unshipped work on the board. In his worked example, a requirements change causes 20 story points worth of DIP to be scrapped; and as each story point costs 1,000 EUR to develop, the requirements change means we must write off 20,000 EUR of development costs.

It is worth noting that some of the 1,000 EUR per story point is “carrying costs” for the work that was scrapped. Just as manufacturing inventory costs money to store and move around, unshipped software (not to mention uncoded designs) has to be regularly read, searched, built and tested. It was there all the time, and we had to respect it and live with it. So it slowed us down; we had to step around it, and we would have tripped along more lightly if it had never been there. Looked at another way: with lower DIP inventory our cost per story point would be lower; equivalently, we could achieve higher throughput for the same expense.

(Of course, there are two obvious reactions to this write-off cost: make changes really difficult, or reduce inventories and cycle times so that DIP is always lower. Each has its sphere of applicability, I guess…)

In Lean, Lean and More Lean Kevin Meyer bemoans the apparent trend in manufacturing companies to adopt “lean” as a fashion item:

“It may just be me, but it appears that the number of companies citing lean manufacturing in their financial reports, news releases, and general news articles has been increasing. Of course many of them really have no idea what lean is really about, or perhaps they only understand the waste reduction pillar without even knowing about respect for people. Lean is apparently becoming a requirement, or even an analogy, for success.” — Kevin Meyer

Substitute the word “agile” where Kevin uses “lean” and his whole article (indeed the whole Superfactory blog) becomes a commentary on the current state of the software industry too.

Pete Behrens has edited the latest edition of the carnival, which includes links to a nicely balanced pot-pourri of recent agile and post-agile blog posts. I’m particularly pleased that Pete has highlighted Esther Derby’s reminder of the lean principle that we must always focus on optimising the whole system, and not be distracted by creating local maxima just because it may be easy to do so.

(Subscribe now to receive notice of all future agile Carnivals.)

When it comes to agile software development my preference swings heavily towards the influence of lean. The two central principles of lean are eliminate waste and respect people - although the second of these seems to be too often forgotten in the stories we read of lean (manufacturing) transitions. The agile movement (I hesitate to use that word in the present climate) has a strong tradition of demanding respect for people, arising from the manifesto’s exhortation to value individuals and interactions over processes and tools. And as I sifted through the agile blogosphere again this week I found that tradition very much to the fore. So this week’s carnival is a single-topic issue, bringing together a smattering of your thoughts on “individuals and interactions”…

To get us in the mood, in Respect People Alan Shalloway brings together a few pithy quotes, while in Individuals and interactions over processes and tools Simon Baker attempts to unpick what that particular plank of the agile manifesto means in practice. Dave Nicolette asks Is agile’s greatest strength also its most significant risk factor? and suggests that emphsising people over process is both liberating and risky.

The openness of agility is forcing us to (re-)discover some of the deeper foundations of effective communication. One of these is trust, and in I Told You So Ed Gibbs discovers one of the side-effects of not being trusted. (Trust has also turned out to be the theme of Clarke Ching’s Rolling Rocks Downhill book, which he would like you to help him rename.) And in Attachment Employment Jack Vinson points out that knowledge management initiatives will yield poor results when the workforce doesn’t trust it’s employer.

Speaking of knowledge management, in Osmotic communication - keeping the whole company in touch Tom Scott discusses the idea of using IRC (Internet Relay Chat) to promote information flow throughout a company, and specifically to provide a live commentary on what’s happening to version-controlled resources. A fascinating thought experiment, and I’m very interested to hear from any group who try it.

When it comes to working together, Jeremy Miller finds many ways in which Self Organizing Teams are Superior to Command n’ Control Teams (although some of his readers appear to disagree). And Jon Miller at Gemba Panta Rei discusses how to use Skill Matrices as a key part of the knowledge management in a lean organisation.

And finally, after all that reading, something completely different. Why not try simulating variation in task estimates, as suggested by Clarke Ching? Try it a couple of times, then imagine that Heads equates to getting good luck on a task (so it finishes early) and Tails equates to getting bad luck (so the task finishes late). What does the simulation say about plans and planning?

If you have something that you want to see in a future carnival - especially from a blog we haven’t featured before - email us at agilists.carnival@gmail.com. All previous editions of the Carnival are referenced at the Agile Alliance website. The next carnival is due to appear around May 17, hosted by Pete Behrens.