Teaming the Push and Pull of People and Projects

Four people gathered around a fifth person at a computer, representing teaming.

The Agile movement popularised a shift to teams which could pull their work, rather than having work pushed onto them. Practices such as Sprint Planning, or WIP Limits enable this. However, I’ve recently been thinking that rather than the people pulling the work, the work should be pulling the people. This seems counter-intuitive, and equivalent to going back to the traditional project-based approach of the past. To differentiate the different approaches, I will describe three basic teaming models.

Pushing People to the Work

This is the typical project teaming model. First, a central group (e.g. a PMO) defines the work up front as a project. Then they form teams and people are pushed to the work by allocating them to the projects. The diagram below visualises this, with the work at the centre, and people being pushed onto it. Apologies for the terrible artwork. I have tweaked the graphics from slides I used for Kanban presentations over 10 years ago!

A represention of teaming which pushes people to the work. Work is in the middle, surrounded by people being pushed towards it.

In reality, people are often pushed onto multiple projects, making things even worse. In the next diagram, notice the unlucky person in the middle who has been allocated across (pushed to) three projects. At the same time, once people have been pushed onto projects, the actual work is often pushed back onto them. Time, scope and cost are fixed, with no allowance for their actual capacity or capability to do the work.

A represention of teaming which pushes people to the work, with multiple projects. Some people are surrounding and being pushed to multiple projects.

People Pull the Work

This is the typical Agile teaming model. First, long-lived and stable teams are formed to align to some product or value stream. Then the work is defined as backlog items (or options) and the teams pull that work as their capacity and capability allow in order to deliver value.

A represention of teaming where people pull the work. Value is in the middle, surrounded by people, and those people are pulling work from a backlog.  There are two teams with two backlogs.

While this model is typically used with single agile teams, it can also be applied at scale with teams of teams. SAFe’s Agile Release Train structure usually consists of pre-formed and fixed teams that have a backlog of work to pull. As a result, PI Planning is often an exercise in managing dependencies between teams by adjusting the backlog and scheduling items into iterations.

Work Pulls the People

This is more of a Dynamic Reteaming model. First, a value stream is identified, and work is defined as backlog items (or options) to flow through the value stream. At the same time, a pool of people is also identified as part of that value stream. Then the people self-organise themselves into teams as necessary to deliver the highest value work, to the best quality, with the fastest flow. Thus, while the work is pulled into the value stream as capacity allows, it then pulls the people required to enable the flow. As new work is pulled in, the teams may reform to better match the skills and experience required by the changes in demand.

What this looks like in practice is a regular cadence where people can come together to review the current work and anticipate future work. In doing so they can re-organise themselves to deliver the highest value work, at the earliest date, to the best quality. A more general quarterly “Big Room Planning” (as opposed to SAFe’s PI Planning format) can be a good way of doing this.

A represention of teaming where the work is pulling the people. Work is in the middle, surrounded by people, with the work pulling those people. The work is part of a backlog with is being pulled to deliver value.

Also, notice that in the above diagram, not everyone is on a team. Sometimes, it makes sense for people to float between teams to enable them to get better. Or they may form an enabling team of their own as per Team Topologies. Similarly, there will realistically be some constraints around who should be on each team. This may be with respect to experience and continuity to maintain consistency and quality of what is being built. Effectively, this dynamic reteaming model shifts team formation away from governing constraints which are independent of the work context. Instead, it shifts towards enabling constraints which allow for the context of the work.

Making an Impact with Kanban Thinking

This post pulls together a number of ideas  on impact into a single place, and will become the content for a page in Impact on the Kanban Thinking site.

What is Impact

Outputs creates Outcomes which have Impact.

Designing a Kanban System involves the evolution and discovery of a good design. It cannot be pre-determined in advance. Thus instead of defining a future-state and working towards it, we start with the current-state and work away from it, exploring and assessing different alternatives. Each output of a design iteration will create different outcomes, and those that improve the system can be said to have a positive impact, while those that worsen the system have a negative impact.

Impact, therefore, describes the disposition of the system, or its tendency to behave in a certain way. Rather than defining a planned destination, impact points to the desired direction, such that we can check whether any changes are moving us towards or away from the direction we want to be heading. Impact can be assessed by using narrative techniques to capture stories about utopian (and dystopian) futures, and subsequently asking whether an outcome is likely to lead to more of the positive stories and fewer of the negative stories.

Describing Impacts

When imagining what impacts would be desirable, its easy for our experiences and biases to lead us to narrow our thinking and prematurely converge on only one particular type of impact. To avoid this, and encourage diversity in exploring a wide variety of potential impacts, Kanban Thinking describes three types to consider, giving different perspectives.

  • Flow. This is Doing the Thing Right. Stories will be primarily related to the process, efficiency and reliability.
  • Value. This is Doing the Right Thing. Stories will be primarily related to the product, effectiveness and validity.
  • Potential. This is Doing the Thing Sustainably. Stories will be primarily related to people, euphoria and flexibility.

Impacts as Triads

When exploring the impacts, it will become apparent that there is not always an obvious and neat mapping to either flow, value or potential. Thus, the three impacts can be thought of as a triad, with each being a vertex of a triangle.

Triads are concept I learned from Dave Snowden and used by the Cognitive Edge Sensemaker Suite (note that they have a patent associated with this), where a triangle is used as a measuring instrument to assess against three parameters. By using triads, impacts can be placed relative to where they have the strongest affinity, without having to decide on any one in particular. Imagine an impact being connected to each vertex with elastic. The greater the affinity to a vertex, the greater the tension, with the final position being a result of the combination of all three. Thus the story in the triad below has the strongest affinity with the Flow vertex. The next strongest is Potential, with Value being the weakest.

Impact Triad

While triads are an approach not directly supported by the canvas in its current form, the deliberate choice of words to describe each impact creates multiple possible triads which could be explored. Deciding where an impact goes generally requires more thinking, and generates greater dialogue and insight.

FlowValuePotential
Thing RightRight ThingThing Sustainably
ProcessProductPeople
ReliabilityValidityFlexibility
EfficiencyEffectivenessEuphoria

Generating lots of utopian (and dystopian) future stories, instrumented with these triads, will generate patterns which can give a sense of where the improvement opportunities are for making an impact.

Example

Here’s an example of thinking about impact from the three perspectives. It is intentionally lacking in direct relevance to minimise the risk of biasing your own answers to the questions.

When I go running, I’m generally wanting to improve my health and fitness. What impact do I want to have?

  • From a Flow perspective, impact could be about pace and speed. I could imagine a utopian future where I can run a 4 minute mile.
  • From a Value perspective, impact could be about distance and stamina. I could imagine a utopian future where I can run 100 miles.
  • From a Potential perspective, impact could be about friendship and community. I could imagine a utopian future where I am the president of a local running club.

None of these are mutually exclusive. If I can run a 4 minute mile, then there is a high likelihood that I’ll be involved in a running club, and training longer distances as well. However, explicitly exploring the different perspectives avoids me just focussing on one thing such as speed, to the detriment of friendship or stamina.

What stories would you like to tell about the impact your kanban system makes in the future?

Announcing The Lego Flow Game

I have just published a page for the Lego Flow Game – a new game that I have co-created with Dr. Sallyann Freudenberg. Its based on an ‘experiment’ I originally ran in 2010 at the SPA conference. Then I used an exercise of matching, solving and checking equations to explore and experience workflow with different types of processes and policies. While this worked in terms of having a game that consisted of knowledge work, it turned out to be painfully tedious and hard work, which detracted from the main learning objectives. Sal was in the audience that day, and took the concept and evolved it by swapping in Lego building instead of the mathematics. We’ve run the updated version a few time over the last 6 months or so, and made some tweaks to the rules and timings, and we’re pretty happy with the latest version – hence publishing it.

The most recent outing was at the Kanban Coaching Exchange in London last week. It was pretty chaotic with around 50 people attending in a relatively small space, and only 3 full kits – we need to stock up on staplers! That meant that there were lots of observers – if you were there, we thank you for your patience. It didn’t help that we were also missing the right cable to connect a laptop to the TV in the room, so we had to explain the exercise without any supporting slides, and I had to show the end-result Cumulative Flow Diagrams by holding my laptop over my head. Given all that, there seemed to be high energy, good discussion and overall the feedback seemed positive. If we can run the exercise successfully in that environment, then it’ll probably work in most situations!

You can find the full instructions on the main page – please let us know if anything isn’t clear. You’ll also find the slides and spreadsheet to go with the exercise there. There are some photographs from the Kanban Coaching Exchange session on the event page and I’ll add any others that I come across here as well.

Here are the final spreadsheets for the 3 teams. I’ll briefly describe what I interpret from one of them (team 1).

Round 1 is a ‘waterfall-like’ process, or batch and stage. In other words, the work flows through the process in a single batch, one stage at a time. You can see the work build up in the Analysis stage until all 5 are complete, and then moved together into Supply stage, and then Build, where the team ran out of time. Thus no items were completed. The debrief of this round mentioned that the person working felt very pressured, while everyone else was very relaxed. Waterfall is great if you’re not the critical path – and you don’t care about getting anything done!

Team 1 Batch CFD

Round 2 is a ‘scrum-like’ process, or time-boxed, with 3 x 2 minute ‘Sprints’. The time-boxes themselves are not obvious from the CFD, but its clear that there is some more flow, even if it is fairly ragged. One item is completed in the the first time-box, but the team estimated, and started four items. However, they must have learned from this, because they didn’t start anymore work in the second time-box (between minutes 2:00 ad 4:00) and they completed one more item on this time-box. For the final time-box, they decided to start one more item, and complete 2 more. If they had seen the data and the graph (I didn’t show anything until the end) they might have realised that it probably wasn’t worth starting anything in the final time-box either. Four items were completed in total. You can also start to see some predictability at the end as the built in retrospective cadence generated learning and improvement in how much work the team took on. The debrief discussed how this round tends to feel fairly chaotic with strong focus, punctuated by the retrospectives.

Team 1 Timebox CFD

Round 3 is a ‘kanban-like’ process, or purely flow-based with WIP limits. The flow is much smoother this time, and the WIP limit of 1 in each stage is clear. The slope of the graph is also fairly smooth, and its would probably be fairly easy to predict the future performance of the team. Five items were completed at almost one per minute. The debrief discussed how this round tends to be more relaxed, with a more gently hum of activity.

Team 1 Flow CFD

I hope this is useful in getting a feel for how the game works, and making it possible to run the game yourself. Please try it for yourself and let us know how you get on. In particular Sal and I would love to hear about modifications you make, or what other policies you experiment with.

The Flow Impact

As I wrote yesterday about some upcoming Rallying adventures, I get to work on some exciting projects. A recent one is the “Agile for Business” book which is being put together in an iterative and incremental manner. Bob Gower, who is spearheading the initiative, wrote a blog post last month about the background to the book.

One of my contributions will be a short piece on flow, one of the three impacts I describe in Kanban Thinking. I am reproducing the current version below, although the final version may well change.

Flow is the result of doing the thing right. It is the regular and smooth progress of work from its initial concept to its final consumption.

Work that progresses in large chunks, in a stop-start manner, does not have flow. It’s the work that progresses in small pieces, in a continuous manner, that ultimately creates the kind of flow your organization needs. By reducing completion time and enabling greater predictability and reliability, it’s this kind of work that builds trust and fosters creativity and innovation. Moreover, reducing utilization and creating spare capacity, sometimes referred to as slack, allows a greater ability to respond to changes and surprises. After all, we don’t run our servers at 100%, and we know how well traffic flows on a grid-locked road! This spare capacity is what gives us time to spend on continuous improvement and innovation.

Working on smaller and fewer pieces of work helps minimize delays and generate faster feedback. Think about a slow, sluggish cargo tanker compared to a fast and nippy speedboat. Further, balancing demand against capability, and not starting more work than you can complete, means that work isn’t left hanging around and depreciating. Imagine the pileup caused by trying to push a chain of paperclips across a table versus the smooth flow created by pulling them across.

So how does an organization go about actually achieving flow? Focus on progressing and completing a smaller number of smaller pieces of work. Make that work, and its flow, visible in a physical shared place, and when work becomes blocked, encourage teams to resolve issues and concentrate on finishing it rather than starting something new. When aspects of the workflow are identified which mean that the work does not progress as quickly and smoothly as you would like, invest time in improving the workflow in order to develop future capability.

While this may appear to reduce the amount of time one is kept busy, it’s important to remember that busyness and productivity are not the same thing.

Measuring activity, in terms of utilization, will not create great results. Instead of focussing on the worker, focus on the work product, and measure work outcomes by things like throughput for productivity, lead-time for responsiveness, and due-date performance for reliability. These are all appropriate measures of flow.

Stop starting, and start finishing.

Linking Flow, Value and Capability

I wrote recently that I have come to think about Flow, Value and Capability as the primary impacts I hope a Kanban System will have. Flow, Value and Capability are not independent entities, however, with Capability being the link between Flow and Value. We can think of Flow as “doing the thing right”, where good flow is the result of a good process. Similarly, we can think of Value as “doing the right thing”, where high value is the result of good outputs from the process. We want both, however, and we can think of Capability as “doing the right thing right”, where a good process delivers good outputs.

Flow Value Capability

Here’s another way of looking at it…

A common scenario is creating projects, and assigning people to those projects to form a project team. This is great for the project in isolation, but when the project finishes the team is usually disbanded, and all the capability that was created as tacit knowledge in the team is lost.

Project Team

A further challenge (amongst many) with this approach is that when another project comes along – and then another – people get assigned to multiple project teams, at which point they’re not really teams any more. This might seem efficient, but it is not effective, and is not good for the people or the work. In the diagram below, the person in the middle on three projects is not in a good place!

Multiple Teams

An alternative idea is to form teams around organisational capabilities – things which will enable the business to make an impact. Small pieces of valuable work which enhance this capability can then be individually pulled by these teams, creating flow. This is what I call a Capability Team.

Capability Team

Pursuing this approach, the notion of the project goes away, replaced by a Flow of Value through Capability teams who are able to “do the right thing right”. These teams can stay together for as long as the capability is important, building knowledge about all aspects of what they are building, and how they build it.

Running the Ball Flow Game

I previously wrote about the Ball Flow Game I ran at the Scrum Gathering in Amsterdam. I’ve updated the game quite a bit since then and its stabilised into something I’m finding very useful when I work with Kanban teams to help them understand some of the concepts behind Kanban Thinking. I hope this write-up enables others to use and run the game.

To recap, the Ball Flow Game is based on the Ball Point Game, with the following rules:

  • Participants play as a whole team
  • Balls must have air time between people
  • No passing to a direct neighbour
  • The start person must be the end person

The aim is to complete 20 balls (as opposed to complete as many in 2 minutes). Thanks to Rally colleague Eric Willeke I now add some fun context as well. I tell the team that they are producing magic balls. Magic is added to a ball only when everyone has touched it. If two people touch a ball at the same time, the magic is dispersed. Further, magnetic fields mean that passing a ball to a direct neighbour also stops magic being added. The start/end person is the customer wanting magic to be added to the balls. Its silly, but it adds an extra element of fun, and reinforces that the rules are constraints in the context that can’t be changed.

I use a spreadsheet to help automatically capture data about the performance of the team. (Download the template). It works using four macros, which are assigned to buttons and hot-keys:

  • Begin (Ctl-B). Begins a round by starting a timer.
  • In (Ctl-I). Captures the time a ball is added into the system.
  • Out (Ctl-O). Captures the time a ball come out of the system.
  • End (Ctl-E). Ends a round by calculating the metrics.

Once the metrics are calculated, three charts on the worksheet will populate themselves.

  • Lead Time. The time each ball took to work its way through the team (assuming balls enter and exit in the same order). The dotted line is the average.
  • Throughput. The number of balls the team completes every 10 seconds
  • Cumulative Flow Diagram. The number of balls either not started, in progress or done every 10 seconds

Upper and Lower Control Limits can also be calculated and displayed for Lead Time. They are currently commented out in the macro code because I found that they weren’t necessary for the core learning objectives. You may also need to tweak some of the macro functions for different versions of Excel (I use Windows Excel 2010). The template has worksheets for 5 rounds. For additional sheets, simply one of the existing rounds.

One of the things I’ve noticed is how the dynamics of the conversations are different from when I run the traditional Ball Point Game with teams. In particular, the team I was working with today really understood the idea of scientific management and made very small, quick and focussed changes each round as experiments, hypothesising on how the metrics would change. With the Ball Point Game I find teams want to debate in depth all the options in their attempts to get an improvement.

Note that as I said in a post of Balanced Software Development, “scientific management is still relevant for knowledge work, when the workers are the scientists.”

Here are the results. (Apparently we started with only 19 balls due to a facilitator error!)

Round 1

In this round, the customer ‘pushed’ balls into the system when he could. You can see the lead time increase as the WIP increases in the CFD, up to a point when a natural system limit is reached. Towards the end the customer stops adding more balls to let the system flush itself out a bit, which shows as the step in the CFD at about 60 seconds, the drop in lead time, and the spike in throughput. The final two balls went through when the system was virtually empty. Notice the short lead times again!

image

Round 2

In this round the team decided to limit the WIP to 6 – one per person. However, interestingly (to me at least) they decided to batch them, by getting all 6 through before they started the next 6. Lead time is much more stable this time. The spike is because the customer forgot to receive the last ball of the 1st batch before starting the 2nd batch, so it got stuck! Throughput is wildly variable though because nothing comes out for a while, and then all 6 come at once. You can see the batching in the ‘steps’ in the CFD.

image

Round 3

In this round the team wanted to experiment with an low extreme WIP limit of 1. Lead time is significantly better, but throughput is low because there is too much slack in the system now. Notice the smooth flow in the CDF. The patches where WIP drops to zero are because the customer’s process between receiving a ball out, and adding a ball in, added a noticeable delay.

image

Round 4

In this round the team increased the limit to 3, but continued to process those 3 in batches. Lead time remains the same, but with improved throughput. The CFD still shows signs of the batching with the customer delay between batches, but is much steeper due to the improved throughput.

image

Round 5

Finally, the team decided to remove the batches and solve the customer’s delay issue by re-organising themselves. This time the customer added 3 balls into the system, and then only added another when one came out. Lead time is slightly increased, probably due to the fact that there were always 3 balls in process which added some complexity. Throughput is improved again though, and the CFD is looking very smooth.

image

As you can see, the team made significant improvements over the five rounds by making small changes informed by the data they had about their flow and capability.

Starting An Agile Transition With Why

In March this year I gave this keynote at the Rally Agile Success Tour in London. This is a video of the talk, followed by a write-up. The slides can be downloaded from here.

People don’t buy WHAT you do, they buy WHY you do it. Simon Sinek says that this is the fundamental reasoning behind what he refers to as the Golden Circle, which he describes as a natural law occurring in many forms, in the same way as the Golden Ratio. He cites example of the Golden Circle including Martin Luther King, who said “I have a dream” not “I have a plan” and the Wright brothers, who succeeded first with manned flight despite having less money, education, connections and publicity as competitors. The Golden Circle suggests that we should start with WHY, before determining HOW, and finally WHAT, rather than starting with WHAT.

image

Starting an Agile transformation with WHY involves knowing why you want to use an Agile approach, and the goals you are aiming for, rather than becoming Agile just because it seems popular or a good idea. Therefore, begin by defining your WHY, deciding where you want to go and creating a vision of the future that you hope Agile will help create. Then Agile will be a means to an end, rather than an end in itself. Your WHY is your destination, and Agile can help with HOW you get there, and guide WHAT you do to get there.

WHY

A WHY is what motivates people to take action. It is a purpose, a cause or a belief. It is a reason to care and want to get out of bed in the morning. A WHY is not to make money. Money is a necessary precondition for business, in the same way that breathing is a necessary precondition to living although our purpose in life is not to breathe. Making money may also be a desirable result, but it is not a WHY.

WHY is the equivalent of the System Thinking premise of purpose. Complex Systems have a purpose which influences behaviour, the product of the system’s elements and interactions. Dave Snowden uses the Magic Roundabout in Swindon as an example of a complex system whose purpose is to enable a high throughput of cars with a low accident rate. Reports show that it achieves this purpose, despite also being generally regarded as one of the scariest roundabouts in existence. By starting with WHY, the roundabouts designers created an effective, safe and resilient WHAT. Starting with WHAT leads to the less scary but more common design.

image

WHY is always going to be context specific, but one simple generalisation would be that it is to satisfy customer demand. Demand analysis can help understanding of what work adds value, and helps us towards our WHY, and what work doesn’t add value. John Seddon describes failure demand is work that results from not doing something right, or not doing something at all. That is not to suggest that we should strive for perfection and be right first time with up front analysis and design. Value can still be added in small, incremental and iterative steps. Think of it like a ticket machine at your local deli. When a customer first takes a ticket then the request can be considered value demand. Subsequent tickets for the exactly same request can be considered failure demand. However, further tickets could be for similar, related requests because the customer comes back for more of the same, as opposed to exactly the same.

Simon Sinek argues that our brain is wired to start with WHY. Our first brain, the Limbic System is what deals with emotions, unconscious thought, instinct, and governs our behaviour. Our thinking brain, the Cerebral Cortex, is what deals with rationality, conscious thought, intellect, and governs our language. Thus, our natural behaviour is to make decisions emotionally, unconsciously, and instinctively. We then justify those decisions rationally, consciously and intellectually with facts. I have just bought a new car (well, new for me) and spent a not insignificant amount of money in a totally impulsive purchase. I had no intention of buying a car when I entered the garage, but fell in love with the car and ended up talking myself into deciding it was an opportunity I would regret if I missed it. Similarly, both times I have bought a house, which is both an important decision and major investment, the decision was because the house “felt right”. The size, condition, location, price etc. came second.

How

HOW describes the way that a WHY will be realised. It can be thought of as a set of guiding principles that help map a WHY to a WHAT. A HOW can also be a specific outcome that is to be accomplished without detailing the activity and output required to complete it. Additionally, HOWs are often ways of differentiating approaches and describing them in comparison to competitors.

One way of describing HOW an Agile approach enables a WHY is with the metaphor of a Recipe for Success. David Anderson popularised this idea with the following recipe:

  • Focus on Quality
  • Reduce WIP
  • Balance Capacity against Demand
  • Prioritise

Similarly, my colleague Ken Clyne at Rally talks about the fundamentals of Agile as:

  • Focus on customer value
  • Deliver early and often
  • Reduce batch size
  • Pull quality forward
  • Inspect and adapt
  • Create a collaborative culture

These recipes are a guide to HOW to achieve Agility in order to achieve a WHY. However, they are not specific enough to describe WHAT to do.

A common explanation for WHY organisations want to become Agile is “Better, Faster, Cheaper”. These are at best HOWs, and not WHYs. In fact, I would suggest that cheaper isn’t even a HOW. To paraphrase John Seddon, focussing on cost will usually result in cost going up.

Another approach to describing HOW to become Agile is through a transformation strategy or roadmap. Options for which path to take include beginning slowly with a single, fully Agile pilot project from which to learn, diving in and moving all project to an Agile approach in one go for clarity of message, only beginning new projects or initiatives as Agile to avoid risking current work, or incrementally solve specific challenges with certain practices for a more evolutionary transition.

Working Agreements can also be considered as a description of HOW. Explicit policies for how work is done can be created by recognising how value is created, how that creation is visualised and made transparent, how the work in process is limited, what cadences are used for synchronisation and co-ordination, and how continuous learning and improvement happens.

My personal take on HOW to be Agile is in terms of flow, value, capability. Achieving flow involves eliminating delays and focussing on reducing the lead time from concept to consumption. Delivering value involves making sure that the right things are being worked on and the right problems are being solved rather than “doing the wrong things righter”. Building capability involves developing people and their skills working as teams aligned to the organisation strategy.

What

WHAT is done proves that a WHY really is believed. It consists of tangible ways with which a WHY is realised and provides clear data points that actions are according to a WHY.

Agile practices are WHAT teams do in order to enable them to realise their WHY. Further, practices can be associated with HOW agility is demonstrated, in terms of flow, value and capability. The following is one interpretation of some practices. I’m sure there are many others.

Flow

User Stories are a technique to break down functionality into small pieces of demonstrable functionality which can create single piece flow. Time-boxing and kanban-style limits are both ways of managing WIP and enabling a focus on finishing rather than starting to keep work flowing. Visualisation approaches help teams see all the work so that they can focus their energy in the right places to keep flow. Strong teamwork and collaboration minimises the need for queues and batches which cause delays. Test Driven Development, with its emphasis on automated unit testing and refactoring, keeps designs clean and quality high so that new work can progress quickly. Continuous integration and deployment help works flow right through to the customer without lengthy release processes causing delays.

Value

Product Backlogs, User Stories, Minimal Marketable Features and other value-focussed forms of requirements are intended to help teams ensure they are delivering maximum benefit. Similarly, the On-Site Customer, or Product Owner roles are intended to maximise collaboration with people who are determining and receiving the value. Iteration demos and reviews are a means of gaining early and continuous feedback and validation that the product is delivering the intended value. Frequent and continuous delivery means that the value can be realised as soon as possible. Acceptance Test Driven Development and Behaviour Driven Development provide techniques for delivering value through quality and clarity of functionality.

Capability

Dedicated, cross-functional, value focussed teams mean that learning and knowledge is kept, shared and built upon to develop capability. Various collaborative practices, such as Pair Programming, Collective Code Ownership, Group Design, Team Estimation and Planning Poker similarly share knowledge around a team. Regular demos and reviews provide a cadence with which feedback and learning can build product capability, while regular retrospectives provide a cadence with which feedback and learning can build team capability. Visualisation of work, and the way value is created, gives visibility of bottlenecks and constraints and other issues such that they can be resolved to improve capability. Slack ensures that teams have spare capacity to both address these issues, and spend time on other forms of capability development which will improve future productivity and performance.

Conclusion

When embarking on a change initiative using Agile approaches, always “Start with WHY”. Use the WHY as a True North with which to guide the Agile transformation and steer decisions on which Agile practices to use for what reasons. Understand HOW agility is going to help progress towards the WHY, and WHAT Agile practices will provide the means to get there.

A clear WHY, that people are motivated by, will make it more likely that they will want to use Agile. However, Thomas Edison said that “vision without execution is hallucination”, so don’t stop with WHY, but make sure that the Agile HOW is also well known and the Agile practices that form the WHAT are clearly understood to ensure that the goal is successfully reached.

People and Process: Two Sides of the Same Coin

I wrote this short article for JAX Magazine, but it seems JAX doesn’t want to make it easy for people to access the content (you have to register to get a download link which only works once). So I’ve decided to post the article here as well. Its an evolution of some of my thinking that goes back to the new lean and agile picture I posted.

One of the value statements from the Agile Manifesto is “individuals and interactions over processes and tools”. This is often abbreviated to “people over process” with a common interpretation being that the human aspects of software development are the primary areas we should be focussing on for improvement. However, this is counter to the ideas of W. Edwards Deming, who said “a bad process will beat a good person every time”. Similarly, Don Reinertsen has said he prefers “people times process” because if either is zero, then the product is zero.

People and process are two sides of the same coin, both equally important in understanding how to improve capability to deliver valuable software.

People

This side of the coin is about taking a group of people, who form a team in order to develop a capability. Peter Senge wrote in ‘The Fifth Discipline’ that “the fundamental learning units in an organisation are working teams (people who need one another to produce an outcome)”. Creating teams in this way allows people to iteratively learn about the way that they work so that they can incrementally develop their capability in order to improve the outcomes that they produce.

This is the basis of all the popular Agile methods such as Scrum or Extreme Programming, which all recommend creating cross-functional and co-located teams, collaborating with high bandwidth communication. Thus, the people side suggests that forming outcome-focussed teams, rather than activity-focussed silos, will result in an improvement.

Process

This side of the coin is about taking a vision, which is developed into a product in order to deliver value. Mark Denne and Jane Cleland-Huang wrote in their book ‘Software by Numbers’ about “an ROI-informed approach to software development in which software is developed and delivered in carefully prioritized chunks of customer valued functionality”. Taking this approach means that a product will maximise its value through being iteratively refined piece by piece in order to incrementally deliver functionality.

This is the basis of Lean approaches such as Kanban, which focuses on creating an explicit understanding of the process in order to learn how to deliver valuable pieces of software more effectively by modelling and visualising the work and associated policies. Concepts such as Minimal Marketable Features and User Stories help break down the work into smaller pieces. Thus, the process side suggests that continuously delivering small pieces of functionality with minimal delays, rather than waiting to release large batches of features, will result in an improvement.

People and Process

It is when we put these two sides together that we can achieve significant improvement. The iterative loops of learning about both the team and the product link into each other enable product value to rapidly flow through capability teams. This is the development nirvana we are trying to reach.

This model also gives some insight into why the “Waterfall” model, described by Winston Royce in his 1970 paper ‘Managing the Development of Large Software Systems’, has proved to be unsuccessful. It is not because the simple work-flow described was inherently wrong, but because the work-flow has typically been implemented with specialist silos rather than capability teams, and with large rather than small batches. It is both these two sides of the coin that should be the focus of learning and improvement in order to help us on our journey to the nirvana of product development flow.

The Ball Flow Game

I was invited to the Scrum Gathering in Amsterdam this week to give a Deep Dive on Kanban. My Kanban Exploration slides can be downloaded from slideshare. Inspired by an email discussion with Jean Tabaka and Eric Willeke, to introduce the session, and to try and reinforce the concepts of Flow, Value and Capability, I tried a variation of the Ball Point Game that is commonly used in Scrum training.

Here’s a couple of links (Kane Mar) (Declan Whelan) if you’re not familiar with the game. In a nutshell it involves a group working as a team to pass balls between themselves, constrained by some rules. The idea is to pass as many balls in a 2 minute time box. The team has to self organise and inspect and adapt in order to improve its velocity (throughput of balls).

For my variation I wanted to remove the time-box to emphasise flow more, and demonstrate a different way of understanding the capability of a system. In the game, the team are designing a system to meet the purpose of flowing balls quickly between themselves.

The changes I made were to ask the team to pass 20 balls as quickly as possible. I put a unique number (1 – 20) on each ball in case it was useful and also asked the team to time how long it took for each ball to pass through the system.  I took the data that was captured and entered it into a spreadsheet to create a control chart. We ran two rounds of the game twice, with the respective charts below.

Round 1

image

In Round 1, the team didn’t capture all the data, and some problems were had towards the end, but that the average time for each ball was 13 seconds. The system could also be said to be ‘in control’ as all the data points were with the control limits  which were calculated as AVERAGE +/- (3 * STDEV). The last measured ball was completed at 3 minutes and 35 seconds.

Round 2

image

In round 2, the team improved their data capture process and overall flow. The average time per ball dropped to 12 seconds and the variability also reduced. The Upper Control Limit dropped from 01:10 to 00:18. The last measured ball was completed at 2 minutes and 22 seconds.

What this demonstrates is that even with variability (which we don’t want to eliminate completely in software product development), by understanding the capability of the system over time, we are able to reliably communicate what might and might not be possible. For example, using the round 2 data, there is a 50% chance we’ll complete a ball in 12 seconds and a 99% chance we’ll complete a ball in 18 seconds.

We could also calculate and chart the throughput of balls completed over a cadence of 30 seconds to similarly understand the capability from that perspective also. For Round 2 those throughputs would have been 3, 4, 4, 5, 4.

There are a few areas I’d change next time I try this.

  1. The measurement took a long time and was clearly the significant bottleneck. I made measurement part of the system to add some additional complexity, but in hindsight it was probably too much. Most of the improvements were in measuring the system rather than the performance of the system.
  2. I allowed more time than I probably should have for improvement discussions. With the time-boxed version its easier to start the clock for a round and that usually that kicks the team into action. Similarly, when the measurement fell apart we stopped and restarted a couple of times. I wouldn’t do that next time, although by removing measurement from the system, it might be less of a problem.
  3. It took time to enter the data into the spreadsheet. I need to find a better way! The spreadsheet can be found here. It’s very simplistic. Please let me know if you use it and improve it!

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.