CfP: LESS2010 – International Conference on Lean Enterprise Software and Systems

This is a belated announcement about LESS2010, whose Call for Papers for LESS2010 closes tomorrow – June 15th.

LESS2010 is the International Conference on Lean Enterprise Software and Systems, in collaboration with the Lean Software and Systems Consortium (LeanSSC), to be held October 17-20, Helsinki, Finland. CfP details can be found at http://less2010.leanssc.org/call_for_papers/ with submission details at http://less2010.leanssc.org/submit/.

Note that we have clarified the submission requirements. The instructions should be used as a guide. However, content is more important than style initially, so submit whatever is best to give us a good idea of your proposal. Any accepted submissions will need to eventually be expanded and conform to Springer’s LNBIP format for publication.

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

LeanSSC 2010 UK

The Icelandic Volcano Ash Cloud meant that non of the European Speakers could present at the LeanSSC Atlanta 2010 conference. Additionally, many attendees were unable to make the event. As a result, we have put togther this small mini-conference to allow the speakers to share there ideas and experiences, and ensure that the time and effort put in to prepare is not wasted!

We have chosen to collaborate with the UK Agile Coaches Gathering, are are hosting the event at Bletchley park immediately before that get together, so that anyone wanting to attend both can hopefully save on travel and accomodation.

The following speakers are confirmed:

  • Karl Scotland – A Kanban Universe
  • Simon Baker & Gus Power – Product Development in the Land of the Free
  • Liz Keogh – BDD: A Lean Toolkit
  • Benjamin Mitchell – Using Kanban to Get Knowledge and Continuously Improve
  • Mattias Skarin – Converting A Scrum Team to Kanban

Because this is a free event, with limited places, please only sign up if you are genuinely intending to come!

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

A Kanban Multiverse – not from LeanSSC Atlanta

I should have been at the LeanSSC Conference in Atlanta this week, but unfortunately Eyjafjallajokull intervened. This is the Prezi I was going to use. It may not make much sense on its own but hopefully gives a flavour of what sort of things I was going to talk about. I’m hoping to put together a post together to flesh out the details.
Update: I posted a write-up on the Management 3.0 site
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Defining the Last Responsible Moment

I was involved in a recent twitter discussion with Chris Matts about Lean’s “Last Responsible Moment”, and he set a challenge to come up with a usable definition. Chris’s opinion is that there isn’t one, compared to the Real Options equivalent. This then, is my response to that challenge.

I will define the Last Responsible Moment (LRM) in terms of Cost of Delay, as used by Don Reinertsen, and Benefit of Delay, a related term that came up in an email conversation with Julian Everett. In short, the Last Responsible Moment is just before the Cost of Delay outweighs the Benefit of Delay. Its not necessary to be able to quantify the costs and benefits very accurately because any evaluation is going to be better than none!

In his challenge, Chris used the example of knowing the Last Responsible moment to submit a session for Agile2010. I’ll use that example to explain my definition.

Firstly, the Cost of Delay for submitting to Agile2010 goes up at the submission deadline, because when you can no longer submit, can can no longer get accepted, and thus can no longer receive speaker benefits including conference registration, complimentary hotel nights. However, that does not make the submission deadline the LRM, because there is no benefit in delaying submission due to the open commenting and review process. Thus the LRM is actually as soon as the submission system opens. From then on, submitters are losing the opportunity to improve their submission.

What would happen if the Agile2010 submission process wasn’t as open or iterative? In that case, then there would be benefit in delaying, because it would allow more time to refine a submission before entering it. The Benefit of Delay would drop off just before the deadline, however, so the LRM would be then.

A third scenario, as suggested by Chris, is that a speaker might have something so important and valuable to say, that the Benefit of Delay doesn’t actually drop off at the submission deadline. There may be a Benefit right up to the conference itself because a speaker can turn up with a Soap Box, or propose a session for Open Space. The Cost of Delay remains the same, due to the loss of speaker compensation, but the Benefit might always outweighs the Cost.

Finally, in this scenario, a speaker might choose to register for the conference early anyway to take advantage of any early bird deals, and book flights and hotels early to get good prices. This would reduce the Cost of Delay, and thus potentially reduce the Benefit needed to make it worthwhile not requiring an official speaking slot on the program.

To summarise, understanding both the Cost of Delay and Benefit of Delay can be a practical way of defining the Last Responsible Moment. Real Options thinking provides ways of influencing the Costs and Benefits of Delays to gain some flexibility.

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

Facilitating A Kanban Konversation

As I mentioned in my Scrum Gathering Musings, I came up with a twist on the Goldfish Bowl format which I used during the Kanban Exploration Deep Dive.  Here are some more details.

The Goldfish Bowl format works really well for facilitating a focussed discussion with a large number of people. It keeps the active voices to a manageable number, while being open for anyone to join in if they have something to add. Apart from providing a solution to my challenge – keeping a spirited debate under control – it also seemed appropriate that the limited number of chairs provided a means of limiting “Voices In Conversation”.

However, there was one thing about the Goldfish Bowl which didn’t seem appropriate. With a Goldfish Bowl, when someone wants to join the discussion, they fill an empty chair as part of the conversation, and force someone to leave to free up a seat again. That seemed to be like “pushing” in to the discussion. What it no-one wants to leave? So instead, I moved the empty chair out of the discussion, and made it a Queue. If someone had something to contribute, they could fill the “Waiting to Talk” seat, which would be a signal to the “In Conversation” people that one of them should leave when ready. I was pleased to find that this change worked really well. Rather than the discussions being interrupted when people moved around as they figured out who would leave, the conversations flowed smoothly as people moved in and out naturally. Initially the “Waiting” person had to wait some time, but once we got used to the system, this seemed to be less of a problem.

These are the instructions I used:
  • 4 “In Conversation” seats and 1 “Waiting to Talk” seat
  • Only “In Conversation” people may speak
  • If you want to join the conversation, fill the “Waiting to Talk” seat (if it’s empty)
  • When someone “In Conversation” leaves, that is a signal to move from “Waiting to Talk” to be “In Conversation”

I wondered whether we would evolve the system, by increasing or decreasing the number of seats in each state, but that didn’t happen. Its something I’ll look out for in the future. I’d also love to hear if anyone uses this format, or has already done something similar.

VN:F [1.9.22_1171]
Rating: 4.8/5 (4 votes cast)

Did I Mention The LeanSSC?

I’ve just posted an entry on the LeanSSC blog, introducing myself, and talking about my involvement with the group. Its the first of what I hope will be a series of posts introducing a number of the founder members of the Lean Software & Systems Consortium. The goal is to create some more visibility and transparency of who the LeanSSC is and what we are trying to achieve. In addition we have created a public Yahoo! Group where we hope that we can more openly discuss the ideas advocated by the LeanSSC.

While I’m talking about the LeanSSC, I should highlight that if you’re thinking of going to the Atlanta conference and haven’t booked yet, the price gores up again in April. Book now while you can at $995. And if you’re not thinking of going, why not?!? The program looks excellent, and having just begun piecing together my talk, I’m really looking forward to it. I’ll be bringing together some ideas on visual management kanban board techniques which I’m calling the Kanban Multiverse.

An added benefit of coming to t he conference is that the Technical Advisory Board is also meeting at the same venue on April 20th (Tuesday) and is open to all conference attendees. To attend all you need to do is to show up a day earlier, and to register for the conference and collect your badge on Tuesday. The registration desk volunteers will direct you to the room for the TAB meeting.

I hope to see you there!

http://atlanta2010.leanssc.org/
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

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.

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

Systems Thinking, The Vanguard Method and Software Development

I’ve recently read John Seddon’s “Freedom from Command and Control“, which introduces his approach to Systems Thinking – the Vanguard Method. A few key points really struck home with me and helped clarify my thoughts on some of the challenges I’ve come across recently.

First is the following simple diagram, which shows that Management is responsible for defining the System, which is ultimately what defines Performance. Management’s role should be to analyse Performance, and change the System to improve it.

Agile initiatives are usually begun in order to improve performance. Seddon says that in order to analyse Performance, we first need to understand the Purpose of the System. Then we should create Measures to provide knowledge of how well we are meeting that Purpose, before finally applying a Method which meets that Purpose, using the Measures to help refine the Method.

Finally, Seddon says that understanding Purpose involves understanding Demand, and in particular, Seddon introduces the concepts of Value Demand and Failure Demand. Value Demand is what do our customers ask us to do because it add value, and Failure Demand is what our customers ask us to do because we failed to something, or do something right in the first place.

I’m increasingly aware of Lean and Agile methods being used for the sake of it. While Scrum, XP and Kanban will generally serve common software delivery Purposes, such as delivering real benefits and in short timescales, using them without recognising the Purpose will often result in no real improvement in Performance. Lean and Agile methods are often used just as alternative delivery approaches within an existing System, rather than as means to change the System itself. These organisations can be thought of as “wall-dwellers”, using a method within existing boundaries, rather than “wall-movers”, moving the boundaries to help create a System which helps meet the Purpose. To quote (or paraphrase) Russell Ackoff, this is “doing the wrong thing righter, rather than doing the right thing”.

Do you know what the Purpose of your software development process is? Do you have Measures about capability against that Purpose? Do you know what your Value and Failure Demand is?

VN:F [1.9.22_1171]
Rating: 3.6/5 (12 votes cast)

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)