AvailAgility
Karl Scotland – Using Agile to Deliver Value
Agile
Scrum Anti-Pattern: NOT Prioritising Stories Within Sprints
Jan 20th
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
Dec 22nd
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.
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.
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.
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.
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.
Incremental
The purely incremental approach builds each feature, across all components, to full fidelity, one by one.
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.
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.
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
Nov 5th
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
- Decide and agree on an Outcome, in terms of working software
- 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
Oct 21st
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)
Now I just need to find a good label to stick on it…
Is Kanban A Relabeling of Scrum?
Oct 20th
Firstly, this post is not an attempt to be divisive or competitive. Instead it is meant to be exploratory. What would it mean for the statement in the title to be true? Actually, the full statement was “People have so misunderstood Scrum, that they’ve reinvented it and called it Kanban”. It was made by Jim Coplien at Scan-Agile, after (but not necessarily the result of) a conversation over dinner where myself and a few others were describing how we used Kanban. Each time we described different aspects of our processes, Jim would say something along the lines of “but I do that with Scrum”.
So what would it mean for people to have so misunderstood Scrum that they have reinvented it and called it Kanban?
- It might mean that at their heart, Scrum and Kanban have the same intent. That both are really focussed on helping teams think about their processes in order to help them succeed.
- It might mean that the way that Scrum was originally articulated (and is still articulated according to the latest Scrum Guide) was not as clear as it could have been. That teams might misconstrue the focus on roles, meetings, artefacts and rules.
- It might mean that there are alternative ways of articulating the same intent. That teams might find alternative articulations valuable.
- It might mean that Kanban can be equally misunderstood. That teams might be bewildered by a less prescriptive approach.
- It might mean that we should spend more time on understanding how to help teams solve their problems and less time arguing and fighting over preferred solutions.
These are just some of my thoughts. They do not mean that I think Scrum is bad – just not perfect. They do not mean that I think Kanban is perfect – although it’s currently my first language. The topic drew a good crowd at the Scan-Agile Open Space and we had a good discussion. What else might it mean?
Balanced Software Development
Sep 16th
Agile2009 provided me with 3 sources of ideas which all complemented each other, and which I think make an important point that I want to repeat.
Firstly, on the flight over, I read John Shook’s blog post about his work with Starbucks. In it, he responds to the suggestion that by advising Starbucks on using Lean methods, he is transforming them into a robotic fast food joint like McDonalds. That suggestion sounds similarly like the common claim that Kanban transforms software development back into a robotic process. The piece that stood out for me was this:
Toyota combined old IE Scientific Management principles and techniques with social dimensions appropriate for the modern world. Even workers who do “manual labor” with their hands are knowledge workers. Front-line employees become the scientists.
By redefining roles, Toyota changed the answer to the question of who is the scientist in scientific management.
In other words, Scientific Management is still relevant for knowledge work, when the workers are the scientists. That keeps the balance between the Process and the People.
Secondly, Alistair Cockburn talked about three pillars of Effective Software Development in the 21st Century in his Agile2009 keynote. The 3 pillars are:
- Cooperative Game
- Craft
- Lean Processes
Again, this to me demonstrated the need for a balance between the People and Process focussed elements.
Finally, I attended Jon Dahl’s talk on Aristotle and the Art of Software Development. This focussed on the differing ethical philosophies of Kant, and Mill and Aristotle:
- Kant looked at the Acts, known as Deontology. This can be equated to looking at Process.
- Mill looked at the Effect, known as Utilitarianism. This can be equated to looking at Outcome.
- Aristotle looked a the Actor, known as Virtue. This can be equated to looking at the Participant.
Chatting with Matt Wynne after the talk, we both had the same thought. While individuals will probably sway to one form of these philosophies, there is room for all of them, and again, a balance is good. I would even go so far as mapping the three philosophies on to Alistair’s three pillars.
- Deontology is Lean Processes
- Utilitarianism is Craft
- Virtue is the Cooperative Game
In many of the recent discussion I have seen and been involved in on Lean and Agile, and Kanban in particular, it seems to me that most of the debate is because the various participants are talking from the perspective of one of these pillars or philosophies. We should remember that they are all important, and that achieving the right balance is what is going to help us be successful in delivering valuable software.
Reflections on #Agile2009
Aug 31st
I’m just about recovered from Agile 2009, and about to disappear off the grid for a much needed break in the sun. Before I do so, I wanted to jot down my immediate reflections on the conference while they were still fresh.
The conversations in between sessions are always great at the Agile conferences, but this year, I think these conversations were the main highlights for me. I met lots of new people who I’d only previously known online, as well as re-acquainting myself with people who I usually only see once a year. My top 3 highlights were:
- Discussing team maturity and explicit and implicit Kanban WIP limits with Alistair Cockburn.
- Splitting hairs on the finer points of Lean (Kanban) and Theory of Constraints (Drum Buffer Rope) with Mike Cottmeyer (apparently it was a highlight for Mike as well)
- Debating all sorts of ideas around Kanban with Arlo Belshee and Bonnie Aumann – including drawing on beer mats and using beer glasses and other implements to aid visual representation.
As far as scheduled sessions went, Mary Poppendieck gave a good talk on Workflow and Scheduling in which she nicely transitioned from a time-boxed schedule to a kanban work-flow using a form of cumulative flow diagram. Jon Dahl also gave a thought provoking talk on Aristotle and the Art of Software Development, which for me tied in nicely with Alistair Cockburn’s keynote, and some other thoughts I’ve recently had. I’m planning on blogging more on both these topics more when I get back off holiday. See you then…
What is Cadence?
Jul 21st
Mark Stringer gave me some good feedback recently, that I clearly hadn’t described what I meant be Cadence at the recent miniSPA conference. In order to try and correct that, I thought I’d try and clarify with a blog post that it not simply variable length iterations.
The purpose of a cadence is to establish a reliable and dependable capability which demonstrates a predictable capacity. Cadence gives some confidence in the upcoming work when we are triggering rather than scheduling work.
Time-boxing is one specialised form of cadence. It’s like a metronome, giving a single tick. All the main process events are based around this single tick, as shown below where the dotted vertical lines represent the Sprint boundaries. In this example, the unit of work is a User Story, and User Stories should be small enough to be scheduled into a Sprint, and subsequently completed in the same Sprint. Stories in Progress are limited to two, as a good Scrum team might, but Stories don’t always fit exactly into a Sprint. Note also, that while releases can happen each Sprint, User Stories are only potentially shippable product increments.
Kanban on the other hand has a cadence which is more like a drummer. The rhythm is more complex than the single tick of a metronome, and can be more varied, as shown below. In this example, the unit of work is a Minimal Marketable Feature, which while needing to be as small as possible, is not constrained be being required to fit into a schedule. Instead, an MMF is able to flow over a number of process events while it delivers some releasable value. Planning, reviewing, retrospection and releasing all still happen regularly, but they are de-coupled. They can happen independently, at differing rates, which may provide more freedom in creating a natural process which enables the team.
A cadence is usually ‘harmonic’, in that there is a neat overlap between the different rhythms, as in this example. However, it does not have to be. A look at some definitions of cadence can show why. These are some favourites I picked off dictionary.com
- In music, the ending of a phrase, perceived as a rhythmic or melodic articulation or a harmonic change or all of these; in a larger sense, a cadence may be a demarcation of a half-phrase, of a section of music, or of an entire movement
- Music. A progression of chords moving to a harmonic close, point of rest, or sense of resolution.
- The flow or rhythm of events, esp. the pattern in which something is experienced: the frenetic cadence of modern life.
Thus cadence is what gives a team a feeling of demarcation, progression, resolution or flow. A pattern which allows the team to know what they are doing and when it will be done. For very small, or mature teams, this cadence could by complex, arrhythmic or syncopated. However, it is enough to allow a team to make reliable commitments because recognising their cadence allows them to understand their capability or capacity.
Kanban, Flow and Cadence News
Jul 16th
I did a re-run of Kanban. Flow and Cadence at miniSPA yesterday after being selected as one of the best sessions from the main SPA conference this year. I’ve just uploaded the slides on my downloads page. I had some good and appreciative feedback, and Mark Stringer has bee good enough to post some of his thoughts. I’m always glad to get this sort of feedback as it helps me understand how well I am explaining myself, and improve future presentations.
I have also recently agreed to do session at Skills Matter in London on the evening of July 30th – please sign up. This is the start of what I hope to be series of events jointly organised by Skills Matter and the London branch of the Limited WIP Society. While most of the ideas I will talk about remain the same, I am going to spruce up the slides and base them on the talk I gave in Zurich. The original version of Kanban, Flow and Cadence is nearly a year old now, and is refusing to die, so I’m keen to bring in some of my latest thinking.
Kanban Is My First Language
Jul 10th
I was chatting with Benjamin Mitchell recently on the way back from the recent Skillsmatter event at the BBC and said something along the lines of, “I think in terms of Kanban, even when I teach Scrum”. I’ve been mulling over that idea more recently and decided that its a good analogy. Kanban and Scrum are just like different languages.
Different languages can all express the same ideas, but each has its own strength and weaknesses which can give a different interpretation. Its also important that when you speak in a language, that the listener speaks the same language. Conversations between two people who speak different languages can be very painful, and often confusing! It is possible to aid communicate by using multiple languages, however, swapping occasional words or phrases when necessary. Similarly, different methods or processes can all be expressing the same ideas slightly differently, which can cause confusion or help communication of those ideas.
I’m not multi-lingual (in the literal sense), but I can imagine that being able to speak more than one language gives a good insight into how languages work, as well as making learning further new languages easier. Knowing the various grammar rules and other such things that I don’t understand is probably very useful in being a better communicator. Similarly, understanding different methods or processes can give us deeper insight into how and why they work, and help us improve further.
However, when I try to speak in another language, I always think in English. I imagine that’s common and that it’s rare even for skilled multi-linguists to switch the language they think in. So using the language analogy, I currently think about software development in the language of Kanban. Its my first language.
