Trains, Shopping and the Risk of Release Dates

This is a final post originally published on the Rally Blog which I am reposting here to keep an archived copy.


trainsI live in Brighton, on the south coast of the UK, about 50 miles from London. This means that I regularly catch the train for meetings or engagements “in town”. When making the journey, I always look at the timetable. Trains only run every 30-60 minutes, so if I get the timing wrong, then I’m most likely left hanging around at the station. Not a great use of time, especially with the typical British weather. When I get into London and need to catch the tube somewhere, however, it’s a different story. I just head to the right platform and wait for a train, knowing that one should turn up in a few minutes. There’s no need to check the timetable.

What does this have to do with Agile? I was recently on a Q&A panel and fielded a question about how to deal with fixed date and scope projects. The story above hints at the answer…

Managing Variables

Before we come to that, let’s first look at the common ‘Iron Triangle’ variables of time, cost and scope. If the date (and hence time) and scope are fixed, then logic suggests that the only thing we can vary is cost. This typically means adding people, although it could mean throwing money at the problem in some other way. Brooks’s Law, “Adding manpower to a late software project makes it later”, says that this will not work. An Agile approach can mean that any problems meeting the date and scope will be discovered earlier, and hence the effect of Brooks’s Law can be minimised. Colleague Alex Pukinskis recently blogged about how the Rally development team cheated Brooks’s Law with such an approach.

If varying cost isn’t an option, then there are a couple of other options. The first is cutting corners and reducing quality. Note that I am not recommending this option! Having said that, if the date is critical for learning and feedback regarding a value hypothesis, then quality may be less critical, assuming quality will be built in once the value is well understood.

The other variable is fidelity — this is the finesse of the solution. Delivering a low fidelity solution first ensures that scope can be met early. The functionality can then be iterated on to increase fidelity, knowing that when the date arrives — scope is in the bag.

The Alternative

There’s a less obvious solution to the problem, however. Date and scope are often fixed as a reaction to the risk of “missing the train”. We want to be sure of what we get, and when we get it, because if functionality doesn’t make it into a release, we don’t want it left on the platform waiting for the next one. We can address that risk in another way.

brixton-market-300x199

Here’s another example. We (ok, well, my wife) generally do a weekly shop at a nearby out-of-town supermarket. Because it’s weekly, we spend time planning by putting together a shopping list, thinking of everything we might need during the week. After all, if we don’t get everything we need, it will be another week until the next shop. This often results in over-stocking and the waste of throwing out unused perishable food.

However, when we go and visit a friend who lives in the small village in the Lake District, we just pop into the local shops every day to get whatever we fancy for that day. There is no need to plan ahead or make decisions on what we are going to eat days in advance. The local produce might be slightly more expensive than the big supermarkets, but it’s higher quality and there’s less wasted food. We trade-off a slight increase in cost for higher quality, deferred decisions and less waste.

So instead of worrying about how to deliver to fixed time, scope and cost constraints (not to mention quality), I would recommend figuring out how to release more frequently.

If your releases are like a tube train, arriving every day or so, then the need to plan time and scope lessens. Planning and implementing in smaller batches significantly reduces the cost, allowing more time to build the desired scope by the desired date. If a feature misses a release, it can just go into the next one straight after.

Try this approach and let me know how it goes!

karlimageiteration-300x225

 

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Estimates as Sensors

Note: this is not an April Fool – honest!

I’ve been watching the #NoEstimates conversations with interest and decided its about time to pitch in with my own perspective. I don’t want to take any ‘side’ because like most things, the answer is not black or white. Estimates can be used for both good and evil. For me they are useful as a sensing mechanism. Put another way, by estimating, I can get a sense of how well I know my actual capability.

Lets take an example. I’m taking part in a 10K run this Sunday (*) and I am estimating that I will complete the distance in 55 minutes. This is based on an understanding of my capability from participating in regular 5K runs, and more general training runs over a 10K distance. I’ve never run an official 10K race, let alone this course, and I don’t know what the conditions will be like, but I’m aiming for 55 minutes. If I run quicker and do better than my estimate, then my actual 10K capability is better than I thought. If I run slower and do worse than my estimate, then my actual 10K capability is worse than I thought. Either way,  I will learn something about how well I know my 10K capability.

What helps even more with that learning is regular feedback! I use MayMyRun on my phone to track  progress and give me feedback every kilometre for total time, average pace and last split. This could be considered a distance-based cadence. I could probably also use a time-based cadence to give me equivalent feedback every few minutes. This feedback on a regular cadence helps me decided whether my estimate was way off, or if I should slow down because my pace is probably unsustainable, or speed up because I feel I can push harder.

How does this relate to product development? Well, we can use estimates in the same way to get a sense of a teams delivery capability, and use regular feedback to learn whether we’re making the progress we thought, and need to re-plan, slow down or speed up. Time-boxing, with Story Point estimates and Velocity can provide this time-based cadence and feedback. Alternatively, how long it takes to complete 10 User Stories can be used as a distance-based cadence and feedback.

To sum up, I recommend using estimates to sense capability and create feedback for yourself. I don’t recommend using them to make promises and give guarantees to others. Or maybe we could just call them sensors instead of estimates?

(*) Of course this post is primarily an excuse to invite readers to sponsor me. If you’re so inclined, or would like to show support for this post in a charitable and financial way, then please head over to my JustGiving page and do so there 🙂

Update: My final time was 49:23 based on the timing chip, or 49:30 from the starting gun. I’ve learned that I’m better than I thought I was, and next time I’ll be estimating 50 minutes!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Three Kanban Reminders

I seem to have had a number of conversations recently which have all had some common themes. The general pattern has been that someone wants to talk about Kanban and let me know how its not working for them in some way. When I enquire further, and dig into the background some more, I’ve found that there are generally 3 things missing or misunderstood.

  1. You still need discipline. I hear of teams who find traditional agile practices difficult, for various reasons, some which may be valid, and some which may not. They decide to drop those practices, which may or may not be due to a lack of discipline. Dropping those practices, and just keeping the board, does not mean they have a Kanban System. In fact, if the board doesn’t have WIP limits, its not really even a Kanban Board! Whether or not teams have the discipline to follow their original process, they do need to have the discipline to define their own process by creating explicit policies.
  2. You still need cadence. The most common instance of a dropped practice that I hear is that of the time-box. The complaint is then that the team loses their rhythm, and that they have nothing to give them short term focus. They lose their sense of capability. What they have done is gone from a tightly coupled metronomic cadence, to an asynchronous, random and imperceivable cadence. There is a middle ground of a loosely coupled, poly-rhythmic cadence which is more resilient to the nature of their work, yet provides an ability to sense. As described above, it takes discipline to define this cadence.
  3. You still need people. The last misconception is that a Kanban-based approach is removing people from the equation again by trying to simply optimise the current process. Personally, this is why I talk about increasing Potential as one of the impacts we want a Kanban System to have. The potential of a system – its ability to improve over time – is grounded in the human potential of the people who are a fundamental part of the system. Its the people, and their connections and collaborations, who are best placed to know how to change the system for the better now, and be able to continue to change the system as the landscape changes.

I believe that attendees at the recent Kanban Leadership Retreat in San Diego were having similar experiences and I saw on twitter that the phrase “there’s a lot of sh*t out there” was used! This is partly why I came up with the Kanban Thinking model. As I alluded to when I talked about Cargo Cult Kanban, the Kanban community is not copying Toyota’s Kanban implementation tool, but the thinking behind it. If you trying a Kanban-based approach and its not working, think about why, identify something to change, and run an experiment. See, its not really that different to Agile!

 

VN:F [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)

A Model for Creating a Kanban System

This post is a high level overview of the model I use when I think about Kanban Systems. As the saying goes, “all models are wrong, some are useful”. This is what I currently find useful based on working with teams and organisations in recent years.

At the heart of the model is Systems Thinking. Without looking at what we do as part of a system, with a purpose to be met by outcomes, we risk focusing too heavily on the activities and practices we perform. Having a clear understanding of a systems purpose, from a customers perspective, helps us to design a method which serves that purpose.

The model then has three foundational building blocks which underpin an effective process; Flow, Value and Capability.

  • Flow – Keeping the work progressing and avoiding delays by focusing more on the movement of the work, and less on the movement of the worker.
  • Value – Ensuring that the work serves the system’s purpose, satisfying customers and stakeholders and resulting in successful organisations.
  • Capability – Creating knowledge of how well the work serves the system’s purpose in order to maintain and improve the system’s effectiveness over time.

In other words, we want to flow value through capability teams.

Finally, the model has five aspects, from which we can look at a process to help us understand and improve it; Workflow, Visualisation, Work in Process, Cadence and Learning.

  • Workflow – how does the work progress through the system? Understanding workflow helps improve how the work moves from concept to consumption.
  • Visualisation – where is the work in the system? Understanding visualisation helps create a common mental model of the current state of the work.
  • Work in Process – what work is in the system? Understanding Work In Process helps identify bottlenecks and impediments to improving flow.
  • Cadence – when does the work in the system happen? Understanding Cadence helps with co-coordinating the work and improving system reliability.
  • Learning – how does the system continuously improve? Understanding further models with which to view and explore the system ensures the system gets better at serving its purpose.

While this is only a model, and contains no specific practices, I believe that it can be useful in describing why some techniques work in some circumstances, and provide context for applying the right tool to the right job.

VN:F [1.9.22_1171]
Rating: 3.6/5 (5 votes cast)

What is Cadence?

Mark Stringer gave me some good feedback recently, that I clearly hadn’t described what I meant be Cadence at the recent miniSPA conference. In order to try and correct that, I thought I’d try and clarify with a blog post that it not simply variable length iterations.

The purpose of a cadence is to establish a reliable and dependable capability which demonstrates a predictable capacity. Cadence gives some confidence in the upcoming work when we are triggering rather than scheduling work.

Time-boxing is one specialised form of cadence. It’s like a metronome, giving a single tick. All the main process events are based around this single tick, as shown below where the dotted vertical lines represent the Sprint boundaries. In this example, the unit of work is a User Story, and User Stories should be small enough to be scheduled into a Sprint, and subsequently completed in the same Sprint. Stories in Progress are limited to two, as a good Scrum team might, but Stories don’t always fit exactly into a Sprint. Note also, that while releases can happen each Sprint, User Stories are only potentially shippable product increments.

Sprint

Kanban on the other hand has a cadence which is more like a drummer. The rhythm is more complex than the single tick of a metronome, and can be more varied, as shown below. In this example, the unit of work is a Minimal Marketable Feature, which while needing to be as small as possible, is not constrained be being required to fit into a schedule. Instead, an MMF is able to flow over a number of process events while it delivers some releasable value. Planning, reviewing, retrospection and releasing all still happen regularly, but they are de-coupled. They can happen independently, at differing rates, which may provide more freedom in creating a natural process which enables the team.

Kanban

A cadence is usually ‘harmonic’, in that there is a neat overlap between the different rhythms, as in this example. However, it does not have to be. A look at some definitions of cadence can show why. These are some favourites I picked off dictionary.com

  • In music, the ending of a phrase, perceived as a rhythmic or melodic articulation or a harmonic change or all of these; in a larger sense, a cadence may be a demarcation of a half-phrase, of a section of music, or of an entire movement
  • Music. A progression of chords moving to a harmonic close, point of rest, or sense of resolution.
  • The flow or rhythm of events, esp. the pattern in which something is experienced: the frenetic cadence of modern life.

Thus cadence is what gives a team a feeling of demarcation, progression, resolution or flow. A pattern which allows the team to know what they are doing and when it will be done. For very small, or mature teams, this cadence could by complex, arrhythmic or syncopated. However, it is enough to allow a team to make reliable commitments because recognising their cadence allows them to understand their capability or capacity.

VN:F [1.9.22_1171]
Rating: 2.8/5 (18 votes cast)

The Kanban, Flow and Cadence Simulation

I use a simulation when I have time in presentations on Kanban, Flow and Cadence, which I hope makes the ideas a bitter clearer and more concrete.  I was asked if I could make the materials available, so here they are with an explanation.  Its not perfect, and can be slow and time consuming, so I’d love any feedback on how to speed it up and make it a bit snapper.

The simulation uses an example work flow with 5 stages; Analysis, Design, Code, Test and Release, and a set of Minimal Marketable Features which require varying amounts of effort at each stage.  The kanban board is set-up as below with WIP and Completed columns for each stage

kanban-board
The MMFs can be printed from this MMF document.  If you want to create your own, they are generated from a MMF spreadsheet with a MMF mail merge.

An MMF progresses through the system by rolling a dice for each days work per stage and subtracting the appropriate effort from the relevant total.  When a total reaches zero, the MMF can progress to the next stage.

mmf-card

This MMF requires 3 units of Analysis effort, 1 unit of Design effort, 4 units of Code effort etc.  If the Analysis role throws a 2, then there is 1 unit of effort remaining.  If they throw a 3 then there is 0 effort remaining and the MMF can proceed into Design.  If they throw a 4, then there is 0 effort remaining, the MMF can proceed into Design, and 1 unit can be used on the next MMF.

The simulation proceeds by each role throwing a dice once per day, from Analysis to Release, and pushing work through the system.  After each week (5 days) we can update the metrics spreadsheet with the current status.  For each MMF, set its its status in the Column for week 2 (i.e. the beginning of week 2).  In addition, to show how much work was started each week, set the status for all the new MMFs to Not Started in the Columns for week 1.

metrics-week-2

Continue for 3 or 4 weeks and you should start seeing a bottleneck.  The effort numbers on the MMF cards are deliberately weighted so that Code requires more effort than the other stages.  Hence in the CFD you can see that Test and Release are starved, while and Design is backing up.  You can also see that Lead Time is going up, but that Throughput has settled at 4 MMFs per week.

cfd-week-5 lead-time-week-5 throughput-week-5

If we continued to work this way we can predict that these trends would continue.  Code would be a bottleneck, causing lead time to grow, and constraining throughput.  However, at this point we can introduce kanban limits. I tend to set a single limit across both the stage and its completed column as I find this simpler.  An alternative could be to have each column have a limit of 2.  As we are implementing a kanban system we should also pull the work by rolling the dice from Release back to Analysis.

We can also re-focus our available effort to help Code be more productive.  We do this by artificially weighting the dice.  A normal dice has an average throw of 3.5.  By reducing the average throw to 3 for Analysis and Test, we can increase the average throw for Code to 4.  The following table shows how this works.  For example, to get an average throw of 3, a roll of 5 or 6 translates to 4.

dice-weighting

Running like this for another 3 or 4 weeks should clear the backlog, giving smoother flow and resulting in Lead Time coming back down.  Throughput may also improve  as we have made Code more productive.  At this point further tweaks to the system may suggest themselves.  Shifting the allocation of effort by further weighting the dice may is one option.  Adjusting the limits is another.  Run until all the MMFs have been completed and see how the graphs look.

cfd-week-13lead-time-week-13throughput-week-13

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kanban, Flow and Cadence

Intro

There has been some noticeable increase in interest in Kanban recently, with a number of people asking for more basic info, and more people writing new blogs and articles.  This is my attempt to describe in more detail my take on it all, which I refer to as Kanban, Flow and Cadence.

  • Kanban – Controlled Work
  • Flow – Effective Work
  • Cadence – Reliable Work

Kanban

A Kanban system is a mechanism for controlling the work in the software development system.  Kanban can be defined as “visual card”, as shown below – kindly written for me by Kenji Hiranabe at Agile 2008.

The origin of kanban is the Toyota Production System. Taiichi Ohno, in his book Toyota Production System, wrote:

“The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban.”

Kanban is what enables a pull system for just-in-time work.

What does a Kanban System look like for software development?  Very simply, there is a queue of work, which goes through a number of stages of development until its done.  When work is completed in a stage, it goes into a downstream queue for the next stage.  When someone needs new work to do, they pull it from their upstream queue.  This can be depicted as below.

That looks very like a typical Agile Task Board, with maybe a few more steps, although there is nothing to say there can’t be a single development stage. However, there is one more important element which really defines a kanban system – limits.  There are two basic limits – Queue limits and WIP limits.

Queue limits are designed to avoid premature work.  This how just-in-time is achieved.  The limit should be large enough to keep the team busy (i.e. there is always something in it for the team to start work on), but small enough to avoid premature prioritisation (i.e. having things sitting in the queue for too long before they are begun).  Ideally the queue should be FIFO, although this is a guideline rather than a hard rule, as sometimes available skills or other resources mean that it is not always possible.

Work In Progress limits are designed to reduce multi-tasking, maximise throughput, and enhance teamwork.

Reducing multitasking is beneficial for two primary reasons.

1) 20% time is lost to context switching per ‘task’, so fewer tasks means less time lost (from Gerald Weinberg, Quality Software Management: Systems Thinking)

2) Performing tasks sequentially yields results sooner.  As the diagram below shows, multi-tasking A, B and C (on the top), delivers A much later, and even C slightly later, than sequentially (on the bottom).

A great exercise to demonstrate the effects of multi-tasking was described by Clarke Ching.

Throughput is also maximised by decreasing WIP.  Simple examples of this effect are traffic jams, where traffic speed reduces as more traffic builds up, and CPU load, where application performance goes down as CPU load increases.  The effect can be be explained by looking at Little’s Law for Queuing Theory:

Total Cycle Time = Number of Things in Progress / Average Completion Rate

Therefore, to improve cycle time there are two options; reduce the number of things in process or improve the average completion rate.  Of the two, reducing the number of things in progress is the easier, and once that is under control, then the more challenging changes to improve completion rate can be applied.

Finally, by having fewer work items in progress, then the team is able to focus more on the larger goals, and less on individual tasks, thus encouraging a swarming effect, and enhancing teamwork.

Limiting Work In Progress like this can seem unusual for teams, and there is often a worry that team members will be idle because they having no work to do, but are unable to pull any new work.  The following guidelines can be useful to help in this situation.

  1. Can you help progress an existing kanban? Work on that.
  2. Don’t have the right skills? Find the bottleneck and work to release it.
  3. Don’t have the right skills? Pull in work from the queue.
  4. Can’t start anything in the queue? Is there any lower priority to start investigating?
  5. There is nothing lower priority? Find other interesting work.

They key question here are what constitutes lower priority investigative work or other interesting work.  Essentially it is work which won’t create any work downstream, will improve future throughput and can be paused as soon as existing kanban related work is available.  Lower priority work could be spikes or analysis for known impending work.  Other interesting work could be refactoring, tool automation, personal development or innovation.

WIP limit sizes can depend on type of work and size of team and should be adjusted to achieve maximum flow.  One approach is to start small (e.g. a limit of 1) and increase as necessary.  Another is to start larger (e.g. a limit of half the team size) and reduce until the sweetspot is achieved.

The consequences of using a kanban system are that the Product Backlog can be eliminated, because the immediate queue is the only work of interest, timeboxed iterations (i.e.Sprints) can be eliminated, because work is pulled as necessary, and estimation can be eliminated, because work is not planned into iterations.

Flow

Flow describes how the work in the system can delivery maximum value.  As Mary and Tom Poppendieck write,

“In lean enterprises, traditional organizational structures give way to new team-oriented organizations which are centred on the flow of value, not on functional expertise.”

In particular, Lean emphasises ‘One Piece Flow’.  This means moving one piece at a time between stages in a workflow as opposed to moving  batches of work between stages in a workflow.  The ‘One Piece’ in a Kanban system for software development can be thought as the Minimal Marketable Feature, as described by M Denne & H Cleland-Huang in Software by Numbers.

“A minimal marketable feature is a chunk of functionality that delivers a subset of the customer’s  requirements, and that is capable of returning value to the customer when released as an independent entity”.

The kanbans should be minimal so that they are as small as possible in order to enable progressive delivery  to realise the product sooner, reduce feature bloat and focus on the the core features which are the most important, and minimise complexity because each feature has a cost to a user.

The kanbans should be marketable in a number of ways.

  • Table Stakes – these delivery parity to the competition and are the minimum needed to be in the game
  • Differentiators – these differentiate the product from the competition and delight the user
  • Spoilers – these nullify a competitors differentiator and raise the bar for parity
  • Cost Reducers – these reduce cost and improves the profit margin

A useful guideline is that an MMF is marketable if it is something that could be written about on a product blog.

The kanbans should be features which are distinct, deliverable and observable.  The INVEST acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable) as described by Bill Wake, can also be useful for applying to MMFs.

The Marketable element of MMFs means that they may sometimes be larger than typical User Stories, which often break work down such that while they can be incrementally delivered, and show some element of value, they are not marketable in their own right.  Therefore, it is important to understand an MMFs Value Stream in order to deliver the whole MMF as quickly as possible.  A value stream describes the steps, delays and information required to deliver a product, and can often be used to decide the steps in an initial kanban system.  With large MMFs, the User Stories become more of an analysis technique in order to enable incremental delivery of an MMF, without losing sight of the overarching MMF.  I describe how a continuous flow can be achieved with MMFs in The Anatomy of an MMF.

A number of techniques can help manage the relationships between MMFs and User Stories in order to realise the benefits of both.  One is User Story Mapping, as descried by Jeff Patton.

I have also recently been working in a regulated environment where User Case Goals and Sub Goals have provided the MMFs, with the detailed scenario paths and steps providing the additional details.

A further enhancement is to use two-tier Kanbans, with one tier for the MMFs, and another for the User Stories.

The consequence of applying the concept of Flow is that emphasis is placed on using larger, value-focussed MMFs, rather than smaller, more incremental Stories.

Cadence

Cadence is the approach to achieving commitment and reliability with a kanban system.  I often get a question something along the lines of,

“If the team isn’t estimating or planning with fixed time-boxes, how can it make reliable commitments?”

To quote Mary and Tom Poppendieck again,

“A regular cadence, or ‘heartbeat,’ establishes the capability of a team to reliably deliver working software at a dependable velocity.  An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity.”

The time-boxed iteration is one form of cadence, which couples planning, review and release together.  A kanban system de-couples these events and allows them to have separate cadences, as well as adding two additional ones.  Throughput is the amount of output of a process in a given period of time, and Cycle Time is the length of time to complete a process.  The relationship between the two is:

Throughput = WIP / Cycle Time

Throughput allows forecasting of future capability, without needing to specify what might be delivered.  Cycle Time allows commitment by becoming an SLA with the business (see Kanban Commitment).  Where the size of work varies, from large new features to small fixes and change requests, then a classification of MMFs can enable a range of cycle-times.  Both Throughput and Cycle Time can be charted and trended, in a similar way to XP’s Velocity, as a means to encourage the team to improve.  A Cumulative Flow Diagram can also make visible how the work is flowing through the system and highlight bottlenecks.

For longer term forecasting, a quarterly planning cadence focusses on quarterly goals and objectives.  MMFs can subsequently prioritised to meet those goals and objectives.  A regular release cadence will build up trust that the team will work to its full capacity and throughput.

Other cadences, are daily stand-up meetings, and regular retrospectives and Operations Reviews as described by David Anderson.  Some teams are using a Retrospective Kanban to signal when a retrospective is necessary, and I have already blogged briefly about Kanban and Retrospectives.

The consequence of Cadence is that commitment and reliability is achieved though measurement as opposed to planning.

Summary

They key points of Kanban, Flow and Cadence are:

  • A Kanban System manages the workflow in a way which allows the Product Backlog, Timeboxed Iterations and Estimations to be eliminated.
  • Flow is about effectively delivering maximum value by focussing on optimising the value stream of larger MMFs
  • Cadence allows iteration input and output to be de-coupled and achieves commitment and reliability via measurement rather than planning.

Further resources and information can be  on my Kanban Page, including most of the material which has influenced and directed my thinking.

VN:F [1.9.22_1171]
Rating: 4.8/5 (30 votes cast)

KFC Consequences

One of the regular questions I get asked when I talk to people about KFC Development is about how it is different.  As a result I came up with a set of KFC Consequences to try and help articulate this.

  • Kanban Consequence – Eliminate backlogs, timeboxed iterations and estimates.

Eliminate might be a slightly strong word, but there is certainly less reliance on these things, and thus less wasted investment in them.  Ultimately a high performing team would not need them in a typically recognisable form, although they may use variations.  For example, an ‘incubation area’ might replace the backlog as a simple place to keeping ideas before they are refined into MMFs.  Similarly, classification might replace estimation.

  • Flow Consequence – Use larger, value focussed features

Rather than an emphasis on driving user stories into smaller and smaller pieces, there is more of an emphasis on right-sizing pieces of work based on their value.  User story decomposition is used more as an analysis technique.

  • Cadence Consequence – Commitment via measurement and SLAs, rather than planning and timeboxes.

Instead of planning batches of work into timeboxed iterations as a mechanism drive productivity and commitment, the mean lead time of MMFs is measured and used as an SLA against which due date performance is reported.  Thus it is actual performance which drives productivity, rather than forecast performance.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

KFC Development

I’ve been referring to my latest thinking on development process as KFC Development. Its a bit of a gimmicky name, which makes it memorable, but there is some meaning behind it. KFC stands for Kanban, Flow and Cadence – three lean concepts which I think are important and complementary.

Kanban – Kanban is the mechanism which controls the workflow and helps manage inventory and investment, and identify bottlenecks.

Flow – More specifically One Piece Flow. The one-piece is a Minimal Marketable Feature (MMF) which ensures there is focus on the delivery of actual value. This avoids the temptation to artificially break work down into smaller chunks in order to fit them it into an iteration or sprint. A side effect of this flow, is that typical agile time-boxed iterations can become unnecessary.

Cadence – Cadences give the team the rhythm usually provided by time-boxed iterations. There can be a variety of cadences, from daily stand-ups, to quarterly roadmap planning. An additional cadence is that defined by cycle-time, which determines throughput, and allows a level of forecasting of future work.

I’m hoping to explore these ideas more in the future.

VN:F [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)