Karl Scotland – Using Agile to Deliver Value
Archive for March, 2011
Agile Israel and LSSC11 Conferences
Mar 11th
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.
Kanban, System Archetypes and Limits to Success
Mar 8th
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.
Cargo Cult Kanban
Mar 7th
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.
