I just finished leading an in-house Scrum Product Owner course with a group of 6 actual or future product owners. One of their most pressing issues was what to do when the team does not meet its commitment. "My Team regularly commits to 20 points, then only delivers 10. What can I do?"

We briefly discussed the alternatives of shooting, firing or otherwise punishing team members for not meeting their commitment, but quickly came to the realization that such measures are likely to be counterproductive. If the team fears the consequences of not meeting a commitment, it will be very cautious about making those commitments.

Here are eight strategies for achieving the sprint goal:

1. Yesterday's Weather

If the team finished three backlog items ("stories") for a total of 10 points in the last sprint, then that is a good place to start for the next sprint. As a product owner, only accept a commitment to 10 points. As a team, only offer to take on 10 points. If the team runs out of work, it can always go back to the product owner and ask for more.

2. Smaller Stories

The larger the backlog item, the higher the complexity and the higher the risk. By breaking the story down into smaller stories, you decrease the risk of each individual story. If 3 of 6 stories go South, the Team has a problem, if the team does not succeed on 3 of 20, it's not such a big deal.

Current recommendations suggest that a team should commit to 10 to 20 stories per sprint. For two week sprint with 6 people on the team, that means each story (backlog entry) will need, on the average, about 3 to 6 Person-days to complete.

Reminder: each story must meet the INVEST criteria and have an acceptance test associated with it.

3. Prioritize large stories higher

Even if you are aggressively breaking down stories, some will be bigger than others. It's dangerous to have big, low priority items. When the team starts the story, the sprint should be nearing its end, so the story may not fit. Get the big ones out of the way first, then do the smaller ones.

4. Defend against Scope Creep

A common problem in the sprint is discovering "new" requirements during the course of the sprint. (Product owner says, "check our requirements document, chapter 4.1.3 for the details." Chapter 4.1.3 is where the skeletons are hiding. No-one has really studied the implications of 4.1.3 and it will surely have surprises which cause the effort to rise.

I have found the following strategy to be useful: The story has precedence over the requirements doc. It represents the instructions for this sprint, which is should create a small piece of the entire product. If I stumble on a requirement which is not clearly part of the story, I report that to the product owner, who then decides what to do with the "new" requirement (in backlog or not, prioritized high or low), and I continue to implement the story as previously agreed.

How do you identify what is in the story and what not? Two components define the story: 1) its title 2) how do demonstrate it to the Product Owner at the end of the sprint. If the functionality in question is needed to make the title happen and is visible in the 'how to demo' workflow, then it is part of the story, otherwise not.

Even if title is not a correctly formatted user story, the story should be a complete sentence. For example:

• Good: As a job hunter, I want to send my resume with my job application so that....
• OK: Send resume with job application.
• Much room for improvement: Attach resume.

The second component is "how to demo." This is a simple work-flow which the team will use to demonstrate the story and that they have met the requirements on the story, for instance: 1) chose a want-ad, 2) select "Apply," 3) select "Attach resume," 4), pick file from dialog 5) upload, 6) Send. At there very latest, Team and product Owner should agree on this work-flow during the Sprint Planning.

So the team is working on this story, reads chapter 4.1.3, and discovers 'E-Mails should be signed with PGP to assure authenticity." Sounds like a great, trust building requirement. Is it part of this story? No! There is nothing about digital signing, neither in the title nor in the 'how to demo'. Report this to the PO who can create and prioritize a new story, if appropriate.

5. Strict Prioritization

The backlog items are prioritized in the Product Backlog. This prioritization is carried over into the sprint backlog. A simple approach is to consider the top story 'Must have' and everything else 'Nice to have' until the top story is finished. The team members should always focus on getting the top story finished before looking at issues further down the priority list.

6. Early Acceptance

There is no rule which says the Product Owner must wait until the Sprint Review before definitively accepting a story. If the story is done after three days, then ask the product owner to accept it right away. This smooths out his workload and reduces the uncertainty on how many stories have been accepted.

7. Swarming / Pairing

Consider a team with 4 people, 4 stories each estimated at 10 days each, a 2 week sprint (10 working days), and in which each team member takes on 1 story and works on it large by himself. On the 9th day, each story is 90% done.

How many stories will be done at the end of the sprint? Hard to say. Getting stories done usually means coordinating with other people: a code review, an independent test, acceptance by the Product Owner. This can become a tremendous bottleneck and it is possible that no stories get finished, even if the work on each really was 90% done. The situation gets worse if the stories were underestimated. They don't need 10 days to finish, but 13. At the end of the sprint, nothing is finished and the burn-down chart remains unchanged.

Let us assume that this team applied Strict Prioritization and the entire team worked on one story at a time and that this did not affect the working time needed to complete the story. The first story would finish after 3 days, the second after 6, the third after 9 days. At the end of the sprint, the team has taken 30 points off the backlog. Not the 40 they had hoped, but better than the zero achieved with everybody working on their own story.

Can a team -- and in particular your team -- really apply swarming? Only one way to find out: Try it on a story or two and see how it works. More widely practiced is pairing, in which two team members work on a story together. This is almost always useful, because it stimulates knowledge sharing and prevents becoming too dependent on a single team member.

8. Throttling

The Product Owner cannot and should not tell the team to pair or swarm. But the P-O can still influence this process. Let us assume the team has 6 members. If the product owner only asks for 3 stories (sized according to the guidelines above), then the team is forced to ask themselves, 'How can we work together to solve this problem?'

I recommend this approach to teams that are just getting started, in combination with a few weeks of one week sprints. This helps them learn to do Scrum quickly and to work as a team effectively.

These strategies have worked for me. What other strategies do you use to help your team achieve its commitment at the end of each sprint?

I have been following an interesting discussion on scrumdevelopment looking for case studies on Productivity improvements and ROI from Scrum. Roy Morien wrote:
"What I am always puzzled about is that in the history of software development, during which the Waterfall type approaches have been taken as THE way to develop systems, I have seen little, if any, real evidence of the effectiveness and efficiency of using them. I have also seen little demand for such evidence. The industry has adopted these approaches, and that's that! What I have seen is a vast amount of evidence that these approaches do NOT ensure successful outcomes." Why was the waterfall adopted without appropriate rigor? Very simple, you don't need a statistic or a study to understand something that you already know!

This may be a surprise to some people, but waterfall was a substantial improvement compared to its predecessor - which I'll call 'unstructured chaos' for lack of a better term. Waterfall imposes constraints on the development process, so it can proceed effectively. Waterfall says:

1. Figure out the business requirements first
2. Don't change your requirements while you are implementing
3. Test your code to ensure that it works

I have met a number of large companies for whom imposing this basic discipline was a tremendous improvement over unstructured chaos. So when a CTO is hesitant to give up his waterfall, it's because s/he remembers (and probably paid for) the bad old days.

Waterfall fails because these constraints are impossible to uphold over the length of an entire project. 

Scrum and XP impose these constraints at the sprint level, and introduce an additional constraint: the time-box. Seen from this perspective, Agile is surprisingly similar to waterfall!

By processing small batches and producing "finished" functionality, the performance, reliability and predictability of the system improves dramatically (the Poppendiecks taught us that).

Iteration also introduces the opportunity for frequent reflection, which turbo-charges the improvement process. Agile groups can get much better very quickly and fruits of their labor are more closely aligned with customer needs. Regular reflection also has the side effect of making work much more fun.

So let us not condemn the waterfall. It has served us well. It was developed by real people in response to real problems, who did the best they could with the knowledge that was available to them at the time. We can do better now. So a moment of silence, and let's get started with the next sprint.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. This is one of the 12 Principles of the Agile M Agile Manifesto. A recurring theme in many Scrum discussion groups is that virtual meetings and web based tools are a poor substitute for a physical task boards.

Hans-Peter Korn was also convinced of this, until he took an the ScrumMaster role for the project "Basislehrgang Social Media," at the  social media akademie. Their mission was to produce the prerequisite materials for this program.

Although Hans-Peter lives in Switzerland, the Team was distributed throughout Germany. To minimize costs, it was necessary to hold all meetings virtually.

How well did these virtual encounters work? How did they maintain concentration? What tools did they use? Hans-Peter will give us an overview of his experiences and leave plenty of room for discussion on how a Scrum team can use social media to organize itself.

When: July 7, 2010
Where: SwissICT, Vulkanstrasse 120, 8048 Zürich
Time: 8.00 to 11.00, Coffee 8 to 8.30, Presentation and Discussion 8.30 to 10.00, Informal Discussion and Networking, 10.00.
Registration: Online at the SwissICT

And of course, the Lean Agile Scrum Group will meet afterward for the final planning of the Lean Agile Scrum Conference in Zürich. All interested parties are welcome!

I am pleased to announce that registration for the Lean Agile Scrum Conference in Zurich is now open.

Readers of this blog know that this year's LAS Conference is focused on bridging the gap from that first Scrum/Agile project to becoming a Lean enterprise. To this end we have invited two thought leaders as our Keynote Speakers:

• Henrik Kniberg, Swedish author of Scrum and XP from the Trenches, explores the core elements of both Agile and Lean, and how these toolboxes can be successfully combined: 'The Thinking Tool Called Agile.'
• Mary & Tom Poppendieck, co-authors of the Lean Software Development books, questions the biggest fallacy in organizing work -- the idea that schedules or “plans” lead to predictable performance. The Tyranny of “The Plan”

Rounding out the event, we have received great tutorials and experience reports from Swiss, German, and International Speakers: Josef Scherer, Dr. Peter Kessel, Marcel Bauma, Ralf Wirdemann, Stefan Roock & Markus Andrezak, Joseph Pelrine & Adrian Honegger, Turgut Dogan & Alain Giulieri, Hans Neumaier, Urs Enzler, and Silvana Wasitov. See the conference program for details.

Lean Leadership Course

After the conference, Mary & Tom Poppendieck will hold a Lean Leadership Workshop for Managers and Thought Leaders: How to structure work in your organization to achieve much better results. Conference participants receive a 10% discount — register directly with the SwissICT.

Conference Details

• What: Lean Agile Scrum Conference in Zürich
• When: September 7, 2010, 8.00 to 18.00 - the first 2 hours are free of charge
• Where: ETHZ, Building ETZ, Gloriastrasse 35, 8006 Zürich
• Program Languages: German and English.
• Registration: SwissICT
• Follow us on twitter

I just stumbled upon the prize money table at Wimbledon. The winner gets one million pounds sterling. The runner up gets 1/2 million. The 64 first round losers get £11'250 each and the 32 second round losers get £18'750 each. In total, those 96 losers earn £1.32 million. So the two finalists earn more than the 96 losers competitors in the first rounds together. Furthermore, the increase over 2009 was 17.6% for the top 16 players, but only 4.7% to 6.8% for losers of the first three rounds.

Wow.

Are there any similarities to pay scales withing companies? Actually, I think I know the answer to this one. More interestingly, given that corporate pay scales do look like tennis tournament prize winnings, what effects does this have on cooperation and teamwork within the company, especially at the levels of top management or between the departments of the "Quarter-finalists"?

A member of the Agile-Swiss  Linked in Group recently asked, "I've read about Scrum, XP, and Lean. What are the current Agile frameworks available for software development? What are the advantages and drawbacks of each of them?" Since the discussion is not world readable, I decided to republish my answer here.

A quick overview of top agile processes

The Lean and Agile approaches are far more complementary than they might seem at first glance. All of these approaches are built on principles and values which emphasize people, communications, quality and continuous improvement.

If we think of Lean as first and foremost a set of principles for thinking about producing value for customers, then these principles can be applied to many (all?) situations and are very helpful for understanding why Scrum and XP work.

If we think of Lean as a set of 'best practices,' then Lean can be quite counterproductive. Why? Best practices are only 'best' in a particular context. Lean evolved originally in a Manufacturing context and many of its practitioners are not aware of how Software Development and Manufacturing are different from each other.

XP and Scrum emphasize empowered, self-organizing teams (think special forces, not infantry) and are especially suitable for creative environments, like new product development.

Scrum is a simple framework for organizing teams to solve complex problems (e.g. creating software, changing organizations). Scrum places a strong focus on systematically identifying and eliminating impediments. Therefore Scrum is primarily a mechanism for introducing change into an organization.

XP stands for eXtreme Programming. The name comes from taking good values and practices to the extreme, to make them even better. XP is primarily known as a set of engineering practices for producing high quality software. Despite being the foundation for fast time to market with quality product, engineers have had difficulties gaining acceptance for their preferred practices, because management has difficulties understanding them.

Scrum is Lean...

with a Turbo Charger! Scrum perfectly complements a Lean strategy, provided that management 1) understands the nature of Scrum, 2) understands the context of their environment and how it is different from other environments, and 3) is truly committed to improving their organization.

Scrum enables XP Engineering Practices

Scrum delineates responsibilities clearly and enables (without explicitly requiring) XP and other practices. "If you are not doing pair programming, you're not doing XP. If your team is not allowed to do pair programming, you are not doing Scrum."-- Andreas Schliep.

My experience with Scrum is that it encourages management to do the lean thing without explicitly invoking lean principles, and Scrum enables development teams to use the best practices for their situation. Because of the rhythm of iterations, improvements in performance come quite rapidly.

Are there alternatives?

Kanban Software Development is derived from lean principles in general, and Value Stream Mapping and the Pull Principle in particular. It focuses on visualizing flow and reacting to blockages in the flow. Although some people believe Kanban is less intrusive than Scrum, it is actually a change management process. Like Scrum, it assumes that if intelligent people recognize they have problems, they will take appropriate action.

Kanban is controversial because it rejects a number of established agile practices. Kanban does not specify iterations. It does not talk about engineering practices. It it not 'in-your-face' about change nor does it explicitly delineate responsibilities. It is however compatible with frameworks that apply these practices. For instance, there is also Scrum-Ban, a fusion of Scrum and Kanban.

Despite the concerns, Kanban is the first new approach since Scrum and XP to get much mind-share in the community.

As a coach, I like to start by helping management to see the various inconvenient truths about their organization. Lean gives them the tools to understand the impact of those truths. Scrum gives them and their staff the ability to do something about it. And for teams developing software, XP is a collection of the best engineering practices available, and these are probably appropriate for your software development (and your developers should make that call!).

[Update 21-Jun-2010: thanks to Jens Meydam for his insights into XP and Kanban - I've updated the article based on his feedback on the LinkedIn discussion.]

Next week, Scrum Breakfast regular Franco dal Moulin is hosting an event dedicated to Best Practices in Near-shoring:
In the working models of software development near-shore is becoming increasingly important. Companies work with developers in nearby countries or entire teams are tied into their own organizations. The main reasons for this tendency are often the structural shortage in Switzerland, significant cost savings and greater flexibility, - among the few typically quoted ones. Did you know part of Ken Schwaber's vision for Scrum included enabling US (and by extension, European) companies to compete effectively with low cost labor abroad? It is my pleasure to join an experienced group speakers and to give you 'A practical introduction into working with distrubuted teams under Scrum.'

Location: Novotel Zürich City-West
Date: June, 23, 2010
Time: 14:00-19:00
Cost: Free (unless you register and don't show up)
Information: Cirquent Event-Page
Registration: Please register directly at www.amiando.com/nearshore

"People change what they do, not so much because we give them analysis that shifts their thinking, but because we show them a truth that influences their feelings."

John. P. Kotter, Heart of Change High Performance requires
Engineering, Teamwork and Focus
Photo (c) Fotolia
A classic failure scenario when implementing Scrum is lack of understanding and support from management. Why? Since they do not understand what the Agile/Scrum teams are trying to accomplish, the have not bought into it.

Mary & Tom Poppendieck closed the gap between management and Agile with their Lean Software Development books. Inspired by their work, I have created a series of workshops, the Lean/Agile Leadership Series to expose all levels of management to the basic truths behind Lean, Agile and Scrum.

The goal of these three Workshops is to create Awareness, Interest and Desire among all levels of Management and Thought Leaders for the Lean Principles and Agile Values.

Each on-site workshop consists of an introduction to the corresponding Lean and Agile principles and values, a discussion of the pressing issues of your organization, an interactive simulation to experience the principles at work, and a debriefing on opportunities and side-effects of applying these principles in your organization. You and your management leave each workshop with ideas for improvment that you can apply to your business immediately.

Curious about the workshop? Download the Lean/Agile Leadership Series description or contact me.

Ready to go beyond the internal marketing phase? The check out Mary and Tom Poppendieck's Lean Leadership course to learn essential Lean tools, skills and principles. September 8 and 9, 2010 in Diessenhofen, Switzerland (45 Minutes from Zurich Airport).

The focus of this year's Lean Agile Conference is on bridging the gap from the first agile projects to achieving a truly 'Lean' Enterprise.

To that end, the LAS organizing committee selected a group of speakers from Switzerland and abroad who can illuminate this chanllenge from as many different perspectives as possible.

You can choose from experience reports from the management perspective from mobile.de, Baloise Insurance and Nokia Siemens Networks, and from the staff perspective at SIX Card Solutions.

Three tutorials guide you in Scrum, Scaling Scrum, and Agile Project Governance. A tutorial and a presentation address the technical challenges: Acceptance Test Driven Development (so the customer gets what he wants) and Architecture in an agile context.

An interactive workshop with the keynote speakers (space limited) and an expert to expert coaching sessions 'the doctor is IN' give you a chance to bring home the answers you need to the challenges you are facing!

Keynote Speakers

• Mary & Tom Poppendieck, authors of the Lean Software Development books
• Henrik Kniberg, author of Scrum and XP from the Trenches and leading authority on Kanban

Tutorials

• Scrum Einführung - Josef Scherer 
• Agile governance for software teams - Dr. Peter Kessels 
• Scaling Scrum in a Software Service Company - Marcel Bauman
• Akzeptanztest-getriebene Entwicklung von User Stories - Ralf Wirdemann

Presentations

• Enterprise wide Kanban at mobile.de - Stefan Roock & Markus Andrezak
• Transitioning the Baloise to Agile - Joseph Pelrine & Adrian Honegger
• Erfahrungen und Lehren aus einer großen Lean / Agile Transformation - Hans Neumaier (NSN)
• Von User Stories zur Architektur - Urs Enzler
• Der Mitarbeiter auf dem Weg vom Scrum-Team zum agilen Unternehmen - Turgut Dogan & Alain Giulieri
• Overcoming Distance - Scrum with Distributed Teams - Silvana Wasitova

Interactive 

• Value Stream Mapping Workshop with H. Kniberg and the Poppendiecks. 
• 'The Doctor is IN' - Free 1 on 1 coaching on any problem you might wish to talk about, provided by experts in the field -- the other participants at the conference. 
• World Café and Apéro  - experience sharing and networking to close out the day.

We'll be publishing the conference program on the leanagilescrum web site shortly and start to accept registrations. Watch this space...

We are once again privileged to welcome an international speaker to the Scrum Breakfast. I met Kent Johnson in Orlando where he shared the Keynote Address to the Scrum Gathering with Jeff Sutherland. Kent CTO of AgileDigm, Incorporated and has been looking at Scrum in very large organizations and the co-existance of Scrum and CMMI in particular.

Scrum and CMMI are often considered at odds with each other. What does each approach bring to the table? Scrum promotes the idea of focusing on the most important product issues first and supports frequent communication. CMMI (Capability Maturity Model Integration) is a reference model that helps organizations to improve their performance. CMMI brings a structure that promotes consistency and discipline to avoid waste and rework. So, why should we try to combine both approaches? Is this combination a good idea?

In this talk Kent will describe work that he has done with organizations around the world and with Jeff Sutherland, co-creator of Scrum. In these activities, we have identified a number of organizational impediments to really good Scrum and hyperproductive Scrum as well as some key problems with CMMI.
Programm08:00 - 08:35 Kaffee & Gipfeli 08:35 - 09:50 Vortrag & Diskussion 09:50 - 10:50 Networking, Kaffee & informelle Diskussionen
... and don't forget 'the doctor is IN' if you want advice on a problem!
Registration and InfoWhen: June 2, 2010
Where: SwissICT, Vulkanstrasse 120, Zürich-Altstetten
Registration: SwissICT

The LAS Conference Organizing Committee met last night to select the sessions for the LAS Conference in September. We had some 26 proposals from 19 speakers from Europe, North America and Asia. Everyone is under time pressure. How do we get through the task of sifting through all the proposals and agreeing on a program quickly and effectively?

While co-teaching a CSM Course with Peter Hundermark, I saw a new estimating technique (well, new for me ;-) 'affinity estimating' as an alternative to planning poker. I thought this would be useful for selecting the talks and tutorials, so we decided to give it a try.

Preparation

1. Everybody read all the submissions (46 pages!)
2. For each Submission, I created a card with the title of the submission. I used yellow cards for talks, blue cards for tutorials and green cards for submissions that could go either way. (Next time, I would also put on the page number of the submission in the printout)
3. I created column headers (white) Great, Good, Maybe and Questionable.

First we discussed our criteria for a good presentation, decided to rate the talks on their intrinsic quality first, and then handle in a second step the evaluation criteria necessary to create an attractive, balanced program. We decided we wanted 10 selections (for the program) and some alternates (just in case!). Then we agreed to try out the Affinity Estimating to rate the submissions.

Affinity estimating is pretty simple: for each story size, one column (e.g. 1, 2, 3, 5, 8, 13, 20, Too Big). To estimate a story, put its card down in a column, and anybody can slide it around to another column. If it stops moving, you have an estimate. If not, you need to discuss the story to come to a consensus. It can be very useful for (preliminary) estimates of large backlogs, because it is very fast and requires little discussion.

So we set up our columns, put down 6 cards, and moved them around until they stabilized. If they didn't stabilize, we put them in a 'to be discussed' column to discuss at the end. When all 6 cards were placed, we put down 6 more, et cetera until all cards were placed.

At this point, we put all the 'maybe' and 'questionable' cards aside. We were left with 14 cards.

We discussed the criteria for creating the program. There were a number of points: the mix of management, technical, team and corporate topics as well as Swiss and International speakers. What questions do we think will be important to the participants. We also wanted to ensure a balance of the various consulting companies. It wouldn't do to have one or two companies dominate the proceedings.

Next we set up the 10 Slots (4 Tutorials and 3 x 2 Tracks ) and used the same process to put stories to tracks, looking to create the right balance. Again, moving cards around on the table was an easy way to identify which topics complimented each other, which were overlapping, etc.

Eventually we were happy and the cards stopped moving around. We wrote down the results and also took a picture of the final assignments.

That left four cards left over. We decided that these would be our alternates (and we think we have enough good material for an evening event in October or November).

That was it. Four was a good number of participants in the meeting. We managed to stay in our timebox of 2 hours without really thinking about it.

And looking at the results, I think we have a good balance of interesting talks for the Conference this fall (which I think is really a statement about the speakers and their submissions!)


P.S. What happens next for the speakers? I will contact them later this week, so we can start to prepare the program.

I am again pleased to sponsor the Lean Agile Scrum Conference in Zurich and to enable a workshop led by important thought leaders in our domain.

Just after the conference, Keynote speakers Mary & Tom Poppendieck will offer their new course in Switzerland, Leading Lean Software Development. Lean Software Development combines two successful approaches to management: "Lean" -- well known for its impact in the manufacturing sector (and familiar to management through their business school training) -- and Agile -- which, especially in the form of Scrum and despite unfamiliar terminology and guiding principles, has become quite widespread in the software sector.

In this management retreat at the idyllic Seminar Hotel Unterhof on the Rhine, leaders will learn why "Results are not the point." Success comes from people, and creating a system so that your people can achieve successful results is the point.

Special Early Bird Pricing:

Conference participants will get a 10% discount once the program is announced and conference registrations are open. If you register before then, you qualify for a special 25% discount. See the Course Description for details or just Register now.

Registration:

• Dates: September 8 & 9, 2010
• Location: Seminarhotel Unterhof
• More Info: Detailed Course Description
• Lodging: We have reserved a room contingent - please contact me for details. 
• Register now

International, virtual teams are more the rule than the exception in Software Development Projects. Customers, Suppliers and Development Partners come together for a project, separate and regroup in a new form for the next project. Further, such projects are often confronted with strict regulatory requirements. These start with requirements for documentation and may include prescriptive definitions of how to develop the software and manage the application.

How can you optimally use an agile approach within this strict legislative context? What makes sense? What problems can you expect?

Ralph Dröge, Senior Consultant at Liance GmbH in Kaiseraugst, will examine these questions based on his project experience.

When: May 5, 2010,
Where: SwissICT, Vulkanstrasse 120, Zürich-Altstetten
Registration: SwissICT

Recently, I asked myself, "What does it mean for a company to be agile?" and came to the conclusion that "Agility is the ability to change your mind intelligently, based on new information."

Why is the Waterfall so cumbersome, so un-agile, and why are companies stuck in the waterfall? One reason is Work in Progress. Let's take the example of a large services company which provides its services to other large, institutional customers. A typical such organization might have:

• Sales Department - they sell service contracts
• Pre-Sales/Engineering Department - they determine the business requirements and write specifications for custom development
• Software Development Department - they write the software
• Quality Assurance Department - they protect the company from disaster
• Operations Department - they deploy, uh, working software (and Development babysits the system until it really works).

Sales is selling services which the development team will work on, say, a year from now. Pre-Sales is writing specs for software which the development team will work on in 6 months. The development is working now to satisfy contracts that were signed over a year ago. And the QA is working on software that the development team "finished" 3 to 6 months ago and for which the contracts were signed as long as two years ago.

The pipeline is permanently full, it takes a long time to for wishes to be transformed into working features, and there is constant pressure to keep the flow moving (just like in fluid dynamics!). So the company has great difficulties changing priorities, because that means throwing away vast amounts of unfinished work, and that can be expensive!

So if WIP creates inertia which makes a company cumbersome, stiff, inflexible or worse, what would be the state of perfect corporate agility? Having no work in progress at all.

At the end of every sprint, a Scrum team should have no work in progress. The software is (potentially) shippable.  If the Scrum Team has done its job well, all backlog items are "done", there is no undone work, and there is nothing preventing the product owner from requesting a shipment. This is a natural point for changing priorities and direction.

As I understand Kanban, it emphasizes limiting WIP to improve flow. But the pipeline is never empty. The pressure is limited, but there is no point where there is zero WIP. Scrum provides natural points to set entirely new priorities: the planning for the new sprint.

Is Zero WIP something that customers value? One concrete expression of the Zero WIP approach is the "Money for Nothing, Changes for Free" contract. Since the project has Zero WIP the end of each sprint, there is no reasons not to accept changes in the product backlog, or for a fee, the cancellation of the rest of the project.

Are moments of Zero-WIP a desirable goal?  Does this offer an important advantage to Scrum which is not achieved by the flow optimizing Kanban?

Six Card Solutions belongs to the earlier adopters among Swiss Financial Institutions deploying Scrum. They started rolling out Scrum among their 80 developers in Zurich last Summer (2009). So, how did it go?

Christoph Loher (Product Owner) and Stefan Kinigadner (ScrumMaster) were the leaders of the first team to transition to Scrum at Six's Development Group Zurich. The organization presented to usual challenges one expects when trying to transition one team to a cross-functional Scrum in a company that is organized on function division. Despite this challenge, the team was able to achieve a pretty good Scrum (based on Henrik Kniberg's Scrum Checklist).

One problem in particular stood out: As the project unfolded, the team grew. This was a relic of the classical project planning. At some point, the team became unwieldy - 12 people or so - and performance stagnated. The P-O wanted to split the team in two. Although they talked about it in several retrospectives, the team was never enthusiastic about splitting. Eventually, the P-O insisted (but avoided falling back into command and control). Although not all variables have been eliminated, after the first sprint after the split, it looks like the team(s) substantially improved their productivity and everyone agreed the split was a good thing.

You can download their presentation here:  Scrum at Six Card Solutions

A lot of the discussion centered on why the team could not agree to split. My take: the members of a team are expected to form a unit, to commit to that unit and to solve problems together. Even the ScrumMaster is taught 'When in doubt, ask the team!'  Asking a team to split itself up is asking the team members to reject their identity, something they are not all inclined to do!

Perhaps there are limits to what problems self-organizing teams can be expected to solve. And this hints at the role of management in a Scrum organization.

What's your experience? What are the limits of a self organizing team?

Due to the realities of Swiss school holidays (and their indirect impact on the organizers ), we have postponed the submission deadline for the Lean Agile Scrum Conference in Zurich to April 30.

We have already received several good proposals, but still need some more, particularly for the tutorials. In the name of the conference committee, I'd like to encourage to submit talks about your experiences connecting the agile team to create a lean enterprise!

To the CfP in English and German.