AvailAgility
Karl Scotland – Using Agile to Deliver Value
Lean Software & Systems Conference 2010 Atlanta
Nov 16th
The first Lean Software & Systems Conference will be held in Atlanta, Georgia, USA between April 21st and 23rd 2010.
Registration and the Call for Papers is now open at atlanta2010.leanssc.org
The first 50 registrants enjoy a super early discount rate of $800 plus entry to the exclusive speaker luncheon and a special limited edition Ltd WIP Society t-shirt, sponsored by David J. Anderson & Associates.
The Call for papers closes on December 14th.
Use the Twitter search tag #lssc10 to filter tweets about the event. Follow @lssc10 on Twitter for news from the organizing team.
If you are speaking or attending the conference you might like to tell people about it by adding these buttons to your web site design. If you want to use these assets on your site just paste the HTML code provided straight into your web source code or content management system.
Source: <a href=”http://atlanta2010.leanssc.org/”><img alt=”Atlanta 2010 Attendee” src=”http://www.agilemanagement.net/lssc10/Atlanta2010Attendee.png” border=”0? /></a>
Source: <a href=”http://atlanta2010.leanssc.org/”><img alt=”Atlanta 2010 Speaker” src=”http://www.agilemanagement.net/lssc10/Atlanta2010Speaker.png” border=”0? /></a>
Conference Chair: David J. Anderson
Track Chairs: Alan Shalloway, Joshua Kerievsky, James Sutton, Eric Willeke, Chris Shinkle, Richard Turner & David Anderson
Event Planner: Kelly Wilson
Organizing Sponsor: Software Engineering Professionals (SEP)
Event Team: Dennis Stevens, Janice Linden-Reed, Aaron Sanders, Eric Landes
Sponsorship opportunities email info@leanssc.org
Skills Matter Lean and Kanban Exchange
Nov 13th
I’m going to be speaking as part of the Skills Matter Lean and Kanban Exchange on December 1st. From their website:
The aim of the Lean & Kanban eXchange is to promote awareness and adoption of Lean and Kanban ideas and techniques. With David J. Anderson providing the conference keynote and two Parkbench sessions, the programme is structured to encourage discussion and bring together the leading thinkers and passionate members of the UK Agile, Lean & Kanban community. With a maximum number of 125 delegates, we aim to provide an informal and intimate environment where you can share experience, demonstrate new ideas and techniques, talk to the experts and generally have lots of fun.
There are still a few places left. If you’re in or around London, I’ll hopefully see you there.
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.
New and (Hopefully) Improved AvailAgility
Oct 28th
After over a year of blogging, I finally decided that it was time to move off wordpress.com and invest in an independently hosted version that gave me some more flexibility. So today I bit the bullet and grabbed availagility.co.uk (availagility.wordpress.com is being redirected, so all the old links should work). If you see anything which looks odd, or find any links which don’t work, please let me know.
I should also give credit to Just Host, who provided a seamless process for setting everything up, including a very quick and helpful response to a support request when figuring out how to get the redirects working.
Update: One of the downsides to moving the blog that I lost all of the article ratings. Feel free to go through and re-rate any entries you feel deserve it!
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?
5 Steps to Kanban in Cambridge
Oct 12th
I’ll be talking about 5 Steps to Kanban at Software East on November 19th. From the website:
This event will take place at Red Gate Software, Newnham House, Cambridge Business Park. See the location map for Red Gate Software.
BOOK NOW for this event. Tickets (including light buffet) £15 if booked on or before 16th November, £25 thereafter. Places strictly limited.
Evolving a Workflow
Oct 9th
Mary Poppendieck gave a talk on Workflow is Orthogonal to Schedule at Agile2009, during which she very neatly transitioned a schedule-focused view of work, into a flow-focussed view. At least I thought it was neat, so I’m going to try and reproduce the basic elements here, using my favourite agile workflow.
4 Week Time-box Schedule
Here we have a schedule showing an average of 4 features being delivered every 4 week time-box. Each time-box is preceded by 2 weeks understanding the next features, and a release is made every 8 weeks. Its not a bad schedule. There’s a regular release every two months which is better than a lot of projects, but it could be better.
2 Week Time-box Schedule
Now we reduced the time-box to 2 weeks, meaning that we do an average of 2 features in each time-box. This means that the preparation now takes only 1 week. Additionally, we are now releasing at the end of every time-box, which is also reduced to 1 week. Much better.
One Piece Flow
If we continue the evolution we end up working on a single feature at a time and releasing it immediately. Each feature only takes a week to build, and preparation and release times are now down to 1/2 a week. At this point, we don’t really have a schedule anymore, but a natural workflow.
Cumulative Flow Diagrams
One of the things that strikes me about the diagrams above, is that each step in the evolution transforms them more into a smooth Cumulative Flow Diagram. In fact, in the same presentation, Mary showed the following picture taken from Building the Empire State. This is the building schedule from from around 1930, and itself looks remarkably like a CFD. Another example of how we are not inventing anything new, but can learn from other industries and successes.
#lkuk09 – A Tweetrospective
Oct 6th
I ended up making notes at the Lean & Kanban UK Conference with good old fashioned pen an paper. Rather than try and write up those notes into something coherent and meaningful, I have decided to write them up in the style of a twitter stream. These are the things I would have tweeted if I’d been on my laptop. The quantity of “tweets” in no way represents the quality of the presentations. I also make no promises that all of the following “tweets” are actually <= 140 chars!
Monday
Mary Poppendieck – The The Tyranny of the Plan
- Plans – what did construction do before computers?
- Eliminate design loops by consulting experts early
- Design for decoupling workflow
- Cash Flow Thinking – Cost of Delay
- Design based on constraints of situation
- Establish a reliable workflow 1st
- Schedule is orthogonal to workflow
- Build schedules based on experience, not wishful thinking
- Variance from plan is a learning opportunity, not a performance failure
- Reliable workflow – output, pathway, connection, method, improvement – Steven Spears, Chasing the Rabbit
- Polaris Success – Quality of Leadership, Focus on deployment, Decentralised Competitive Org, Emphasis on Reliability, Esprit de Corps
Alan Shalloway – Creating a Model to Understand Product (and Software) Development
- 3 types of value: Discover what a customer needs, Discover how to build it, Build it
Jeff Patton – Lean Product Discovery
- There is a difference between Delivery & Discovery
- Undelivered software is a solution hypothesis (usually incorrect)
- Include discovery in the VSM
- Market demand = pull (but is post delivery)
- “Lets go to marble”
- Discovery Kanban + Delivery Kanban
- Visualisation creates collaboration
- Storyotype 1: Bare Necessity – minimally demo-able
- Storyotype 2: Capability + Flexibility – options-
- Storyotype 3: Safety – invisible
- Storyotype 4: Usability, Appeal, Performance – differentiating
- Chess analogy – Opening Game, Mid Game, End Game
- Use options when cost of iteration and failure is high
John Seddon – Re-thinking Lean Service
- If you manage costs, costs go up
- Failure demand is a signal
- Incentivising workers get less work done
- Predictable failure demand is preventable
- Lean is getting a bad brand
- The only plan is to get knowledge
- Improve flow – walk the flow
- Pull the help, keep the work
- Do “productivity” tools improve productivity?
- Make them curious
Tuesday
Don Reinertsen – Second Generation Lean Product Development: From Cargo Cult to Science
- Understand causal relationships and salient phenomena
- Scientific v Faith (Science Free) based approaches
- Faith based = Cargo Cult
- Every system has Push / Pull interfaces
- No bad tools, only wrong times to use them
- In Product Development, Requirements are a degree of freedom
- Inventory is information and invisible (physically and financially)
- Agile practitioners are going a better job at LPD than LM practitioners
- In engineering we are making economical (Profit + Loss) decisions and we have no clue what we are doing
- Quality = Process x People – If either drops to 0, the quality of the result will drop to 0
- Don’t tolerate initiative – demand it
- Chief Engineer doesn’t know better than the customer
Kenji Hiranabe – Learning Kaizen from Toyota
- Balance process control and process improvement
- Management fosters human potential
- Go to the gemba != PowerPoint
- To know and to understand are different
- Think within your constraint
Hal Macomber – Lessons from Target Value Design
- Meld planning with execution + control
- What signals do we pay attention to?
- Articulate + activate the network of commitment
- Only start work when it is in the condition to be finished.
- Embrace the contradictions of Lean
- Focus on tool users, not the tools
- PDSA – Study, don’t Check
- Creating constraints creates innovations
- Create constraints so that we can do our work
- Don’t open the trenches until you know you can fill them
Marc Baker – Lean Thinking: what is distinctive about it and where it is going?
- Pull means take the payment first
- Visual controls mean that nothing is hidden
- Standardised tasks are the foundation of employee autonomy
- Go see, ask why, show respect
XP As A Kanban System
Sep 25th
During recent discussions with XP folks on the topic of Kanban, it occurred to me that based on my understanding, XP can be described in terms of a Kanban System for Software Development. This is an attempt to do that, on the basis that it might be useful in helping teams understand Kanban concepts. I have structured the description around the five primary practices of Kanban that I have previously blogged about.
1. Mapping the Value Stream
Here’s an example of an XP Value stream
- A customer comes to the team with a problem they want solving, and collaboratively they write a set of User Stories
- The team then holds an Iteration Planning meeting to prioritise which User Stories they believe they can deliver within the next iteration (which is 2 weeks in this example)
- The team then pick the first of those User Stories, and plans how they will build it.
- They build a User Story (using good engineering practices)
- When the team has something to show, they review progress with the customer. In this case, every 2 days on average. I assume that the team will be collaborating with the customer more often than that, but am not showing that level of feedback for simplicity. Reviewing a User Story may result in re-planning and re-building (iterating). Completing a User Story will trigger another User Story being planned and built.
- At the end of the Iteration, the customer accepts all the completed User Stories. At this point the User Stories are re-prioritised again and another set chosen for the next Iteration.
- At the end of the Iteration, the software may also be released, and more User Stories may be written.
In practice, the workflow is not this precise, but I think its a close enough approximation. For example, new User Stories could be written at any point.
2. Visualising the Value Stream
An XP teams may use a very simple visualisation such as the one above, which focuses on the Plan-Build-Review section of the Value Stream. The User Stories (yellow) chosen for an Iteration are initially not started. When they are planned, then tasks (grey) are added, and the tasks are working on until they are all done, and the User Story is Done.
3. Limiting Work in Progress
An XP team will limit work in progress by working in pairs, with each pair only working on a single User Story at a time until it is Done. Thus in the above example, a team of four developers limits work in progress to two User Stories by two pairs.
4. Establishing a Cadence
XP teams have a very specific and synchronised cadence which is created by time-boxing the Iteration. Prioritisation, Reviews, Retrospection and Releases all occur at the same time interval, and User Stories are planned to be completed within that time interval.
5. Reducing the Kanban Tokens
An XP team is always striving to improve, usually by using retrospectives. As such, in the above example, they may reach a point where all four developers are able to work on the same User Story, and as a result complete it sooner.
Assuming that this description of an XP based Kanban System is not widely off the mark, I hope that it serves to communicate that XP and Kanban are not alternatives, but different and compatible ways of describing a process. Further, I have found that by understanding a process in terms of a Kanban System, it has helped my think about alternative ways of evolving that process in order to improve it. There is of course, more to XP than I have mentioned here, such as release planning, and the usual good engineering practices.
