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)

A Model for Creating a Kanban System

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

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

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

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

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

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

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

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

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

A Root Cause Analysis of Agile Practices

At Agile2010 I was chatting with George Dinwiddie about general process related stuff (probably with some reference to Kanban!) and I mentioned an idea I had submitted to a couple of conferences which had never got accepted. George suggested we try it as a Open Jam session, so we did!

The idea is to run a root cause analysis of various agile practices to drill down into why they work and what the benefits to be realised are. So rather than using a 5 whys approach to solve problems, it is used to understand solutions. For example, why do unit test? To minimise defects? Why do we want to minimise defects? To create less rework? Why do we want less rework? etc. The session tied in nicely with another Open Jam run by David Hussman on Dude’s Law, which also emphasised focusing on why rather than how.

Here are the outputs from the 3 practices we picked; Unit Testing, Iterations (Time Boxes) and Limiting WIP. Click to view the album with bigger pictures.

As a general exercise, I found it really useful and interesting. Definitely something to try submitting to future conferences again. The discussion and debate we had, and the surprising tangents we went on, was rewarding and enlightening. I was particularly fascinated by the comparison between Time Boxing and Limiting WIP and the way that creativity came out in both of them through different paths. I hope that by understanding why practice work in more detail, we can avoid following them dogmatically, and be in a better position to solve problems based on context. When a particular practice is not suitable we can draw on other practices which can provide the same benefits.

This is definitely something I want to explore further – hopefully with workshops at future conferences. If you try it out as well, blog your outputs and let me know!

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

Exploring the Kanban Multiverse at Agile2010

I ran a workshop on “Exploring the Kanban Universe” at Agile2010 with Xavier Quesada Allue. The premise was to setup an example case study and lead participants through visualising different aspects of a project – the different multiverses – over a number of iterations.  Below are pictures of the final boards from the different teams. We encouraged people to think ‘outside the box’ and try and move away from traditional rows and columns approaches.

The highlight for me was the circular design that one of the teams came up with. I thought it was a great solution to the challenge of avoiding kanban boards appearing to show a linear process. With a circular design, a work item can loop round the circle multiple times, with the distance from the centre indicating closeness to completion, and different quadrants indicating the primary focus of work such as analysis, dev, test etc. This was the nicest example of a board as a ‘map’ as opposed to a ‘relational’ representation.

One thing that was reinforced for me was that a Kanban Board should not try to visualise absolutely everything. Its should have just enough information to signal where the issues are, and where the team should look to find out more. In other words it should be able to “point to the gemba”. Thanks to Harada Kiro to reminding me of this after the session. In future runs of the workshop we’d like to try starting with a blank canvas each iteration to avoid teams feeling constrained by trying to show too much and having to build upon previous designs.

I also gave a talk on the subject at the Lean & Kanban Conference in Belgium last week after which Mary Poppendieck pointed out that I’d slipped into referring to some visual management designs as kanban boards when they strictly weren’t because they didn’t limit WIP. Visual Management is a large part of a Kanban System, but not every Visual Management board is a Kanban board.

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

LESS2010 – Don’t Miss Out

I’ve spent the last few days busy on final preparations for the LESS2010 – the International Conference on Lean Software and Systems, which is being held in partnership with the LeanSSC.

Tickets for LESS2010 are selling well, but we’d really like it to be a sell out. If you’re not already coming, please take a look, sign up and bring your friends and colleagues!

The website is http://less2010.leanssc.org/ and the full program and details are now available at http://less2010.leanssc.org/program/. There is also an executive day if you know anyone who you think would be interested in that. http://less2010.leanssc.org/program/executives/. If you book a group of 5 or more, we can also offer a discounted rate – let me know if you’re interested in that option.

We have a couple of flyers for helping with promotion:

If I were to pick 3 main reasons for attending the conference, they would be:

  • The Beyond Budgeting track and links with that community
  • The Academic content and links with that community
  • The great line-up of speakers 🙂

I hope I see you there!

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