Tag Archives: questions

When will this project be ready? (and some better questions)

Posted on by

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?

Real Kanban Questions #3: What makes for a good improvement?

Posted on by

Or, given a proposal for change, how do I know it’s a good one?

Dangerous answer: “Because it has a good ROI”

Too often, ROI is used as a tool to justifying changes of questionable benefit. Grandiose schemes, off-the-shelf solutions, restructurings, divestments – we’ve all seen them. It’s not always terrible, but we can do better!

A better answer: “Faster, better, cheaper – pick three”

Changes that promote early feedback tend to improve both speed and quality, but cheaper? Don’t overlook the biggest cost of all, namely opportunity cost – another way of saying that overall benefit to the business must be a primary concern. And if the economics still don’t work, keep trying! Perhaps you can implement your change incrementally, working on the next small change as the previous one proves itself and the system adjusts to a “new normal”.

To see this in action, a couple of real examples:

  1. The sign-off that takes weeks of chasing to complete, never yielding any benefit in quality. Better? That was the intention, sadly not realised in practice, a situation tolerated for years. Faster? Quite the opposite. Cheaper? Again no.
  2. The deployment scripts that take not just “20% time” but hard, scheduled effort to develop. Yes there’s a cost, but the value of being able to deploy quickly, reliably and (let’s say) opportunistically is very significant. Faster? Definitely. Better? Check. Cheaper? Absolutely!

Even better than “pick three” is “pick four!”, where the fourth element is a compass check, looking for alignment to wider vision, goals, or values. Good values make for quick tests: the first example above might have been rejected on the grounds that was likely to add complexity, discourage collaboration and disperse accountability.

What’s your experience? Do you live in a world of ROI-driven change, and what is that like? Is your team good at finding improvements that make your process better, faster and cheaper? What happens when change is in conflict with wider concerns? Are those values made explicit?

Real Kanban Questions #2: How does the team know that customers are factoring architectural significance into their selections?

Posted on by

This Real Kanban Question is based on a Twitter conversation with @ThinkBA.

One set of answers (David’s) assumes the existence or creation of a process step for assessing architectural impact:

  • Make sure that this step is reflected in the team’s kanban system
  • Have policies for feeding back on items whose impact is determined to exceed tolerance
  • Refine these policies by making them specific to a class of service, allowing (for example) non-urgent items to have greater impact than urgent ones without the need for some special decision making process
  • Have a class of service for items expected to be high impact (platform improvements, say) and reserve some capacity for these so that they are analysed in good time

But what if that assumption doesn’t hold (or can’t be made to hold cheaply)?

“How does the team know?” is a “smell”, meaning that there may be a dysfunction to sniff out here!  It begs a number of questions:

  • Why doesn’t the team know?
  • What are the architectural concerns that the team wishes the customers to take into account?
  • Are there perhaps architecturally significant pieces of work that the team is anxious to get prioritised?  And failing to?
  • Armed with better information, would the customer make better choices (better for all concerned)?

In other words, the question implies to me that the customer and team are insufficiently aware of each other’s concerns and priorities, indicating that collaboration doesn’t feature enough in work selection and (moreover) risk management.

Let’s return to the key paragraph of question #1 (interestingly, another “how do we know?” question):

One very cool but rarely discussed effect of limiting work in progress (WIP) with Kanban is that it pushes choice back upstream.  Or to put this the other way round: too much WIP and the prioritisation and risk management problem is sucked into the development team.  Horrible!  Better to keep it where it belongs: in a partnership between the team and its key stakeholders. Getting this right goes a long way towards neutralising the value question; difficulty here likely reflects broader problems in the organisation.

The opposite of “sucking the risk management problem into the development team” is “creating opportunity for collaborative risk management upstream”.  The more informed the customer’s choices, the better those choices will be, to the benefit of both customer and team.  Win!

Do you have a Real Kanban Question?

Real Kanban Questions #1: How do we know that the things we are working on are the most valuable?

Posted on by

That’s partly a question of perspective.  How is the input queue replenished?  Is the team deciding for itself and worrying about whether they’re doing it optimally, or perhaps having work selected for them and worrying that they’re having their time wasted?

One very cool but rarely discussed effect of limiting work in progress (WIP) with Kanban is that it pushes choice back upstream.  Or to put this the other way round: too much WIP and the prioritisation and risk management problem is sucked into the development team.  Horrible!  Better to keep it where it belongs: in a partnership between the team and its key stakeholders. Getting this right goes a long way towards neutralising the value question; difficulty here likely reflects broader problems in the organisation.

Ultimately, only time will tell how valuable the work will turn out to be.  Collaborate, be transparent about the decisions you make and how you make them, keep feedback cycles short. For maximum effectiveness in the short run, reframe the question from “how valuable?” to “what will we learn?” and refocus the work accordingly.  If value is hard to measure and still harder to predict, you can at least learn to test your assumptions quickly!

Finally (and partly as a warning against getting hung up on the value question), remember that winning in long run depends on maintaining a healthy level of investment in capability-building work, alongside the more obviously urgent value-driven stuff.  The alternative is to risk being left behind, and you need no ROI calculation to tell you how bad that would be!

[While we're here, not long now until my Kanban class in London, 5th-6th December 2011. Info here, registration here.  Don't miss it!]