Now Playing Tracks

Evolutionary Change over Revolutionary Chaos Part III

Transformation through Evolution – A Pathway to Success

Evolution is defined by the OED as “the gradual development of something”. This is the approach that is outlined in the diagram below and is the approach that Radtac use when addressing transformations.

Evolutionary Change: The Epigenetics of Organisation Transformation

This approach allows the development of what ‘good looks like’ and also allows the adaption and environment to have influence over change as it proceeds.

Cultural evolution needs to be supported with a framework and implementation approach. An approach that can be used is called ‘vertical slicing’ with ‘horizontal striping’. This has the advantage of being simple to understand, immediately visual and straightforward to implement.

This model has been proven to work across multiple geographies of significant cultural diversity as well as diverse industries and public bodies.

It is predicated on the understanding and use of the Radtac Change Wave. Radtac uses the term Change Wave and the simple graphic to give a clear and unambiguous communication, again emphasizing the visual and simple. Most senior teams find the use of simple graphics to both capture their views, as well as present them to others, a powerful communication tool that is difficult to distort. This is based on the whole process that people understand what they can draw and articulate simply, and is not easily open to verbal misinterpretation. 

The Shallow Wave

  • Individual teams adopt their way of working
  • This way of working fits within existing structures and processes
  • Not a sustainable change outside of the team, when members depart the way of working is likely to collapse
  • Has little Enterprise benefit, in fact is unlikely to deliver any benefit as it sits in isolation surrounded by Constraints

The ‘Tsunami’ or Breaking Wave

  • Senior team on Board, ‘flavour’ of the month
  • It is a managed and ‘driven’ or 100% ‘pushed’ adoption.
  • Small project teams at layer 3 embrace ideas
  • Layer 2, ‘The Frozen Middle’ not engaged, wave crests, breaks and collapses, senior team ‘walk away’
  • Layer 2 beat up layer 3 for being so ‘stupid’ – don’t do it again

The Sustainable Wave

  • Change in all layers as a ‘vertical slice’ through the organisation
  • The change is ‘Led’ through ‘walking the talk’
  • Company starts small and acts fast to expand
  • Scalable growth by expanding horizontal stripe width ways
  • Pull’ demonstrates what good looks like

The Radtac Change Wave

The uses of simple tools to both put previous failure in context and understand the route to success is essential for buy-in through the organization, starting at the executive. The key to a good transformation in any organization is an effective communication plan; diagrams and pictures are excellent mediums for explaining complex issues.

And a good communication plan is key to success. For people to be led they need to understand ‘why’ they are doing something, then ‘how’ that is going to be achieved and finally ‘what’ needs to be done to make the ‘how’ happen. We have adopted this approach in Radtac’s Information technology Transformation Approach (RITA)[1], others such as Simon Sinek refers to this simple order as the ‘Golden Circles’[2].

The use of the Why, How and What, follows the logic of the evolution of our limbic brain (biology in successful change). This “inside to out” approach is what makes messages appealing and is more readily understood by both internal, third party and customer audiences.

Organisation Structure for Effective Innovation

The organization must develop effective leadership. Leadership that always does what it always did will not produce an advancing and innovating business; it will always be more of the same.

Once our  concept  behind the ‘Change Wave’ is communicated what does this mean in terms of structure for change. How does the leadership of the organisation develop risk taking and effective innovation.

About Radtac

Radtac Ltd has been established for over 15 years and has delivered programmes for clients such as British Airways, Nokia, Rolls Royce, Hiscox, William Hill.

Radtac’s vision and values are ……..

Vision :

Radtac believe in challenging the status quo and in the innate ability of people to rise to the challenges of their organisation.

Values :

Radtac do this by helping our clients achieve sustainable continuous improvement and by unlocking their human potential using our great people and unparalleled practical industry experience.

By doing this we have come to value….

  • Evolution over revolution
  • Collaborative partnerships over supplier relationships
  • Pragmatic transformation over fundamentalist dogma
  • Transformational leadership over transactional management
  • Realising innate potential over hiring new staff
  • Simplicity over complexity
Michael Short
Radtac COO
Enquiries@radtac.co.uk

[1] RITA – Radtac Information Transformation Approach is the company’s consulting approach to change and    transformation that combines all the leading methods and approaches into a deliverable 

Innovation and Change – The Challenge for Enterprises Part 2

Changing the way you do things is a massive challenge for humans. We are creatures of habit and from a young age our biology teaches us to do those things that work and we get rewarded for. Referred to as reinforcement learning, we learn what to do and how to do it by receiving positive feedback.

Why is such natural human behaviour a blocker to change, this illustration goes to why.

Led vs. Managed; different activities need different approaches

These two diagrams, which can be laid over each other, go to the route cause. You need to foster good management because this makes you efficient. Management focuses as a group on a process of making what you currently do more efficient rather than thinking ‘is what we currently do still providing best value to our customers’. When you have a formula that is commercially successful then you need to provide a programme of efficiency gains e.g. zero defects, total quality management etc. These are valuable and we have provided many such programmes. However it will not create a business that will survive. Just delivering the same thing cheaper and faster may not be the answer, especially in a globalized economy where delivering something 10% cheaper from one economic area still can’t compete with one that can inherently deliver something 50% cheaper.

You also need to provide develop a service that is more effective (answering current customer needs) than you currently provide. 

Effective business must evolve in tandem with the changing customer environment, delivering value to changing needs. That means innovation, because “doing what you have always done just gives you what you always got”. The bias of the organisation is that it is designed to “do what you’ve always done”, that is why innovation needs to be led. 

Effectiveness comes from innovation.

The leadership challenge is to lead an evolution to more effective working without destabilizing what is already established. This is challenging because:

  • Status quo is safe, it is how we got here
  • Our business is profitable and successful, why change what isn’t broken
  • If we change this will disrupt the company and is unfamiliar ground for the Executive
  • Innovation and new visions are hard, risky and do not play to strengths
  • True innovation is challenging because innovation is a ‘led’ not a ‘managed’ process

The answer to change lies in the development of a culture that supports innovation. Here are three fundamental aspects of cultural change;

  • Push and Pull – To create pull companies need to create small increments of success based around innovation and new approaches (what good looks like). They then need to provide a wider ‘toolbox’ of approaches, the ‘Pull’, training and corporate learning, that encourages and provides approaches which others can adopt when seeking to emulate these successes.
  • Accepting failure as a pathway to success – In achieving the ‘pull’ illustrated above there will be failure. When you are doing something new companies and CxOs must accept that this does not follow the ‘normal’ budgeted approach. Doing what you have always done is easy; doing something that is different (innovation) is hard. Measuring success by applauding loudly those who have always done what you always did will positively reinforce NOT changing anything, therefore reinforces stagnation and reducing company performance.
  • Leading by doing rather than talking – One of the keys aspects of success, the leadership, must constantly communicate the vision of innovation and why the company must do it. The Executive must walk the talk by making their success significantly dependent upon innovation. Key Performance Indicators (KPIs) must be attached in a clear and meaningful way to risk taking. Leaders must adopt an approach of incremental inspect and adapt. Leaders must understand, rather than monstrous programmes of grand design and cost, change succeeds by starting small and evolving success. These approaches inspect and adapt to feedback or value delivered to client / customer

About Radtac

Radtac Ltd has been established for over 15 years and has delivered programmes for clients such as British Airways, Nokia, Rolls Royce, Hiscox, William Hill.

Radtac’s vision and values are ……..

Vision :

Radtac believe in challenging the status quo and in the innate ability of people to rise to the challenges of their organisation.

Values :

Radtac do this by helping our clients achieve sustainable continuous improvement and by unlocking their human potential using our great people and unparalleled practical industry experience.

By doing this we have come to value….

  • Evolution over revolution
  • Collaborative partnerships over supplier relationships
  • Pragmatic transformation over fundamentalist dogma
  • Transformational leadership over transactional management
  • Realising innate potential over hiring new staff
  • Simplicity over complexity

Michael Short

Radtac COO

Shelfie!

The infamous ‘selfie’ that Ellen DeGeneres took at the Oscars has, at the time of writing, been re-tweeted over 3 million times.

So, always up for a challenge, I thought I would take my own ‘shelfie’ and see if I can get it to go viral! What do you think?

So what is on my ‘Agile Shelf’? Quite an eclectic assortment of books that I have either read, part read or been given (I have no plans to read any of those)!

So from left to right, tallest to smallest, let’s have a quick whistle stop tour of my ‘shelfie’.

Ring Binders x3

Course hand-outs from my CSM Course and the SAFe Program Consultant course, the former with Pete Measey and the latter with Dean Leffingwell; both ‘legends’ in the their own right!

Managing Successful Projects with PRINCE2

And yes it is on my Agile shelf! Anyone that believes that Project Governance cannot happily co-exist with Agile Software Development is misguided.  Read the following:

Agile and the Best Management Practice framework within the public sector” Peter Measey, RADTAC Limited

 This book dates back to when I became a PRINCE 2 Practitioner back in 2004 which means I have lapsed in terms of my certification because I have not re-registered in the 3-5 years window.  And that’s not because I don’t value the accreditation, it’s more to do with whether re-registering would aid my understanding any more.

Scaling Software Agility and Agile Software Requirements

So I wanted to read about Scaling Agile before I went on the SAFe Program Consultant course and I thought Scaling Software Agility by Dean would be the book to read. Nope! It’s another good introduction to Agile. If you want to read about Scaled Agile then you need to read Agile Software Requirements. Doh – obvious really! In here is a very early incarnation of the big picture! It has evolved many times since!

Lean Analytics

This book was won by my colleague Dragan Jojic at Agile Yorkshire for tweeting at 8.55pm!! Have I read it? No!

Software Testing

A book published by BCS as an example of a course reference book. So why have I got it? Well, BCS have commissioned Radtac to write a supporting text for the Agile Foundation Certification. Exciting stuff – I plan to contribute to the book and become a co-author!!

Succeeding with Agile

In my personal opinion, this book by Mike Cohn is one of the best introductions to Agile and Scrum. Enough said!

Kanban

The Blue book! The new kid on the block. Is it Agile or not? I don’t care. A must read for considering ‘flow’. However, I always have a small issue with books like these:

  1. They are always blue books!
  2. Why write 262 pages when 182 is probably enough – I never end up finishing these books.
  3. They tend to be extended Case Studies! In this case Microsoft XIT!

Balancing Agility and Discipline

Probably one of the first Agile books that I bought! It was early days in my first Agile adoption and, being in a corporate environment, I needed a disciplined approach because ‘back in the day’ Agile was considered to be ‘fly by the seat of your pants’!!! Actually that’s just FrAgile!

The Lean Start-up

Another blue book and another extended Case Study for Imvo! Also, I have borrowed this from another colleague (Alex Gray) and not given it back!

SPIN- Selling

This is a legacy from my days at a Senior Bank Manager with Lloyds TSB – don’t ask!

Facilitation

For me this is great for Agile Coaches, ScrumMasters and Project Managers alike, with superb tools for the tool box. At some stage, I really hope that I will be able to offer the Facilitation Course as part of the Radtac training catalogue. It’s on my backlog!

So here’s the challenge, re-tweet over 3 million times OR just tweet a picture of your shelfie!

Darren Wilmshurst

Head of Radtac: Consulting 

It’s about People and Culture, On-Line Betting & Gaming Technology – that’s the easy bit

CAT-terick, 2:40, a £5’er each way on the fav

“… it’s more a problem of people, processes and culture. If I had to do it again, I would spend 90% more time worrying about people and processes, and 90% less time worrying about the technology.” 

So who said this, a CEO ……. a Director of HR ……. Chief Business Officer …….. Chief Marketing Officer……Director of Sales….Head of Customer Service

If you thought it was one of these you’d be wrong it was the Chief Information Officer for Betfair and I wholeheartedly agree, read the whole article here from CIO magazine on-line. 

Michael Bischoff went on to say

“Our development and test shops are where … we’re supporting the ability …. to be asefficient and effective and Agile as possible …another way of thinking about that is more like an API-accessible set of capabilities, and here we’ve come a long way down that route.” Bischoff said he wants to see a broader deployment. ”Eventually we want to get it through to production as well, since there’s no reason that if we can orchestrate it with test and development it won’t work in production as well. The ability to deploy new features to our customers at speed is where we get our competitive advantage.” 

“The only sustainable competitive advantage is an organisation’s ability to learn faster than the competition.” Michael Bischoff? No a quote on the wall of a “Three Wall Workshop” run for our Radtac client workshop last week for a client. 

We regularly help clients become Efficient and Effective, we recently published this white paper “Evolutionary Change over Revolutionary Chaos” where we discussed our approach and why this is important to how you go about transformation and change, way before you look at what you were going to do.

So if you fancy a discussion on this subject and cannot get hold of Michael Bischoff why not talk to #Radtac, We have worked with clients in the #Media and #Television space as well as the #gaming and #betting arena on just these issues.  Help is at hand and it is easier to get than you may have thought.

Michael Short

Radtac COO

0203 638 5040

Enquiries@radtac.co.uk

Agile is not about Cost Reduction!

Many times an organisation will embark on an Agile transformation because they have been told, and maybe believe, that it will make their software development projects cheaper (Oh, and they will deliver faster and have better quality as well, but that is a discussion for another time!). This is a false goal that will more than likely not be attained and I will attempt to explain why.

The goal of implementing Agile should NOT be about cost reduction. A statement from Donald Reinertsen sums it up nicely:

“Armed with the wrong definition of economic success, we would naturally measure—and optimize—the wrong things”

Agile principles

Starting from the absolute basics of Agile, none of the principles, whether it is those in the Agile Manifesto, or those of any of the main methods says anything about cost saving being a primary, or even secondary, aim. It is all about delivering Value, as quickly as possible. Lean might hint at it with waste elimination, but even there it does not directly relate that to cost.

Putting focus on the wrong thing

There is a phrase used in a number of reference sources on Lean and Agile which states that we should:

“Watch the baton, not the runner”

This is at the heart of the Agile approach where we need to keep our eyes on the work flowing through the system, not the people carrying it out. It is the process we model in a Value Stream, the pieces of work flowing through the system. The danger of using cost, which is primarily incurred due to the people, is that the focus turns to the runners. The temptation is to start looking for cost saving in the resources we use, whether that be in a project by slimming down the team, or obviously outsourcing and offshoring, and it is more than likely that this has a damaging effect on the outcome. Sure, costs have been saved, but the project will fail, and then Agile gets the blame.

Cost Reduction has Negative Overtones

When cost is touted as the main reason for implementing change it is not generally well received. It would appear to be a serious de-motivator to the teams who are required to carry out the change. Cost saving initiatives, in my experience, are always a signal to start looking for another job, as my salary is in jeopardy! “The company is in trouble and it is all the employees fault” would be the perception.

Wouldn’t it be better to motivate them with a positive target, one that inspires and calls upon their corporate spirit, wanting to do a good job to keep the company going and to bring them benefit?

In Conclusion

So when you are confronted by your boss who states that he needs to reduce costs and that is why he is implementing Agile, it would be in both your interests to attempt to disabuse him of that notion and encourage a dialogue on what are the real reasons behind the organisations problems, how Agile might help address them, and to make sure that the goal is not about cost reduction, but improving the flow of high value to the business.

Randal Cooper

Director Product Development & QA

The Economics of Agile Payback

So if Agile is not about making things cheaper for cost sake, although cost improvements as measured by economic value delivered to the P+L and asset secured to the balance sheet certainly are, how do we measure the payoff?

Economic Payoff

The decision we need to make in Agile software development is not just about cost. Nor is it just about Value, or maybe not even Return On Investment. Whilst all of these will have an influence, focusing on just the cost does not allow good economic decisions to be made.

It is not just about the number. For example, the statement that an organisation needs to save £x from its R&D budget needs to be examined very closely to discover why this reduction is deemed necessary. It could be that this level of expenditure is necessary to support the development of the new products and the revenue streams that support it, so why the need for change? Now if the revenue stream does not support the expenditure, then isn’t it about reducing the capacity of the R&D organisation? And if this is so, then what has that got to do with Agile?

There are a number of variables which can be measured, referred to as proxy variables, and the tendency is to try to use these in isolation to make decisions. Just looking at Cost could be one of those. But what is possibly poorly understood is that these variables interact, and making the right decision is understanding how they do, by using economics. For example we can’t answer questions like “Which is less expensive: a 1-month delay or a $5,000 increase in expense?” or “Is this feature worth pursuing if it will take twice as long to implement?”, if we don’t take into account how these things interact. If the focus is only on cost saving then the increase in expenses is rejected, when in reality it could actually give the correct payoff in economic terms.

Cost Accounting and utilisation

The cost accounting model encourages management to look at resource utilisation, trying their best to achieve 100% in the belief that it is them optimised for costs. This is a false goal, as increasing utilisation is not conducive to optimising flow (just look at the M25 in rush hour!). Reinertsen quotes a formula:

Cycle Time / Value Added Time = 1 / 1 – rho,

where rho is the utilisation figure.

The aim should be to make left and right tend towards 1. For the left hand side this means that there is no waste in the system and that the time it takes for a piece of work to flow through the system is all devoted to value adding work (an almost impossible position, but worth targeting). For the right hand side it means that “rho” must tend towards 0, or in other words the utilisation figures need to reduce, which is against the instincts to save costs.

In Conclusion

It is very likely that costs will be reduced as a result of implementing Lean and Agile approaches, but it is best treated as a secondary benefit, rather than a primary target, for the reasons outlined above. It could be considered a proxy variable, in the sense that whilst we are interested in it, it is not the primary target of the transformation, and that the real targets, like waste reduction, improved flow, etc, will lead to cost reduction. But these are better motivators and change agents than cost reduction.

So when your boss states that we must focus on costs and that is the ‘why’ he is implementing Agile you would do well to encourage a dialogue. That should be focussed and directed at

  • what are the organisations problems
  • why (the reasons) behind them
  • how Agile methods might help address them
  • En sure that the goal is about improving the flow of high value to the business from those reasons of failure

The best cost will be delivered through doing the right things better, not as a simple aim in itself

Randal Cooper

Director Product Development & QA

Sizing, Estimation and Forecasting

This is Radtac’s first Guest Blog and we are delighted that it is from the NHS Choices team and specifically Joe McGrath. 

We started working with the group in early 2013 during a period of considerable change in the NHS organisation as well as specific changes for the team doing the delivery. 

We continue to with the team in 2014 across two sites. 

Enjoy a great and amusing read.

The story so far

Over the last few years we’ve tried a variety of estimation and planning techniques. We’ve suffered from our fair share of Estimation Anti-patterns and tried various approaches to avoid these.

I thought it’d be useful to outline some of the approaches we’ve tried, the problems we’ve encountered, and how we’ve reacted to those in order to get to where we are now.

2010

Back in 2010 estimates were forced to fit a previously agreed plan:

“What’s the estimate”

“60 days”

“It needs to be 30, go away and re-estimate it”

This is a cross between the Target Estimation and Comedy-driven Estimationanti-patterns, and obviously it’s just a big farce – what’s the point in estimating in the first place if you’re just going to have a fixed time, scope and resource all imposed on you.

This approach led to teams and individuals being put under a great deal of pressure, and generated bad feeling between the people who imposed the ‘estimates’ and those who had to stick to them.

Of course corners were cut in order to meet the fixed estimates, which led to further technical debt, which just exacerbated the whole problem for future projects – the Done-driven estimation anti-pattern.

2011

During 2011 we gradually moved away from ‘fixed’ estimates. We introduced a few fairly standard ideas -

Estimating in ideal days

We started estimating in ideal days, to take into account of the fact that a Developer doesn’t get to spend their entire day dedicated to the estimated item that they’re currently working on.

This worked okay, once we finally hammered out the exact definition of an ideal day…

“Does an ideal day include meetings?”

“But what if the meeting relates to the story they’re working on?”

Having the people who are going to do the work doing the estimation

We tried to throw out the idea that a single individual could estimate a project more accurately and precisely than the developers who were familiar with the codebase, and who were about to do the work.

Estimates would still be questioned by people who weren’t going to do the work. We’d get Architects or Managers questioning why Developers thought something would take, for example, 3 days -

“That story’s just a few lines of code isn’t it”

This was frustrating, and we probably did waste more than a few hours justifying estimates to people outside the team.

Planning poker to derive estimates from the group, not individuals

The introduction of planning poker was quite good fun to start with. It bought the team together and helped to alleviate some of the discussions and justification that we had to go through.

However, it sometimes did feel like a bit like a negotiation – with some people deliberately going in low to try to bring an estimate down.

Velocity – planning based on past performance

We introduced the standard idea of velocity from Scrum -

Take the number of ideal days you complete in an iteration, and then plan your next iterations based on that.

This was sound, but unfortunately it was described by whoever sold the concept to senior management as being a percentage measure. So if a team got 30 ideal days of stories completed in an iteration of 40 elapsed developer-days, the team had achieved a ’75% velocity’ – this was really ugly, and came to hurt us, as you’ll read below.

We struggled a bit with the idea of the team committing to a sprint goal. There were a lot of dependencies on other teams that we just didn’t account for, so we could never really meet what felt like reasonable goals.

Relative Estimates

We started to estimate work based on it’s relative size, compared to work we’d done previously. After all, this seemed like the quickest and generally most reliable way to estimate. If you ask a decorator to quote for painting a room, they can usually give you a rough quote without measuring up, because they’ve already painted lots of rooms of roughly the same size before.

This approach for us was pretty successful – if we’d tackled a similar size project in the same product area, we could look up the actual effort we expended on the previous project and use that to guide our estimate for the new project. When the newer project was complete, looking at the actuals showed us that this was a fairly accurate method.

It helped us to resolve the Fractal Estimation anti-pattern that we’d suffered from in the past, because we were now looking at sizing the project as a whole to start with, as opposed to trying to break it up and estimate each constituent part.

The problem was when we had to estimate something that wasn’t really similar to anything we’d built before.

Overall things improved during 2011 – the people doing the work had more control, and we had a method by which to size things, and plan work. But then things started to unravel…

2012

It gradually became clear that some of the things that we thought were working, weren’t really…

Story Points

The business didn’t understand the concept of Ideal days, so we re-branded them as Story Points, where a story point equates to an ideal day. This didn’t really help though as we never built a shared understanding that Story Points are a relative measure of size, as opposed to an exact measure of time taken to do something.

“How big is the project?”

“30 points”

“You have five developers, so it’ll be done in six days?”

“Erm…maybe…”

What’s velocity?

The concept of Velocity was never been well understood by the business either. It became seen as a measure of efficiency, or utilisation. To paraphrase:

Manager One: “What’s velocity?”

Manager Two: “It’s the time that developers aren’t working – like when they go for lunch or a p*ss”

and so the percentage thing came back to bite us – velocity was used as a stick to beat the teams with -

“The Developers are only working at 60%, we need to get them to work at 70%”

Targets

We moved away from planning based on past performance and trying to improve on that, to planning based on fixed targets per developer. The Target Estimation anti-pattern again.

To increase speed; targets were set for developers to develop a certain amount of work each week.

The planning was based on one big resource pool of developers (only), with individual targets aggregating up into one giant target.

The focus was on individual developer productivity rather than actual throughput of developed and tested stories. This led to a bad working environment, much frustration, and undesirable behaviours.

Some teams adopted the Velocity-driven estimation anti-pattern in order to get around the targets they were set. But it didn’t mean they were delivering any more work – it just meant that Story Points became even more meaningless…

Budgets

A positive thing we introduced in 2012 was the idea of budgets for pieces of work. This was the starting point for turning the question around and establishing what each piece of work is worth to the business -

“How long will this project take you?”

“We’re not sure yet. How long would you like us to spend working on it?”

Developers-only

As you’ll have picked up from the story so far – the vast majority of the focus was on Developers, and only Developers. They were widely regarded as the limiting ‘golden’ resource, and as such theirs was the only work that needed estimating – everything else that needed to be done like story-writing, deployment and testing would just fall into place.

This is partly the Done-done-driven Estimation anti-pattern. The problem with focussing on just Developers is that they cannot deliver work in isolation. There are many inter-dependencies on other roles such as BAs, EAs, Testers, Infrastructure, DBAs and so on.

It is the team that delivers work, not individuals. You can try to estimate the effort that a Developer alone will have to put in to deliver a story, but that really is only a part of the work needed to deliver end-to-end.

2013

As part of the more focussed agile transformation process, we decided to have a complete re-think about how we estimate and plan at the team-level.

Principles

We came up with some principles by which we wanted to base our estimation and planning. These are based on the experience of the team, and tied in with the feedback that we received from Radtac.

§  Plan based on past performance

§  Track the whole cycle, not just development

§  Estimates are not exact quotes

§  Plan at a team level and scale up, not the other way around

§  Limit work in progress

§  Separate the methodologies used for planning, from that used for performance management

What matters

We considered having another crack at using story point estimation and velocity as it was intended, but decided that there were already too many misconceptions around this for it to be a success.

Instead we opted to try some of the more empirical techniques associated with Kanban, which tied in nicely with our move away from iterations to more of a flow-based delivery model.

The beauty of these techniques is that they focus on what matters – the question that the business want an answer to is generally

“When will we get this product?”

not

“How much effort will it take?”

We started focussing on the elapsed time that it took to deliver things, as opposed to how much effort a particular role puts in to get it there.

Efficiency

An eye-opening aspect of this is to look at Business Process Efficiency (BPE) – which is the ratio of the time that a piece of work is actively being worked on (by anyone), to the total time that it takes to deliver that piece of work.

Many organisation are working with a typical BPE of just 15%. So for the vast majority of the time it takes to deliver something, that thing is just sat waiting to be worked on – perhaps at a handover between roles or teams. So all the work we put in to estimate effort was really only focussed on a very small portion of the time it takes to deliver – and focussing on developers only magnified this even more!

The here and now

Flow and Forecasting

Where we are now is that the teams aim to split stories up nice and small. They then count the number of stories in each state of their kanban system each day. We use this to track each teams’ flow.

We generate Cumulative Flow Diagrams (CFD) and record team throughput. Both of these can be used to forecast future delivery. The great part is that this is not based on anyone’s judgement of the size of a piece of work – it is based on the actual empirical figures for how long it takes to deliver.

Cycle Time

We track the Cycle Time for stories – this is the time it takes to deliver a story end-to-end. It is currently surprisingly high, and we’re challenging teams to see what they can do to reduce their cycle times – the quickest win for this is to reduce the time that stories sit in a particular state waiting for someone to pull them into the next. We can improve on this by limiting the number of things that we work on at any one time.

Sizing

When we set out with this method of using empirical data to forecast, instead of estimating, we were concerned about the disparity in the size of stories. If we’re just counting stories what would happen if we delivered all of the smaller stories first, and were left with all the bigger ones – it’d look like we were way further head than we really were.

To counter this we sized stories small, medium or large. We had one person per team doing this to generate some consistency, and it was a quick process that was done as part of the story’s refinement.

We then tracked CFDs for both story count, and a kind of ‘weighted count’ that took the relative size into account e.g. a medium is twice a small, and a large is twice a medium.

So this took differences in story size into account, but what we found was that over time the slope of the CFD’s accepted state was roughly the same for the weighted and non-weighted count. A forecast based on story count alone should be as accurate as the forecast that takes story size into account.

For this reason, we’ve stopped sizing altogether and now just count stories. What’s key is that we aim to get a reasonable consistency of small stories.

Time-boxes

Back when we introduced budgets we started to turn around the question of how long something would take, to how long did the business want us to spend on it – what is it worth?

We’ve extended this to reinforce the idea of fixing time and flexing scope, by planning time-boxes. A project has an assigned delivery time-box during which the team pull stories from the backlog for that project. Once that time-box is over the team finish any unfinished stories off, but start pulling new stories from the next project time-box to which they’re assigned. Essentially the time-box controls which project the team pull new stories from – or in Kanban terms – where they replenish their system from.

Project cycle-time

The question that remains is what is a reasonable length of time-box to plan in for a project.

At a higher-level what we need to do next is start tracking the cycle time of overall projects. We can then use this to plan sensible time-boxes for delivery of future projects of a similar nature.

The Future

It’s been a long and sometimes frustrating journey – but it feels like we are now in a better place. We now spend a lot less time sizing and estimating things – practically none in fact.

In future we aim to widen the gathering of metrics look for further patterns to see what impacts on delivery. There are still challenges ahead as we embark on newer, bigger pieces of work, but I think we are better equipped to give honest, accurate forecasts of what can be delivered, and by when.

 Joe McGrath

NHS Choices Team

PS. If you’d asked me to estimate how long it’d take me to write this blog post I’d have said a couple of days. It took a bit longer…

To Tumblr, Love Pixel Union