LeanSSC Atlanta 2010 and other Conferences

I’ve just updated my Calendar page with where I’m speaking this year so far (or hoping to), and thought it would be worth adding some more details in a post.

Atlanta 2010 SpeakerThe conference I’m most looking forward to is the inaugural LeanSSC Conference in Atlanta in April (21-23) which is the place to find out about “the next wave of process innovation”: Lean, Pull Systems and Kanban.

If you are interested in applying Lean concepts to software and systems development then this is the conference to attend. It will have the best people in Lean and Kanban, and the best and largest quantity of Lean content. A significant number of the speakers are not part of the regular Agile community so this is your chance to see them. Here’s some other reasons why you might want to go:

  • Learn lean development approaches with a focus on scientific, model based solutions.
  • See how to tailor lean methods to your unique work situation.
  • Find proven approaches that let development and management work together on a system design level.
  • Get pragmatic, actionable advice, delivered by people with field experience presenting metrics and data.

I’ll be giving a new talk on “A Kanban Multiverse”. Here’s the abstract:

Wikipedia defines a Multiverse as the hypothetical set of multiple possible universes that together comprise everything that physically exists: the entirety of space and time, all forms of matter, energy and momentum, and the physical laws and constants that govern them. A Kanban Multiverse can be defined as the hypothetical set of multiple possible Kanban Boards that together comprise everything that physically could be visualised: the entirety of scope and time, all forms of work type, status and flow, and the organisational laws and constants that govern them. This talk will explore how a single Kanban Board might visualise these multiple aspects in a limited and constrained space.

The other exciting conference for me is going to be the Scrum Gathering in Orlando next month (match 8-10). I’m really honoured to have invited to run a deep dive workshop on Kanban. Its going to be structured round what I refer to as the Five Primary Practices (see here and here), with exercises and discussion to explore how Kanban Systems are compatible with Scrum.

The other two confirmed conferences are ACCU 2010 and SPA 2010 where I’ll be talking about Five Steps to Kanban and running a Kanban Game respectively.

Finally, its the Agile2010 submission process at the moment. I have two submissions in, and am a panel member on a third. If you have a user account (why wouldn’t you? :)) please give them feedback to help them get accepted!

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

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.

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

Process Safeguards and Ski Slopes

black ski slope One of the joys of working as a coach for EMC Consulting are the regular opportunities to have deep conversations on various topics with my colleagues when we are in the office together. For example, earlier this week myself and Simon Bennett began to discuss way of talking to our clients about process such that we can guide them towards the most appropriate choice. However much we may have our preferred approaches, they may not always be the best solution in any context. In the course of the conversation we compared various styles including waterfall, scrum and kanban, and looked at them on various scales, including risk, reward and control. None of these seemed satisfying as a language to use, until Simon suggested safety.

Different processes have different levels of safeguards built into them. Safeguards are used by processes to compensate for low skill, low maturity or low trust, but they also reduce speed or reward. With a waterfall process, the heavy up-front documentation is a safeguard to compensate for low trust (and often low skill and maturity). When a customer does not want to collaborate, then waterfall provides safeguards aimed at avoiding them rejecting the final delivery (not that those safeguards always work!). At the other end of the spectrum, extremely productive teams often have very few safeguards because of the high trust, collaboration and capability. Those safeguards that are in place (such as automated tests) are very different. Not having safeguards doesn’t make the process dangerous. It means that team doesn’t need them. So when we talk to customers about process, we can talk about the appropriate safeguards needed for the amount of trust that exists, the capability of the team, the desired delivery speed etc.

While exploring this idea, I became aware that at various points I was referring to kanban at different places on the safeguard continuum. At the high safeguard end was a kanban based process that looked like waterfall, but was limiting WIP and reducing queue and batch sizes. At the low safeguard end was a kanban process with extremely low WIP, no estimation and pure pull. That’s quite a wide range of processes. Similarly, we had Scrum down as a range on the continuum. Towards the high safeguard end, Scrum-but changes Scrum to add safety. Towards the low safeguard end, a highly productive Scrum team will just be using the raw essence of Scrum. Even at this end, however, the Sprint boundary in Scrum could be seen as a safeguard. It’s the opportunity to pause and reset if things are going awry.

In trying to articulate the different types of kanban system in terms of safety, I gave a nod to XP and labelled low-safety kanban “Extreme Kanban”, and high-safety kanban “Safe Kanban”. Not entirely happy with this we bounced some more ideas around and came to the Ski Slope metaphor. “Extreme Kanban” became “Black Kanban” and “Safe Kanban” became “Blue Kanban”. A further iteration led us to “Off Piste Kanban” and “Nursery Kanban”. The ski slope metaphor works quite well at a number of levels. Its a nice way of looking and risk and reward. As a beginner at skiing I don’t want to take much risk, but can get some reward on the nursery slopes. As my capability improves, and as I trust my ability (and instructor) more, I’m prepared to go onto more difficult runs and take more risk to get more reward. Nursery slope groups are generally more controlled, staying in a single file group. As capabilities improve, individuals are given more freedom to try things out for themselves. If I were ever to become an expert, I’d be happy to go off piste to get a high reward. Additionally, when I get to a level where I go off piste, I probably don’t need an instructor anymore, but I may need a guide.

Using the ski slope metaphor allows us to decide what level of process to start a new team with based on how good they currently are. We may want to stretch them a bit, but we may not want them to go straight onto a black run process. We also want the team to be able to move up to more challenging but rewarding levels as they improve. This is one of the reasons I prefer a kanban based approach. I believe it allows teams to start with an safer process to begin with and move to more rewarding processes later by removing or changing safeguards, as opposed to pushing teams straight into a process with less safety before they are ready.

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

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.

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

Kanban Trail Markers

When talking about Kanban Systems for Software Development, I always try to emphasis that the Kanban System is more than the tool, and is a System that should be owned by the team, rather than being imposed upon it. By owning it, and being part of creating it, a team are more likely to evolve the system as part of continuous improvement. Recently, I tried a new analogy to make this point, and while its not perfect, I think its good enough to blog about for further feedback.

The Primary Practices of Kanban that I describe, are not Boolean practices that teams either do or don’t use. Rather they are practices that teams should be constantly revisiting, and re-implementing, as they improve and their context changes. To recap, the primary practices I talk about are:

  • Map the Value Stream
  • Visualise the Value Stream
  • Limit Work in Progress
  • Establish a Cadence
  • Reduce the Kanban Tokens

I currently describing these practices as like trail markers on the team’s journey of process improvement. At any point in time, the team’s Value Stream, Visualisation, WIP Limits, and Cadence identify where the team currently is, and when combined with Kanban Reduction, point the way forward. As when on a hike, only the group knows where it is, and only the group can decide where it should be going. The hiking group must work together, helping each other out and making sure that everyone reaches the destination. If you’ve read Eli Goldratt’s “The Goal” you’ll recognise the comparison to the one he uses.

Trail Marker

Where the analogy breaks down is that a team’s trail markers are only ever unique to that team. They cannot be followed by other teams. Instead, they will only show the journey the team has been on in their quest for success.

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

Lean Software & Systems Conference 2010 Atlanta

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>

Atlanta 2010 Attendee

Source: <a href=”http://atlanta2010.leanssc.org/”><img alt=”Atlanta 2010 Speaker” src=”http://www.agilemanagement.net/lssc10/Atlanta2010Speaker.png” border=”0? /></a>

Atlanta 2010 Speaker

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

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

Skills Matter Lean and Kanban Exchange

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.

Lean Kanban Exchange

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

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.

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

New and (Hopefully) Improved AvailAgility

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!

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

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…

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