"Agile" via Ken in Google Reader

Running the Ball Flow Game

2011-07-19T21:57:15Z

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!

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.

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.

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.

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.

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.

Frequently Forgotten Fundamental Facts about Software Engineering

2011-04-29T18:35:39Z

Comments

Distributed ScrumMasters Update

2011-03-30T21:00:40Z

It has been over a year since I first gave my Distributed ScrumMasters talk to friends & coworkers around Washington, DC. Since then I’ve learned quite a bit about myself, how I speak publicly and what people are most concerned about with Distributed Scrum.

After careful consideration, inspecting and adapting I have updated my original presentation to reflect all that I have learned.

Distributed ScrumMasters and the art of digital facilitation

View more presentations from David Bland

If you find this useful, please share it with your friends and colleagues.

I feel as though ScrumMasters that serve Distributed Teams need all the support we can give them.

The Death Star was an Agile Project

2011-03-22T17:24:47Z

Shared by Ken
Note the comments to this post :-)

A few ideas… great and small.

Comic for March 11, 2011

2011-03-11T06:00:00Z

Kanban, System Archetypes and Limits to Success

2011-03-08T15:53:49Z

In a previous post I introduced the idea that Kanban can play a role in Systems Thinking and understanding System Archetypes. In this post I’ll describe system archetypes in some more detail, and describe the Limits to Success archetype.

Balancing Feedback

Balancing feedback will stabilise a system’s behaviour. For example a thermostat is a balancing feedback system where the temperature is measured, the difference from the desired temperature measured, and a heating or cooling device adjustment made accordingly. This can be depicted as below, with the B identifying the loop as balancing. When the temperature is higher than the target, then the adjustment is to generate cold air. When the temperature is lower than the target then the adjustment is to generate hot air.

Reinforcing Feedback

Reinforcing feedback will amplify a system’s behaviour. For example a bank account is a reinforcing feedback system where you have an account balance, onto which an interest rate is applied, and as a result you have interest paid to increase the balance (assuming your bank pays you interest). This can be depicted as below, with the R identifying the loop as balancing. As the cycle continues, more and more interest is paid, continually increasing your account balance. Conversely, when you have a negative account balance, your bank might apply a charge, which is deducted from your balance (much more likely). This cycle will continue as your account goes into increasing debt.

Delays

What makes systems complex is that there are often delays in the feedback loops. Delays separate cause and effect over time which often leads to instability and oscillation. For example, how many times have you been in the shower and tried to adjust the temperature, only to find the water suddenly get too hot or cold? This is due to a delay in the action of adjusting the temperature, and the temperature actually changing. As a result we tend to over-adjust and get burnt or chilled.

Archetypes

Most systems are not as simple as these examples, and consist of combinations of balancing and reinforcing feedback loops with different delays. However, a system’s particular structure will result in its behaviour being constant over time, and systems with similar combinations result in similar behaviours. These patterns which cause similar and recognisable system behaviour are known as system archetypes.

Being able to recognise system archetypes helps to identify the cause of behaviours, and gives insight into how to break (or encourage) the archetype to our advantage. Let’s take a look at an example.

Limits to Success

The Limits to Success archetype can be depicted as below.

To improve performance of a system, more efforts are made, which do lead to the anticipated improvements, creating a reinforcing loop. However, after some time the performance reaches a limit and resistance creates a balancing loop, leading to the performance levelling off, declining or even crashing.

Recognising this archetype leads to the understanding that when the systems resists, or pushes back on attempts at improvement, then rather than continuing to push the reinforcing loop, and increase efforts or do the same thing better, we should look to remove the limits by adjusting the system design to delaying the balancing loop. In other words, deal with the limits before the system does. The system’s limits will result in a worse outcome.

A Kanban System can help to cope with Limits to Success in a couple of ways. Firstly, setting explicit Work in Process limits is a way of directly limiting the system before the system does so itself, avoiding the decline or crash in performance. Secondly, gaining transparency of the work and the workflow is a beginning to learning what the cause of the limiting factor is. Visualising any bottlenecks or impediments gives a good indication of where to start looking to make changes in the system design.

A tale of two PMOs | TechRepublic

2011-02-15T14:18:47Z

The actual benefits and most effective way to setup your PMO are difficult to identify. Patrick Gray looks at two different PMOs–one an administ

LeanEssays: Before There Was Management

2011-02-08T20:06:56Z

Presentation:Raising the Bar: Super Optimizing Your Agile Implementation Using Kanban and Lean

2010-11-23T15:29:00Z

Jesper Boeg and Guilherme Silveira discuss various Agile anti-patterns which proved not to work for everybody, presenting some Lean principles implemented with Kanban and helping to improve things, resolving possible conflicts with traditional Agile practices, and determining if Lean&Kanban is appropriate for immature teams. By Jesper Boeg and Guilherme Silveira

Presentation:Continuous Delivery

2010-12-23T12:00:00Z

Jez Humble talks on the importance of Continuous Delivery for a business, outlining the foundational principles and practices to be implemented for a successful CD, explaining how to do continuous integration, various ways of testing, canary releasing, and migrating data. By Jez Humble

How to evaluate and implement startup ideas using Hypothesis Driven Development

2011-01-11T23:07:25Z

Comments

Fact and folklore in software engineering

2011-01-06T16:11:01Z

TDD Problems

2010-12-23T22:06:10Z

Comments

Kanban and Systems Thinking

2010-12-22T16:23:58Z

Systems Thinking

The original Agile methods were created by teams independently in response to the challenge of improving software development and their documentation as a named process was a subsequent codification in order to help spread the learning and improvement wider throughout the industry. Either consciously or intuitively, these processes were applications of Systems Thinking, taking a holistic approach to solve the problem at hand. Taken in this context we can learn from Agile methods by treating them as system archetypes rather than repeatable solutions, and design our own systems to create the same results.

System Structure

Systems Thinking suggests that systems are made up of elements, which interact, to meet a purpose. In other words, they are more than the sum of the parts.

A system’s purpose is what ultimately determines its behaviour. In fact a system’s purpose can be often deduced from its behaviour which is observed over time rather than through individual events. A generic purpose for product development might be to deliver value through achieving flow and building capability.
A system’s elements are the things that it is made up of and these can be either tangible or intangible. Tangible elements of a product development system could include the people, physical resources (e.g. hardware and furniture) and artefacts (e.g. specifications and tests). Intangible elements could include the software itself (both product and tests), software tools (e.g. compilers and editors), skills and morale.
A system’s interactions are the relationships that hold its elements together. They can typically be a flow of energy, material or information. For product development systems, the most relevant interactions often take the form of information flows. This might be information about learning (e.g. success or failure), state changes (e.g. ready or done) or decisions (e.g. accepted or rejected).

System Archetypes

A system can also be described in terms of stocks and flows. A stock is a recognisable and measurable part of the system, and the flows are what cause the stock to rise and fall over time. Thus, the stock at any given time is the result of the all the preceding flows in and out of the system. The stock acts as a buffer for the flows, which can create stability and allow for variability by decoupling the flows. However, it can also cause delays which may cause instability. In a product development system, if we think of the stock as the Work in Process (WIP), we can see that some WIP will create stability, but too much will create undesirable delays.

Describing systems in terms of stocks and flows leads to the understanding of feedback in systems. Feedback is created when changes in a stock affect the flows into or out of that same stock. Feedback can either balance and stabilise, or reinforce and amplify a system’s behaviour and combinations of feedback structures result in a system’s behaviour being constant over time. The patterns which cause similar and recognisable system behaviour are known as system archetypes.

Kanban Systems

These basic Systems Thinking concepts give us a clue to how we can help meet the challenges of improving our product development practices without codifying methods. Having clarity of purpose, and the way elements interact to achieve that purpose, can give us insight into intervention points for continuously improving.

System archetypes give us a further perspective with which to view our product development processes, and suggests the role Kanban plays. If Agile processes are examples of a system archetype, then Kanban provides an approach to creating further examples of those system archetypes. Workflow can be thought of as part of the system structure. Visualisation can highlight key elements and interactions. Limiting WIP can manage the stock. Cadence can co-ordinate of elements and interactions. Learning can focus on improving the system. Further, where processes are exhibiting less desirable archetypes, then Kanban provides an approach to recognise, visualise and eventually break them.

It should be remembered though that systems area non-linear in that there not a simple cause and effect relationship. That is why behaviour should be measured over time rather than looking at individual events. As Donella H. Meadows so eloquently put it in her book ‘Thinking in Systems: A Primer’, “The future can’t be predicted, but it can be envisioned and brought lovingly into being” and “We can’t control systems or figure them out. But we can dance with them!”

Company Practice: Mini-conference

2010-12-22T22:06:26Z

Our company is quite small (25 people). Most companies of this size focus on rapid growth and don’t pay much attention to learning. We are different. Fortunately, learning is very important in our company. We boost it in all possible ways:

We highly encourage people to try and learn new things.
Every employee can dedicate up to 12% of their time to unstructured learning (5 hrs per week).
We organize internal trainings twice per months.
We organize so-called Friday Shows every other Friday where we watch and discuss some interesting videos about UX, development, business, etc.

About a month ago we decided to structure our trainings in a better way. The resulting idea was internal mini-conference. Mini-conference is a full-day event dedicated to sessions and discussions. All sessions are prepared internally. The idea is to have a very focused learning event instead of several trainings over 2 months.

Our first conference will take place this Friday. Here is the program

10:00 Registration, “wake-up” coffee
10:15 Data Visualization Alex Tsayun /45 min
11:00 coffee break /15 min.
11:15 Node.js intro Vadim Gaidukevich /30 min
11:45 MongoDB (NoSQL) intro Oleg Seriaga /30min
12:15 coffee break
12:30 Exploring Good Experience Seth Godin (guest video) /20min
13:00 History of Kanban Anton Marchenko /30 min
13:30 lunch
14:30 Performance Metrics Alex Fomin /1h
15:30 coffee break
16:00 Marketing and Sales @ TargetProcess Andrey Mihailenko /1h
17:00 free discussions.

I am really curious about the outcome. Wil people like it? Will we keep this practice? Not sure. But we are trying new things :)

Doc On Dev: The Three "R"s of Clean Code

2010-12-02T22:18:05Z

Show HN: A/Bingo for ASP.NET

2010-11-05T14:55:03Z

Comments

7 A/B Testing Resources for Startups and Solo Developers

2010-11-05T14:53:56Z

Comments

How to Bootstrap a Lean Startup

2010-11-03T03:46:48Z

Comments

How to Identify a Programmer's Personality by Just Watching Their Keyboard Moves

2010-11-01T19:39:40Z

Comments