A couple of good articles have caught my eye recently, both extolling the virtues of Critical Chain Project Management (or aspects thereof), namely:
Also announced in the last few days: Troy Magennis’s (@t_magennis) new book Lean Forecasting (“Rapid Forecasting Likely Staff, Cost and Delivery Dates of Agile Software Projects”). Meanwhile there’s always the classic Waltzing with Bears by Tom DeMarco and Timothy Lister.
Here on positiveincline.com I’ve made some small contributions of my own on the subject of planning, for example:
But there’s a problem with these technical approaches…
Is the when will this project be ready question always a good one to ask? And even when it is a reasonable question, are we guilty of rushing to answer it when more interesting questions need to be asked first? Questions like:
- Why do you ask?
- What will we need to prove?
- What parts should we deliver first?
- What else needs to happen for this to be successful?
Moreover, we risk a lot of needless pain and waste if we don’t take the trouble find out what kind of date we’re talking about. Is it a “bad things will happen if we’re a day late” kind of date, or “I need some cost information so that I can make a priority call” kind of date?
I don’t expect the need for forecasting and schedule risk management to to go away completely, but let me leave you with another:
- What needs to change in our organisation for the when will this project be ready question to be asked only rarely?
Answer that one, and you’re probably on a good path to a kind of processes that deliver predictability in ways more valuable than just date compliance. Worth exploring, surely?
…treat any stakeholder who holds any kind of a veto over your delivery … as a customer
This is to ask: have I identified them all, have I considered their needs?
To illustrate this at a small scale, which of these is better:
- “I’ve got this code for feature X I need you to review”, or
- “I’m about to make a start on feature X. What will you expect to see?”
Former colleagues from my dev management days will recognise this one! Whether you call it “no surprises”, “good risk management”, or simply “taking responsibility”, it’s no contest, surely.
What other sources of delay and unpredictability could you attack in the same way?
I’m just back from a fantastic Lean Agile Scotland, many thanks to Chris McDermott and team for putting together a great event.
The slides for my talk “Kanban the Hard Way” are now up on Slideshare. In overview:
- Kanban works on your organisation – visual management, self-organisation, the knowledge discovery process
- Kanban works on your process – pull systems, leverage points, interventions
- Kanban works on your system – models for evolutionary change, the Kanban Method and its debt to Systems Thinking, Lean and TOC
I’ve given this talk several times now, sprinting through it as a webinar in half an hour, presenting it in the typical 45-minute conference slot (Lean/Kanban Southern Europe, Lean Agile Scotland) and twice as a 90-minute tutorial (BCS Manchester, Agile North). It’s an introductory talk that never fails to provoke good questions from experienced people too and I always enjoy giving it.
New in this iteration was a reference to Lean Software Strategies by Peter Middleton and my friend Jim Sutton. I love their advice to treat any stakeholder who holds any kind of a veto over your delivery (my words, not theirs) as a customer. Not only will you do a better job of capturing requirements, it’s very good risk management advice too. The CFD on slide 30 shows what happens when you don’t pay enough attention to this.
Do get in touch by email if you would like to see the notes as well as the slides. I never present it quite the same way twice so you might not recognise the talk you heard, but they should help with recalling the main concepts. Drop me a line also if you’d be interested in hearing this talk at your organisation or event.
Comments Off on Kanban the Hard Way
This is followup #3/n to my LSSC12 debrief.
I’ve put the slides for my scheduled LSSC12 talk “Who moved my risk?” up on slideshare.
- There are risks inherent in each piece of work; some of these are unique and specific to that piece of work but there are some easily-recognised varieties of risks based on time and expectation. Time does funny things to priority – it has a habit of making a nonsense of any priority scheme that is fixed in time. And don’t think that risks based on expectations aren’t real risks!
- There are additional risks that relate to the (in)capability of the system (lead time and throughput performance/predictability especially) when faced with a volume of work. Capabilities differ between systems, but less capable systems can still offer high capability on limited subsets of work, those subsets perhaps based on the varieties of part 1 above. It is a “killer feature” of Kanban that we can easily make variety explicit so that good risk-based judgements can be made within teams on a day-to-day basis. Furthermore, it is relatively straightforward to design resilient kanban systems that consistently deliver good results in the face of variety, something that many systems deal with rather poorly.
- Don’t get so focussed on the system that you can’t step outside of it to see what’s really possible. Avoid “backlog driven development” (I’m sure you can work out what this means) – quite apart from its grim economics, you need to be spending time with different kinds of stakeholders concentrating on working out what’s important – using imagination, thinking the unthinkable (good and bad), filtering out the noise, creating good possibilities and heading off the bad ones. To put it another way, backlog grooming (on steroids or otherwise) is no path to success. But there’s good news: limit your WIP, shrink your backlogs and work on growing shared understanding outside your system and your risk will seem very different. Who moved your risk? You did!
Watch out for the “triple” win of improvements that are good for the customer (effective), good for the organisation (economic), and good for the team (humane). To my mind, “effective, economic, humane” in my estimation beats “better, faster, cheaper”; less catchy perhaps, but where’s the humanity in the more traditional test?
How did it go? That’s quite a lot for a 45 minute slot and I should probably have pruned it more. Also, I made a tactical error in thinking that we could do an interactive exercise before we had all warmed up. Lessons learned. Despite those improvement areas the feedback was pretty good and sufficient people were kind enough to tell me of the useful thoughts they took away that I’m happy enough with how it went.
I’ll write up my unscheduled talk on portfolio level problems soon.
Comments Off on “Who moved my risk?” and one of Kanban’s killer features
(see also part 1: Invest in your conference experience: Plan to confer!)
Karl Scotland published today his personal LSSC12 progamme on his blog. I had to try it for myself, and it turns out that it’s really easy to do. Just:
- Create an account (here’s mine)
- “Favourite” the talks and other events you plan to attend
- Share by copying & pasting the embed code as I’ve done below, or simply tweet away!
- Go to http://leansoftwaresystemsconferen2011.sched.org/mobile/ to keep your personal programme handy on your mobile device (yes, the “2011” is correct at the time of writing)
“Who moved my risk?” (4pm Tuesday 9th in Harborview 3) is my talk in the Risk track. It will be a lot more interactive and perhaps more provocative than my usual. Can’t wait!
Comments Off on Invest in your #LSSC12 conference experience (part 2)