If any one has made Agile understandable to top management, it has been Mary & Tom Poppendieck, whose Lean Software Development series has bridged the gap between understanding how business works and how software development works.
If you are a C-Level executive and your company develops software, this course is for you. (Even if you don't develop software, you will profit tremendously.) You learn how to focus your company on the right problems, so it can learn systematically to produce more value more quickly for your customers, with less waste.
You can now register online for Mary & Tom Poppendieck's Lean Leadership Course. May 25/26. There is special super-early bird pricing if you register before December 31. (You won't get an invoice until 2011, unless you specifically ask for it this year.)
Peter Stevens, Andreas Schliep, Peter Beck
One year ago, Peter Beck, Andreas Schliep and I decided to form a marketing partnership called DasScrumTeam (The Scrum Team). Our goal was to leverage each others strengths, pool resources when appropriate and share information and experience to guarantee and continually improve the quality of our coaching and courses, and have a common platform for delivering international projects.
It quickly became apparent that DST was a good idea, but we needed to work even more closely together. So this summer, we formed our GmbH in Zurich, got a bank account and VAT number and we are slowly but surely getting ready to start operations. Starting January 1, 2011, we will be doing business as DasScrumTeam GmbH.
What does this mean for you, our customers and partners? On one level, not much. We will continue to offer top quality Training and Coaching in Germany, Switzerland and Austria. Administratively, we have new accounts for payments and a new VAT number, and of course, new email addresses.
Most importantly, we have more depth. A team is stronger than the individual contributors. Our experience complements each other, so we can support your Lean and Agile Transformations at the Management, Team and Engineering levels even better than before.
Earlier, I announced the LAS November Event on Lean & Scrum in Switzerland. (Just a reminder: Dagmar Gawenda will present the Pull Principle: Lean Production at Griesser. Mario Magnanelli and Kai Windhausen will present their experience migrating a large financial organization to Lean and Scrum). Now we have the speakers lined up for the podium discussion.
Francois Bachmann will moderate a Podium Discussion on the realities of migrating to learning, self-improving organizations. Speakers Kai and Dagmar will be joined by
Patrick Scheuerer, Head of Services, Amt für Migration Kt. Bern, and
Mike Kästner, Chief Information Officer, COMIT AG
to discuss the highs and lows of their transformations: "Help, we're going Agile!"
Personally, I am looking to see if/how well Griesser's practical experience with the Pull Principle matches up with the theory. If you believe the simulations, applying the Pull Principle should increase production, decrease turn-around time and free up resources. Does this promise hold up in practice? I'm confident, but I'm looking forward to hearing the details!
November 9, 16.30 to 20.30 (including Apéro and Networking). Information and registration are available online at the SwissICT.
Life is what happens while you are planning to do something else. This is why we do Scrum.
Scrum Breakfast/November: Scrum Introduction: An example from medical IT.
The Scrum Breakfast in November will welcome Yves Aeschbacher, Product Owner and Consultant in the areas of Care and Para-medical Applications for MCS Parametrix. He will share his experiences introducing Scrum into the development of medical applications. In particular, how the Agile approach required rethinking at all level of the organisation.
As usual, First Wednesday of the month: November 3, 8.00 to 11.00 at SwissICT, Vulkanstrasse 120, 8048 Zürich (map). And the Doctor is IN! Register online at SwissICT.
Scrum Breakfast/December: Stories for Samichlaus (St. Nick)
Watch this space for the announcement of a special Christmas Scrum Breakfast!
BTW - Postponed does not mean cancelled. Deasun O'conchuir's talk 'People Challenges in Virtual Working' will be held early next year.
Any of these talks could have been included in the LAS Conference,
but their just wasn't room. So we made space for them! This evening
event is for Scrum-Masters and Scrum Product Owners who want to see how
Scrum can be introduced into a large company and for entrepreneurs,
C-level executives and top managers, who want to bring the companies
into a state of flow. The talks are in German.
Das Ziehprinzip - Lean Production bei Griesser (The Pull Princple at Griesser)
Scrum im harten Projektalltag - Ein Einblick in die Einführung
von Scrum in der SIX Card Solutions AG (Scrum in the trenches of everyday project management)
Podiumsdiskussion (Podium discussion with various experts).
See the annoucement on the SwissICT homepage more information.
Date: Tuesday, 9 November 2010
Time: 16.30 to 19.30 (followed by an Apéro)
Location: Conference Center Hallenstadion,
Wallisellenstrasse 45, 8050 Zürich
Speaking as the organizer, the conference was one high point after
another: The high caliber sessions from Switzerland and abroad, the
keynote speakers, the interactions among the participants. Judging
from the participants feedback, the workshop with Henrik Kniberg and
Tom & Mary Poppendieck received the highest notes.
There was really only one low point: the long wait for food at
lunch. As lean thinkers we should have thought more about the flow!
SwissIT Magazine published a short
article online and more detailed article in their latest print
edition. My favorite quote in the print edition came from Adrian
Honegger, Co-CIO of Baloise Insurance (and speaker at the
"The organizers of the Lean Agile Scrum Conference 2010 succeeded in
bringing together interested participants from Coders to the IT
Executive, including people from numerous branches of industry and
experienced speakers. Summary of the successful event: the rapidly
accelerating market dynamics and increasing complexity, the not only
ICT companies face, are forcing companies to become leaner and more
agile, so that they can react immediately and adequately to new
trends, dangers and uncertainties. In the long term, the winners
will be those IT organizations which successfully master the
transition to Lean, Agile and Scrum."
My personal high points were the Keynote speakers. Henrik make
complicated topics simple and the Poppendiecks bring home why
management and agile teams need each other. I learned a lot from
both, much of which will be really useful when talking to
management, and look forward to seeing them again.
BTW - The Poppendiecks will be coming back to give their lean
leadership course next spring!
User Stories have become so popular for identifying Product Backlog Items (PBIs) that the term 'Story' is often used as synonym for PBI — regardless of whether the item in question is formulated as a user story or not. Not all user stories are created equal - good user stories can be turned into functionality rapidly and predictably by a good Scrum team. Bad stories clog up the works and teams have troubles finishing them in the sprint. So what makes a good story and how do you get it small enough to implement in a sprint?
A user story answers three questions: Who? What? and Why? A user story leaves open the questions How? and When? Mike Cohn popularized the canonical form of a user story: As a <class of user> I want <some function> to achieve <some purpose>. For example:
As a Job Hunter, I want to find and apply for interesting jobs, so I can find a good job and earn a living.
As an Internet shopper, I want to select books from a catalog and order them. (Technically this is not a user story, because their is no explicitly specified goal. Do we need to specify a goal here? Or is it self-explanatory? )
One starting point is the INVEST guideline for good stories. Let's see how these stories hold up on the INVEST scale:
Independent - the stories can be submitted to the team in any order - OK
Negotiable - how the stories are to be implemented is subject to discussion - OK
Valuable - the feature provides value to the customer or user - OK
Estimable - the team can estimate the effort involved - hmm, our sample stories are a bit vague
Small - they are definitely not small - they might be OK for planning for two quarters from now, but no way can they be implemented in a sprint
Testable - yes and no. I would argue that yes, they are testable, but that there is so much room for interpretation, that it is impossible to say what tests are needed and which tests are not needed to confirm that these stories were implemented properly.
If you are in doubt as to whether your stories are good stories, ask yourself if the stories answer the three questions (Who-What-Why) and ask your team if the story satisfies the INVEST criteria.
So how do you make a story smaller? Here is a list of 13 patterns which I would recommend:
Split on user roles/personae
Split on conjunctions (and, or, etc).
Split on functional components
Split on test cases
Split on business priorities
Split on business process alternatives
Sequences - Build the pipeline one segment at a time
Sequences - Bore a pilot hole and then make the tunnel bigger
Split on non-functional requirements
Separate Goal and Function
Split on Data Types
Split on Data Operations
Split on Levels of Quality
This is a long list, so I will work through the list and provide more details about what each of them mean in the coming entries.
Here are some patterns which I would not recommend employing on the product backlog entries:
Spiking is simply dividing the story into analysis and implementation, with a time box and a set of set of questions to answer about the story. It is a good engineering practice, but the analysis part delivers no value to the customer or user. So I would call it part of backlog grooming and insist that it fit into the 10% or so of the team capacity which it invests to getting the backlog item "Ready" to implement.
Layering can be formulated as 'user' story: "As a developer, I want a DB-Schema, so I can deliver value to the customer in a future sprint." Development Process is pretty much the same: "As a developer, I want a spec, so I can implement some value in a future sprint." Both of these stories fail the Valuable test. They are not valuable to the customer or user.
BTW - There are cases where the developer is a legitimate user, such as when the developer needs a certain functionality to identify and fix problems. But when the developer needs an artifact to deliver value in a future sprint, this is a warning sign that you are falling back into waterfall thinking.