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.

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

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)