Archives for Chris

The usefulness of cost-of-delay: a real-life story

Here’s a interesting real-life story of a requirement from one of the delivery teams that I have worked with which emphasises how a focus on cost-of-delay helps.

The story concerns requirement RQ-0672 which took 46 weeks to go from being captured as a idea to being live in production.  We have a fair idea of which weeks there were activities happening (green) and which weeks nothing happened (red); shown in the value stream map below (See here to learn more about value stream mapping techniques):



Observation 1: It’s pretty clear there was a lot of “waiting waste”. Most weeks, nothing happened!

We introduced the concept of cost-of-delay to this team – i.e. measuring the opportunity cost to the company for every week this requirement was not implemented. This turned out to be $214,000 per week. Cost-of-delay figures often have high levels of uncertainty (particularly if the benefits of the requirements are around increasing revenue as in this case) but in this case, this number is fairly certain.

This particular delivery stream is capable of delivering a requirement like this within 13 weeks. Had this been delivered within 13 weeks instead of 46 i.e. 33 weeks earlier, this would have improved the company’s revenue by:

$214,000 x 33 = $7,062,000

Wow. Big number, particularly in the content the actual cost of making the change was around $4,200.

Obseveration 2: There can be significant value in reducing cycle time.

So why didn’t we make it happen earlier? The pipeline was setup without a focus on cost-of-delay which means there is no sense of the urgency associated with each requirement – they are all treated the same. Once we know the urgency, then we know what trade-offs to make.

In this case, you could say that it makes sense for the company overall to spend up to $214,000 for every week we could bring forward the go-live date for this requirement. You can also see from the value stream mapping that there was a proof-of-concept done for this requirement. This proof-of-concept took a week to execute – plus some mobilisation time – probably several weeks – hard to know exactly. Lets say 2 weeks mobilisation for the sake of argument. The cost of delaying the go-live by 3 weeks to do the proof-of-concept was:

3 x $214,000 = $642,000

The purpose of this proof-of-concept was to be able to accurately estimate the cost of the change. Remember, this change actually came in at a cost of $4,200. Given the enormous benefits, it would still have made sense for the company to implement this change if the cost had come in at $4,200,000. Perhaps we should have skipped the proof-of-concept stage for this requirement!

Observation 3: Not all estimating activity is truly value-adding

I have selected an extreme example of course. Even so, its real. It happened. It serves to emphasis that some requirements have high cost-of-delay which needs to be managed. A good innovation process design should  expedite these types of requirements by:

  • Prioritising quickly based on cost-of-delay (ideally within a week)
  • A frequent “pull” of the top requirement from the top of the dynamic prioritised list of requirement
  • Fast cycle time from the time of “pull” to go-live through a pipeline which is not clogged up with too many other requirements

Lean-agile risk management. Is there such a thing?

An interesting area of discussion is to whether a lean-agile approach contributes anything to effective risk management. Do lean-agile practices effectively mitigate risk? Some say yes and some say no.


There are, I believe, currently no lean-agile practices which are designed to identify the most important risks and then focus on mitigating and tracking them. Other (traditional) project management approaches have tools and practices for this – for example by the creation and ongoing review of a risk log. Yet this is missing in the lean-agile toolkit. Lean-agile practices need supplementing by a traditional risk management practice.


The traditional risk log approach is of limited effectiveness. If you ask a team what the top three risks the team faces are (go on, try it), it’s rare that the team comes with a consistent answer. Even when a risk log helps identify risks, analysing the true root cause of a risk in any particular case can be difficult.

By implementing lean-agile practices, teams get access to ways of mitigating the highest risks that an IT development project faces as evaluated by broad industry experience.

Take the Agile Manifesto. It was created by a group of experienced people. Apparently, it was tough to find things they agreed on (even though they were experienced, the number of projects they have worked on is still small so the number of data points they have is also small). They did manage to agree on the agile principles behind the manifesto. Each principle addresses one or more key underlying risk facing an IT development project. I’ve had a go at identifying the implied risk below. Would you think of these when you start a IT development project? Would you agree that these are the key risks?

Principle Implied risk
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Solution deliver generates no or little value. Unused features.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Solution could not be built as intended. Solution delivers no value. Things external to the project change.
Business people and developers must work
together daily throughout the project.
Business people and developers do not communicate quickly & effectively.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done
Environments and support not available.
Teams not empowered.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Geographical distribution of teams and over-reliance on electronic communication leads to ineffective communication.
Working software is the primary measure of progress. Focus on internal goals instead of meaningful ones (delivery of working software)
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Unsustainable development (pace, architecture, …)
Continuous attention to technical excellence
and good design enhances agility.
Lack of focus on technical excellence.
Simplicity–the art of maximizing the amount
of work not done–is essential.
Complex code. Doing work that doesn’t need to be done.
The best architectures, requirements, and designs
emerge from self-organizing teams.
Ineffective teams due to poor team structure/task management and the team not being empowered to change this.

What do you think?

8 tips on managing requirements

requirements-boxI have been looking recently at managing requirements for new projects. I thought it would be interesting to share our top lean-agile tips/encouragements for for managers of requirements (i.e. the product owner role in agile terminology):

Tip #1: Do only enough requirements work up front to enable you to build the first (small) feature. Then learn and adjust!

How much do we need to work out up front and how much can evolve as we build the solution? Defining all the requirements work up front (Big Requirements Up Front) seems attractive. It means that there can be a contractual style relationship between business folk and solution builders. Commitments can be made and, if an external vendor is involved, fixed price deals can be made. If dates, budgets etc. are not met then punishment can be handed out etc.

Yet this is not the way the IT industry is going. The biggest risk in IT development is that the solution delivers little or no value (unused features). The whole agile movement has this in focus. The IT industry has learnt that Big Requirements Up Front actually increase this risk because the delay the point when we are going to get feedback on our requirements. There are always large uncertainties in what the customer needs and how to build it. Its never been done before! A lean-agile approach emphasises learning – build a bit and get a response so we don’t have to get it right first time.

Wait, I hear you say. Doesn’t this mean that you might not take all business requirements into account from the start and have to refactor/reimplement certain features later? Yep, it probably does mean this. IT industry experience suggests that these refactoring costs are typically much smaller than the costs required to get it right first time. (See here for more details).

Tip #2: See requirements as a placeholder for a conversation, not the conversation itself.

Consider requirements as a placeholder for a conversation between the people who have a business need and the developer writing the code. They are not the conversation itself.

To align everybody around the direction we want to head in, a short up-to-date document describing the project vision (better a short document which everybody has read than a longer one that hasn’t been read at all). Beyond this, user stories are usually the best format to capture requirements since they capture the intention of the requirement (“in order to”) and who wants this requirement (“as a”). Otherwise, these things are often lost. e.g.

AS A: Flickr member
I WANT TO: be able to assign different privacy levels to my photos
IN ORDER TO: control who I share which photos with

Tip #3: Break requirements down

User stories can be arranged into hierarchies with top level stories which are broken down into smaller stories. Keep breaking the work down until you get to a feature that can’t be broken any further and still retain some business value (a minimal marketable feature in the jargon).

Tip #4: Define acceptance criteria up front

How will we know when a requirement has been delivered? Ensure user stories have acceptance criteria so we know when we are done.

AS A: Flickr member
I WANT TO: be able to assign different privacy levels to my photos
IN ORDER TO: control who I share which photos with

A user cannot submit a form without completing all the mandatory fields
– Information from the form is stored in the registrations database
– Protection against spam is working
– Payment can be made via credit card
– An acknowledgment email is sent to the user after submitting the form.

Tip #5: Collaborate like crazy, preferably face-2-face

Two of the the principles behind the agile manifesto are: “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” and “Business people and developers must work together daily throughout the project” Geographic constraints may hinder this but try and get as close to this ideal as you can. Be available throughout development/testing/ etc. for questions (e.g. attend the daily stand-up). If you don’t do this, the fast feedback model won’t work.

Tip #6: Use CD3 for prioritising and be prepared to stop early

Use the economic model cost-of-delay divided by duration as the basis for prioritising requirements. This also means that we have the option to stop early when we have delivered the most valuable requirements.

Tip #7: Smooth the end2end requirements flow

Requirements need to flow into a development team. There is no point developing requirements too early (requirements go stale very quickly). Equally, there is no point having a development team standing idle. Ensure the people who are actually going to build the solution (i.e. coders, not managers) participate the the refining of the user stories. It these people are not available now, wait until they are. It’s counterproductive to create a large queue of requirements that are waiting to be implemented.


Tip #8: Explain to business stakeholders how they need to behave

It’s helpful to explain to business stakeholders what kind of behaviour from them would support a successful outcome:

  • Charter the team to deliver the best possible value in a fixed time scale. Be cautious about asking for a fixed scope by a fixed date. The team will probably have to do Big-Requirements-Up-Front (BRUF) in order to have enough information to commit which significantly raises the risk of failure. It may also mean that invisible factors, like quality, are compromised.
  • Provide $ cost-of-delay/week and trust the team to make the right trade offs. Saying that “this is top priority” or “the board wants this” etc., gives the team no guidance about how to trade off against other high priority items.
  • Trust the team.
  • Make sure business people are available to quickly give feedback.
  • Insist on getting to see something of business value working in production quickly (30-90 days from project start) .
  • Insist on a weekly demonstration of progress.
  • Insist on regularly attending the team stand-up.
  • Insist that the team commit to dates on near-term work items (typically for the next 2-4 weeks).
  • Insist on an up-to-date roadmap covering a longer period. Don’t expect a lot of detail on this.
  • Stop/abandon the project early if you feel you’ve got enough value.

Culture eats strategy for breakfast

culture-eats-strat (1)Feeling a bit bolshie today so I first thought to write exhorting folk to deliver even more value in even smaller chunks in even faster cycle times. Well you should. Once you understand the magic of focusing on overall value (and not cost or some other sub-optimising dimension), the incredible benefits from reducing batch sizes and the almost silver bullet like properties of fast cycle times, it’s obvious.

These are the processes and tools of lean-agile thinking. What it’s really all about is mindset, attitude, culture. The agile manifesto captures this where it says that there is more value in “people and interactions over processes and tools.”

I’ve been getting it at a deeper and deeper level as time goes on. Linda Rising talks of two mindsets “fixed” vs. “agile”:


Fixed mindset Agile mindset
Ability – static, like height Ability – can grow, like muscle
Goal – look good Goal – to learn
Challenge – avoid Challenge – embrace
Failure – defines your identity Failure – provides information
Effort – for those with no talent Effort – path to mastery
Reaction to challenge – helplessness Reaction to challenge – resilience

We all spend time in both places. I offer it for your consideration that you have more fun, are happier and have a greater impact on the world if you spend more time in the agile mindset. If you suddenly wake up to find yourself in the fixed mindset, then there is nothing wrong. Pick yourself up and move over to the agile mindset. The trick is to practice this movement – aim for mastery.

In the agile mindset, we are all a work in progress. The development process isn’t fixed but will continue to improve as it ages. We all try to emphasize continuous improvement but we are woefully short of getting the hang of this.  We boil down lean-agile thinking to kanban boards, CD3 prioritisation and fast cycle times. Yet we are missing the key point. In the book Toyota Kata, Mike Rother looks into what Toyota’s success is really about. The have a behavioural pattern or culture (“kata” in japanese) they have managed to institutionalise where they:

  1. Identify one action that could be taken towards moving towards a vision
  2. Take it.
  3. See whether it did move things in the right direction.
  4. Rinse and repeat forever and make these learning loops as fast as possible.

They do this for everything from the company strategy down to the tiniest thing. What that enables them to do is to out-learn the competition. They understand that learning happens at every level.

“Yea, yea we know all this. I’m always looking for opportunities to improve.” I offer it for your consideration that you are playing this game small and you can play it at a whole new level. You rarely focus on improving just one thing, preferring long action lists and “projects” instead. You rarely understand what the required direction is (what is the vision for how your team communicates? for example. Do you have one?). You assume that you are not empowered to make the necessary changes. You are not ruthless in adjusting and learning quickly, you prefer to schedule meetings for the week after next instead. What both you and the company needs is to maximise the rate of learning. Your mission, if you choose to accept, is to find out how. Adopting the behavioural pattern above is a good starting point.

So here is a call to action. By reading this blog, you are prioritising taking time to learn. To get results, add some courage and steadiness to apply what you are learning. Wherever you sit in your organisation, put on your agile mindset and offer some leadership in adopting the continuous improvement behavioural pattern described above. Have the ambition to apply this pattern to everything. Find out what it takes to make this happen. Experiment!

Research shows that we are encouraged and influenced by other’s behaviour – your colleagues will be influenced by yours. When you start playing the game at a new level, you’ll probably find you won’t recognise yourself and, ultimately, your organisation won’t recognise itself.


The end of waterfall?

I was reflecting on why we don’t all simply do things in a lean-agile way by default. Why are short iterations, fast feedback and a collaborative working style not the natural way of doing things? What is so attractive about organising the development process around a single pass, stage gated approach (typically referred to as “waterfall”) that we often need a whole change programme to address it?

H. L. Mencken quipped, “For every complex problem, there is a solution that is simple, neat, and wrong.” One root cause of waterfall’s historical popularity could be that software projects have been inappropriately associated with a predictable manufacturing paradigm (such as manufacturing TVs or cars). In this paradigm, things can be predictably specified and planned, in contrast to the the chaos and uncertainty associated with a new product development paradigm. Since predictable manufacturing is the wrong paradigm for software, practices and values rooted in it are not helpful. Two assumptions in particular is are a source of amusement or dismay to developers of software solutions:

  • There is a single set of requirements and delivery options that describe what the business wants to do (requirements) and how it will be delivered (analysis and design).
  • The specifications do not change, or only change minimally (and perhaps predictably) during the construction and test phases of the project, subject to a strong change management process.

The deep appreciation—that building software is complex, new product development with high change rates, and not predictable manufacturing—is at the heart of the motivation for lean-agile methods.

Another possible factor is that single-pass waterfall gives the illusion of an orderly, predictable, accountable, and measurable process, with simple document-driven milestones (such as “requirements complete”). There is a special irony in choosing a simple-to-track process that yields higher levels of risk since the high risk activities – testing, integration and most of all, finding out whether the solution is valuable, are pushed to the end.

Software development is a young field, so it is no surprise the simple formula of “requirements, design, implementation” have dominated during the first attempts to create a skilful development process. The single-pass waterfall has the simplicity of explanation and recall (“do the requirements, then design, and then implement”);

So is the IT industry abandoning waterfall as it matures? Last month Gartner (in a research note entitled “The End of the Waterfall as We Know It” – requires a Gartner subscription) confirmed that waterfall is still the dominant approach across the industry (52% of development projects). They go on to say…

“Quite simply, waterfall methods, when used in the traditional, project-based manner, are inconsistent and risky. Since there are other choices available that have the potential to be more consistent and less risky, it’s time to begin the transition to these methods.”

Seems to me that we are reaching the tipping point as the IT industry moves to adopting lean and agile approaches!

Background Reading

Are you sitting in the right place?

I came across this graph in Managing the Design Factory:


Wow! It effectively shows that as a general rule, the chances of communicating with somebody once a week falls off rapidly with the distance your desk is from theirs. Once they sit 16m away, then they are almost strangers.

I measured 16m from my desk. Sure enough – I almost never speak to those guys (what on earth are they working on?). I don’t know why I’m so surprised about how rapidly this falls off.

You might think that this relationship doesn’t hold in these days of email, videoconferences, instant messaging etc.? More recent studies have show that it does – we are naturally much more likely to exchange emails the closer we sit together. Of course, if we have a special reason to communicate e.g. we are working on the same task, then this relationship doesn’t hold – the graph shows the general human tendency for communication –  we have a very strong preference for face-2-face communication!

What can we learn from this? Office designers conclude that our offices need to be compact – smaller desks etc.! Not sure everybody agrees with this. Lean-agile practitioners, on the other hand, emphasise face-2-face communication where ever possible. Co-location (temporarily or permanent) is also a good choice. We try to have as many of the people who are required to deliver a complete unit of business value sit together (feature teams). We use user stories in the place of requirements whereby the written document is considered the “trigger for a conversation,” not the really the conversation itself.

So, are you sitting in the right place?




What are good metrics for IT development?


How should our development activities be measured? What should matter? Mary Poppendieck, inventor of the term “lean software development” has a view:

“The right measurements for software development are delivered business value, cycle time to deliver that value, and customer satisfaction*

I like this because its a small number of metrics and it promotes a focus on value, speed and customers.  Two of the 12 principles behind the Agile Manifesto are:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Working software is the primary measure of progress.

So it seems like these metrics will promote these principles. There is no standard on how to measure these things practically, or who the customer is, or when to start the clock on cycle time, or how to quantify business value, or how to avoid nasty behavioural side-effects. One particularly difficult area is to decide when business value is delivered. Is this when a feature is actually been used or is when the feature is ready to launch in production but is held back because of a business decision  (know as earned business value in IT industry jargon)?

What else? All experts say it’s better to have a small number of metrics. Even so, there are things other lean-agile practitioners like to add on top of this. Perhaps these are of primary interest to the delivery/portfolio manager/delivery team but not beyond that:

  • Velocity –  This is equivalent to throughput – i.e. how much functionality is delivered per month. It’s hard to measure if one doesn’t have a stable way of estimating the size/complexity of requirements and it’s impossible to compare across delivery streams.
  • Defects/Errors – Both open and fixed.
  • Unit test coverage – For all common programming languages there are tools which can calculate what percentage of the lines of code are executed by the unit tests. Perhaps this does need more focus as coverage in many of the teams I have worked with is 0% (depending on the language/feature, min 80% coverage is normal) and there are very few teams who actually know what their coverage is.
  • Technical debt – How much has been added and how much has been removed per month. Most of the teams I have worked with don’t track technical debt so that makes this an interesting one to work on.
  • Work in progress – This can be visualised on the team kanban board. Work-in-progress and queuing times are leading indicator for cycle time (whereas cycle time is always a lagging indicator) which allows action earlier.
  • Lean-agile practice adoption maturity

Perhaps this gives some inspiration to adjusting key performance indicators next time round?

More reading:


Prioritise my stuff first!

hand-upSeeking inspiration in what to say to a project which desperately wants it’s stuff prioritised first? Try this…

Hi project!

Our delivery team is committed to managing the capacity of our development pipeline in a way that provides the best outcome for the company as a whole. We use  CD3(cost-of-delay divided by duration) as a framework for prioritisation since this maximises the company’s overall return-on-investment.

Using this approach, if the work you need us to do is not prioritised straight away, we will explore the following options together with you:

  1. Wait. The project shouldn’t start any related work until the bottleneck resource is finished with higher priority work.
  2. Redesign the solution to reduce the scope of the work required. Smaller pieces of work block the pipeline for shorter periods and increase the CD3 priority score (if the cost-of-delay remains the same).
  3. Redesign the solution such that the work is not is not needed. This can either be by pursuing a tactical solution which later will be replaced or by finding some way of not needing that functionality after all.
  4. Increase capacity at the bottleneck. This could be temporary or permanent. If we see it as a temporary bottleneck, the best would be that other project members go help with the bottleneck for a while if they have the skills (T-shaped individuals, please!)
  5. Abandon project. It may be that the project simply isn’t as valuable as other projects we could work on and we don’t see this changing any time soon.

We believe these options create value for the company. There are two further options which generally don’t add value for the company:

  1. Start more work in parallel. It’s finishing work that makes a difference, not starting it. Starting too much at once means that we lose focus, overhead/switching/coordination costs increase and some value is delivered later than would otherwise have happened.
  2. Complain to senior management to get the priority score of the work increased. This can be by increasing the cost-of-delay for “strategic reasons” or because we have “suddenly” found some extra $ benefits of the project. If this kind “tampering” really really can’t be avoided, we insist that it is the cost-of-delay which is manually adjusted such that the increased urgency of this work is communicated to all teams that are involved in producing the feature. This way we avoid a situation whereby one team considers a feature very urgent and another team considers it less urgent.

In the interest of the company as a whole, we want to steer you away from these last two options.  “Removing roadblocks” is often perceived as a core skill in our management culture but exercising either of these option is not normally removing a roadblock to value creation.

We look forward to exploring this further with you to get the best outcome for the company as a whole!

Best wishes

The delivery team


Increase personal productivity?

tomatoThe Pomodoro technique is used by a lot of lean-agile practitioners to improve their personal productivity and apparently it works. I’m gonna get going with it and I challenge readers of this blog to try it out. Anybody who lets me know that they have become a Certified Pomodoro Master, I will publicise it here on this blog!

The basics of the technique

  • Put all the activities you have to accomplish on the Activity Inventory Sheet.
  • At the beginning of each day select the tasks you need to complete and copy them on the To Do Sheet
  • Start working:
    • Choose the topmost task from the list
    • Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
    • Work until the Pomodoro rings
    • Mark the task with an x on the To Do Sheet
    • Take a short break (3–5 minutes)
  • Keep on working, Pomodoro after Pomodoro, until the task at hand is finished, then cross it out on the To Do Sheet.
  • Every 4 Pomodoros take a longer break (15–30 m)


There’s a load more info. on why it works/goals and how to deal with stuff (managing interruptions etc.) on the Pomodoro website:

Why wouldn’t you give it a go?


Have you got the “lean-agile mindset”?

brainI spent some time this week evaluating the Value, Flow, Quality training course developed by  the agile consultancy Emergn. The course provoked some reflections on what adopting a lean-agile mindset means…

Intuitive Decision Making

The course asserts that way we make decisions is largely based on our intuition. Studies of how CEO’s make decisions shows that, although they often believe they are making rational fact-based decisions, it’s actually coming “from the gut.”  This kind of expert intuition is powerful stuff and can almost be magical – fire-fighters who run out of the house seconds before the floor collapses, chess masters who can glance at a board and declare that white can win in 3 moves, etc.

It was argued in the course that good intuitions take a long time to build up. Within IT development, the high variation both in the type of work, the length of time of most IT implementations and the short lifetime of most teams makes it hard to spot patterns. In a lot of cases, the feedback actually comes after the project is finished.

Lousy Rules of Thumb

Consequently, our intuition about IT development isn’t that great. So we fall back on more general rules of thumb. Which of these do you like?

  • Minimising cost is good
  • A standard process makes things easier and more efficient
  • If the customer needs something, then it must be done
  • Detailed plans allow us to monitor progress and stay on track
  • Ensuring clear handover points normally gives the best outcome

The course contended that these are fairly lousy rules of thumb for a product development context. It’s not that these are never true in a product development context. It’s more that applying them without knowing why rarely gives a good outcome – and often has the opposite effect to that intended.

So this is what a Mindset Change looks like

This made me think about what a lean-agile “mindset” really is. What we mean is replacing these general rules of thumb with some more powerful ones which are more relevant for product development. For us to accept this, we need to understand the “why” of these new rules of thumb (which is what the training course tries to address).

Let’s try some out. Which of these lean-agile oriented rules of thumb do you like?

  • The customer doesn’t know what he/she wants
  • Reducing batch size is good
  • Speed is normally more important than predictability
  • Maximising total value is good
  • A collaborative approach normally gives the best outcome

If you like these better than the first set, then you are already travelling the lean-agile path!