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.

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.

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

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.

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!

Scrum Gathering Musings

I came away from the Scrum Gathering last week feeling surprisingly positive about the future of the Scrum Alliance. All in all it was a very enjoyable conference, and my overall impression was of a community which is more open and inclusive than I have perceived it to be for a long time. Talking to Tobias Mayer at the end he put it quite nicely – the Scrum Alliance is about transforming the world of work, and not about defining Scrum.

My Kanban Deep Dive seemed to be well received. I had a great group who were very engaged and willing to enter into the spirit of lively debate, including Jean Tabaka, Lasse Koskela and Jurgen Appelo. My goal was not to “teach” Kanban, but to explore some of the key elements, and how they compare to Scrum. After some inspection and adaptation, the discussions centred around “how will these ideas change the way I work?” It was interesting to hear some diverse opinions and discover how people would take away what we covered. I also came up with a new format inspired by Kanban – the Kanban Konversation – a pull-based variation of the Goldfish Bowl. I’ve blog about this separately.

Other sessions I went to included a couple on Lean Thinking and Scrum, including a great summary of Statistical Control Charts by Mark Strange – something I never thought I would see discussed openly within the Scrum Community! Mike Cottmeyer also hosted a useful OpenSpace session on Scaling Agile in which we explored his ideas about using a Kanban approach to co-ordinate Agile Enterprises.

The OpenSpace itself was hosted by Harrison Owen, creator of the format, and it was insightful to hear him talk about its origins, and how he typically uses it. I liked the more fluid way of creating the market place. Proposers were limited to stating the problem they wanted to discuss, and their name – no rambling descriptions or explanations. The market place itself was had no explicit schedule – proposers just added a post-it with a time and location to their problem. The schedule seemed to self-organise into more of a structure later on. One thought I had was that OpenSpace as used by the Agile community may itself be overkill for how we use it. I’ve never been to an Agile OpenSpace in which we needed to solve a specific problem by yesterday. Rather they are forum for open conversations on a variety of topics relevant to the conference and community. Much like the conversations I generally find mysefl involved in over a beer (or Mohito this time) in the evening. I wonder what would happen if we simple hired a bar for a couple of evening and people came along for a drink and a chat? Oh wait, that’s XTC!

To sum up my thoughts after the Scrum Gathering, it seems to me that the Scrum Community is now seeing itself as part of the picture, and not he whole picture, which can only be a good thing.

Scrum Anti-Pattern: NOT Prioritising Stories Within Sprints

Craig Dickson has published an article on Agile DZone claiming that prioritising Stories with a Sprint is an anti-pattern. He blogged this in December last year, when I noticed it and grumbled on twitter, but no more. Now that its re-appeared on DZone I feel compelled to say something, and that it warrants a blog post of my own rather than a comment.

Craig says that a Scrum team commits to a “set of Stories by the end of the Sprint” (his emphasis), and that prioritising within the Sprint means that the “commitment evaporates”. That sounds to me like committing to, and delivering, a batch of Stories. I’m sure notable Scrum luminaries have assured me that the Sprint is not a batch. Craig even suggests the Scrum diagrams should represent the Sprint Backlog as “one single large block of work”. What about flow? What about limiting work in progress to improve flow? If shorter Sprints are good because it encourages prioritisation and limits work in progress, why not prioritise work and limit work in progress with the Sprint?

Craig goes on to suggest that rather than prioritising a Story within a Sprint so that it can “meet a business need”, the PO should “reach out and educate the necessary stake holders about the Scrum process”. This sounds to me like Craig is recommending that Scrum dictates how the organisation is run, and that this is more important than meeting a business need. I prefer my processes to support and enable organisations to meet their business needs. Scrum should be a means to an end, not an end in itself. My view of Agile is that is about being responsive to business needs, not forcing organisations to wait until a convenient date. A cadence should be useful, but not a restriction.

Similarly, Craig says that prioritising Stories within Sprints is bad if it creates “implementation dependencies between Stories”. I prefer to think that a Product Owner should be able to ask for, and have delivered, increments/iterations in whatever order creates the most value, and not be constrained in this way by process policies about how Stories should be written. Worse still is the suggestion that any dependant Stories should be scheduled into separate Sprints. How is that being responsive to business needs and encouraging flow?

Finally, I think that Craig is missing a trick. In the same way that short Sprints focus a team’s technical and creative capabilities to figure out how to get to DONE in a short time-box, so too will prioritising Stories within a Sprint focus a team to stretch their skills even further. A team that can deliver and release a single Story every day or so is surely in a better position that one which can only deliver a batch of Stories every week or so.

Craig concludes by observing that “There is nothing in the Scrum process that talks about Story priorities within a single Sprint.” Correct. But that doesn’t make it an anti-pattern, in the same way that TDD is not a Scrum anti-pattern because Scrum says nothing about TDD. Rather, I’d say that NOT prioritising stories within Sprints is the anti-pattern.

Fidelity – The Lost Dimension of the Iron Triangle

One the topics that I find a lot of people find particularly interesting and useful is that of Fidelity in software. This generally comes up while I’m talking about incrementing and iterating, and the difference between the two. I’ve already touched on this when discussed whether a Kanban System eschews iteration. This post will build on that, and describe what I mean by Fidelity.

The Iron Triangle of Project Management is a well known concept. There are a number of basic variables to project delivery; scope, cost and time. Not all these variable can be fixed, and generally quality is in the middle as another non negotiable variable.

Triangle

This can be related to a typical Agile Burndown, in that the Horizontal Axis is Time, the Vertical Axis is Scope, and the burndown slope is a function of cost and time. Keith Braithwaite and Joseph Pelrine both blogged about this after a conversation we had in Zurich earlier this year. I like to add a 3rd variable into that function that determines the slope – fidelity.

Burndown

Fidelity is similar to concepts I picked up from a number of places. One is Dimensional Planning where a number of different solutions are planned, each with a different level usability. A Dirt Road solution is the most basic, a Cobble Road solution is intermediate, and a Tarmac Road solution is the best.

Dimensional

Another source is Jeff Patton’s work, and in particular his approach to grading features. Similar to school or college work, each feature can be graded from A to F, where A is the best solution, and F is the least acceptable. Understanding how our customers perceive features in these terms, along with what the minimum acceptable grade is, helps with knowing when to continue working (and maybe come back later) or when to stop and move onto another feature. My colleague Simon Bennett refers to this a Balanced Scorecard technique.

Grades

So fidelity refers to the finesse of the feature, or solution. A low fidelity solution will be low in things like precision, granularity, or usability, but will still solve the original problem. As fidelity increases, so does the precision, granularity, usability etc. I prefer to make a distinction between fidelity and quality to avoid getting into discussions about compromising on quality. One recent project I was involved with talked about fidelity in terms of Rich, Richer and Richest.

Fidelity, as I have described above, can be useful when understanding the difference between incrementing and iterating, and how they can be effectively combined. We can consider 4 distinct approaches; Big Bang, Incremental, Iterative and Agile.

Big Bang

A Big Bang approach is neither iterative or incremental. Architectural components are built to full fidelity, for the full scope, and are fully integrated once at the end.

Big Bang 1

Big Bang 2

Big Bang 3

Incremental

The purely incremental approach builds each feature, across all components, to full fidelity, one by one.

Incremental 1

Incremental 2

Incremental 3

Incremental 4

Iterative

The purely iterative approach builds all the features, across all components, to the lowest fidelity, and then increases the fidelity to the highest level.

Iterative 1

Iterative 2

Iterative 3

Agile

An Agile approach combines the incremental and iterative approach by building each feature, one by one, at a low fidelity, and then both gradually adding features and increasing their fidelity until the right combination is achieved. Full fidelity is not always necessary.

Agile 1

Agile 2

Agile 3

Agile 4

Agile 5

Agile 6

It is by adding the Fidelity dimension into the mix that Agile projects can achieve the flexibility required to deal with typical scenarios where scope, cost and time become fixed, without resorting to cutting on quality. Fidelity provides a mechanism to effectively vary scope, while still meeting all the customers needs and solving their problems.

Outcomes and Sync Steps

I met up with Jean Tabaka last week for a coffee and we chatted over various things, including Lean, Kanban, “The Don”, Tufte, and Systems Thinking. One of the other areas was around the origins and original intents of Scrum. Jean mentioned an early paper(*) by Jeff Sutherland, written before the current terminology became standard, where he described his process in a very simple way

  1. Decide and agree on an Outcome, in terms of working software
  2. Use daily Sync Steps to decide how to best achieve the outcome

Since we had that discussion (which also touched on GTD), I have found that this a great a way of describing the essence of Agility. Inevitably it has also triggered thoughts on ways of comparing and contrasting Kanban with more traditional Agile methods such as Scrum.

In a Scrum based approach, the Outcome is defined by the Sprint Goal, with the Sprint Plan being a means of making a commitment to the Outcome. There is a single Outcome, which is constrained by the length of the Sprint. The Sync Steps are provided by the Daily Stand Up Meeting.

In a Kanban based approach, the Outcomes are the limited work items in the system. There can me multiple Outcomes in progress at a time, but the WIP limits constrain the Outcomes. Planning, and as a result any commitment (or SLA) on the Outcomes is done per Outcome, and Just In Time. The Sync Steps are usually provided by the same Daily Stand Up Meeting, but could also be formed by other forms of Cadence.

So both Scrum and Kanban focus on team Outcomes, with regular Sync Steps to achieve the Outcomes. The way in which those Outcomes and Sync Steps are managed are different.

(*) Unfortunately, I don’t have a reference to this paper. If you recognise it, please let me know!

Update: Jeff actually calls them SynchSteps. References can be found in this 2001 paper, and in early emails. He also refers to Outcomes as Mutations.

A New Lean And Agile Picture

David Harvey posted a brilliant piece on his blog entitled “The Scrum Picture is Wrong”. I highly recommend reading it. His ideas and suggestions for an alternative Scrum picture got me thinking about how to visualise Lean and Agile software development in a process or label agnostic way. David’s picture looked like a figure of eight, and there seemed to be 2 inputs (a vision and reality), and 2 outputs (the product and the team). A quick google found me what I was looking for here – a figure of eight with a bar across the top and bottom. “A time sign that according to Diderot’s Encyclopedia meant hour for the chemists in eighteenth century France”. That seems quite appropriate. An hour would be quite a good interval for a feedback loop 🙂

This is what I came up with. A vision and reality come together to produce a product and a team through process and improvement (and process improvement)

Process Picture

Now I just need to find a good label to stick on it…