Agile Israel and LSSC11 Conferences

Some info about a couple of conferences coming up I’m particularly looking forward to. At both, I’m going to be talking about Visualising System Archetypes, which will build upon my recent posts about Systems Thinking and Systems Archetypes to explore how visualisation patterns can show, understand and deal with different patterns of system behaviour. Here’s the abstract:

Many organisational challenges are a result of systemic issues, where cause and effect are not directly connected, but are separated by time and involve feedback loops and delays. Given that Kanban is a method for designing a software and systems development system, and systems thinking includes the idea of system archetypes which describe common patterns of behaviour, we can use system archetypes to guide our visualisations and help us identify opportunities for improvement. This session will introduce how to understand system archetypes, describe a number of common and relevant archetypes, and discuss patterns which can visualise and thus help break those archetypes.

Agile Israel

As the adoption of Agile concepts becomes more and more mainstream, it’s time to climb to the next level!

Agile Israel 2011 is your chance to hear about next level ideas and practices such as Agile Testing, Kanban, Lean Product Management, Agile Project Management, Scaling Agile into the Enterprise level, Metrics and Dashboards, and more, and to meet practitioners from the Israeli Agile community and learn from experience reports and experts.

Agile Israel 2011 is the 4th annual Agile event in Israel, starting at 2008, and as always will include the presence of prominent speakers alongside experts from Israel and case studies from Israeli companies (view photos and lectures from Agile Israel 2010).

This year Henrik Kniberg will be the keynote speaker. Among the other international lecturers and guests will be Jurgen Appelo, Hillel Glazer, and the ScrumAlliance MD Donna Farmer.

The event will take place on April 11th 2011 and Avenue congress centre near Tel Aviv.

Register today http://agileisrael2011-ral.eventbrite.com. An early bird of 20% is currently available until March 15, and I have 5 speaker discount codes giving 5%. Ask me for details.

LSSC11

This year’s Lean Software and Systems Consortium conference (Long Beach, California, May 3-6) is bigger with many more tracks and world-class speakers. In addition, the Software Engineering Institute (SEI) is part of the conference cooperation with the Lean Software and Systems Consortium.

This year’s theme is the synthesis of other models, going beyond lean: LSSC11 will show how vertical markets are embracing lean, how it is applied in large-scale initiatives, and how it is succeeding around the world. 

Anyone considering lean methods like Kanban will want to be at LSSC11 to build on their knowledge and connect with like-minded business people.  Companies represented include Lonely Planet, Goodyear Tires, JP Morgan Chase, Hewlett Packard, Deloitte, GoDaddy, Microsoft and many other organizations worldwide that are actively using lean software and systems thinking to succeed.

Do not miss the excitement, the learning, the networking, and the once-in-a-lifetime moments at LSSC11. Enjoy extended early bird pricing until midnight on March 13, 2011. Ask me about speaker discount codes as well for further discount. Register today at http://lssc11.leanssc.org.

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

Kanban, System Archetypes and Limits to Success

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.

image

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.

image

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.

image

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.

image

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.

image

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.

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

Cargo Cult Kanban

A couple of weeks ago I got involved in another conversation about the appropriateness of the software development community’s use of the name Kanban. This comes up every now and again, and I usually sympathise and try and talk more about the higher level system, as in the Toyota Production System. This time, however, I had a different thought. While Taiichi Ohno did call the TPS’s central tool Kanban, he was also against codifying methods, so why do we insist that the name Kanban has to refer to a copy (or codification) of what Ohno’s TPS Kanban looked like?

The Agile Community has referred to Cargo Cult Agile for some time, and it seems that there are increasing occurrences of Cargo Cult Kanban. The term Cargo Cult is used to describe the copying of practices to achieve a goal, without understanding those practices. From the Wikipedia page:

Cargo cult activity in the Pacific region increased significantly during and immediately after World War II, when the residents of these regions observed the Japanese and American combatants bringing in large amounts of material. When the war ended, the military bases closed and the flow of goods and materials ceased. In an attempt to attract further deliveries of goods, followers of the cults engaged in ritualistic practices such as building crude imitation landing strips, aircraft and radio equipment, and mimicking the behaviour that they had observed of the military personnel operating them.

Cargo Cult Kanban is the copying of another Kanban System without understanding why it is designed the way it is, and its appropriateness for another context. This applies whether the Kanban System you are copying was designed by Taiichi Ohno, David Anderson or Arlo Belshee. Taiichi Ohno’s TPS Kanban System was a solution in Toyota’s context. However, its the thinking behind the tool that was more significant, and I’d like to think that he would appreciate the software development community’s use of the name Kanban to describe its systems thinking approach to evolutionary change.

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

Lean & Kanban: Learning Through Systems Thinking at QCon London

I’ve just been updating my calendar and downloads pages, which have been sadly neglected recently, and thought it would be worth mentioning one particular event I’m involved with coming up.

I’m was really pleased to be asked to host a Lean & Kanban track on Thursday March 10 at QCon London, and have used the opportunity to (selfishly) create a track of talks I really want to see around ideas related Systems Thinking and Learning. I am increasingly finding these ideas core to the way that I talk about Kanban Systems.

The track abstract is:

Lean and Kanban: Learning Through Systems Thinking
It is often said that the heart of Lean is about thinking for yourself in your context. Kanban provides a model for thinking about process within a context and Systems Thinking provides a focus on purpose and outcomes within a context. Together, they enable knowledge acquisition and learning about value creation. The talks in this track will explore these various topics and show how to use the ideas and approaches to create evolutionary, continuous and sustainable improvement.

As well as giving a talk on Kanban System Design, I’m really grateful to be able to have the following line-up:

  • Katherine Kirk – When the pressure is really on: A “rough and ready” application of Lean and Kanban at the BBC

How a small IPTV team at BBC iPlayer used Lean principles and elements of Kanban for their rapid and successful response to a fast paced, very demanding live release schedule for the v2 device customisation programme.

  • Benjamin Mitchell – Can the Kanban Method avoid becoming another Management Fad

The Kanban Method has been shown to provide efficiency gains in many organisations. However, this talk will argue that those improvements have generally come through doing things righter, rather than doing the right thing. Doing more of the right thing requires challenging and testing underlying assumptions about the design and management of work, which will often lead to situations of embarrassment or threat. For the Kanban Method’s approach to evolutionary increment change to become more than a fad, it needs to either provide guidance or advice about how to overcome issues that generate embarrassment or threat, or provide a more balanced view of it’s potential impact. The talk will cover approaches that could increase the chances that the Kanban Method could deal with questioning assumptions around issues that could create defensiveness.

  • Jurgen Appelo – Complexity vs. Lean: The Big Showdown

Agile software development is (in part) based on the idea that software teams are complex adaptive systems. And Lean software development is (in part) based on systems thinking. Many Agile and Lean experts have borrowed terms from complexity theory (like “self organization” and “emergence”). But what is the difference between complexity theory and systems thinking? And how does complexity thinking compare to Lean software development? Are they different, or aligned? Can we use one to better understand the other?

  • Jeff Patton – Using design thinking to stop building worthless software

Delivering software fast isn’t the same as delivering value fast. The value we’ll get from that software is generally assumed. The real risks are almost always unknown. It’s because every piece of software we design and build is unique. It’s not designed then mass-produced like a car or piece furniture. Lean thinking and tactics that focus on speeding re-production of the same thing over and over doesn’t easily apply to the design and invention of new software. It takes design thinking. In this talk, Jeff describes the simple concepts that characterize design thinking: clear problem definition, ideation, iteration, and execution plans that emphasize continuous learning. You’ll learn how integrating these concepts into a design and delivery process shortens the cycle time from opportunity identification to acquiring real benefit from the use of the software. Jeff will give specific examples of the practices used by today’s successful software design and development companies that effectively integrate design thinking into their development approach. You’ll leave with a toolbox of simple proven practices you can add to your current process to improve the rate you deliver benefit from software.

I’m really looking forward to this. If you’d like to come along, the sooner you register the cheaper it is, and if you use the promotion code SCOT100 you can save a further £100 and a donation of £100 will be made to Crisis.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Agile Thinking

Over the last few years I’ve been looking to ideas outside the traditional software development community to help me understand and improve the way I work and help teams. I’ve realised that there’s something in common with nearly all of them; Lean Thinking, Systems Thinking, Complexity Thinking and in just the last few weeks I’ve come across an increasing number of references to Design Thinking. Did you spot the commonality? They are all regularly referred to as Thinking concepts. And then there’s Agile, with its silent Thinking. I’m pretty sure that anyone recognised as knowing anything about Agile will say that Thinking is a core part. A quick Google search with show that. But we don’t often say it explicitly and instead usually talk about doing Agile, being Agile or having Agility.

As we approach the 10th anniversary of the community adopting the term Agile, my contribution to the retrospection on what we have learnt is to propose we remove the silencer from the work Thinking. Lets talk about using Agile Thinking alongside Lean Thinking, System Thinking, Complexity Thinking, Design Thinking and  the rest.

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

Kanban and Systems Thinking

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!”

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

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.

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

Kanban System Design Article

I’ve just had an article published on Agile Journal about Kanban System Design in which I look at Kanban from a Systems Thinking perspective, and how various aspects of Kanban can provide leverage points to improve our product development outcomes.

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

Lean Software & Systems Conference CfP & Registration Open

The Lean Software and Systems Consortium US-based community conference will be May 3-6 next year, in Long Beach California. The Call for Papers and Registration are now open. The CfP Deadline is Dec 19th and will not be extended.

May 3rd is LeanSSC Technical Advisory Board meeting and pre-conference tutorials. If you intend to attend those you should plan on arriving in Long Beach on May 2nd. The full conference starts on May 4th.

The Lean Software and Systems Conference is the Kanban conference for North and South America in 2011. This is where the community gathers and is where you will get the first chance to see and hear the best new material.

We will also be awarding the Brickell Key Award for outstanding achievement, leadership and community contribution for the 2nd year. A Call for Nominations will be made within the next week. Please consider who you’d like to nominate for the award. Last year’s worthy winners were David Joyce and Alisson Vale. This year they, together with David Anderson, Alan Shalloway, Donald Reinertsen and I, make up the selection committee. The Award banquet will be held on Thursday May 5th in Long Beach. Be sure to select the banquet as part of your registration if you would like to be part of ceremony and festivities.

Volcanoes and other natural disasters or Black Swans permitting, I hope to see you there.

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

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!
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)