Friday, June 29, 2012

Using Scrum For Organizing Your Life


One of the most amazing and rewarding things to me is how Scrum is being used not only in software development, but in all sorts of areas, from schools and churches, to everyday. After I realized Arline was using Scrum to organize a family weekend, I asked her to write about it.

A family Scrum Board, from scrumforkids.com
Scrum is used by all kinds of people in all sorts of places to plan everything from weddings, preparing for the arrival of a baby, to managing a household, and getting kids organized. Oh, yes, some people use it to run software development projects, sales teams, corporate finance offices, and manufacturing. 

In our family, as you might expect, we use Scrum for everything, including this weekend. Our younger son, JJ, and his family are coming to Boston for three nights.   This means the delightful task of organizing the days and evenings.  It gets complicated.  They will stay at our older son, Drew’s house.  Counting us all, there will be 8 adults, one 12 year old, one almost 3 year old, and an eight month old.  Two cribs, 1 booster seat, 1 highchair and a potty. 

Adults have work lives, the 12 year old has summer activities, the three year old and the 8 month old need care and meals need preparing.  Did I mention that we have one vegan with a serious case of celiac disease, another vegan, a vegetarian and several carnivores, who cannot imagine a family meal without red meat. 

Thank God for Scrum!

Taking on the role of Product Owner, I’m creating a Backlog:

  • Plan menus that accommodate food restrictions and preferences
  • Create list of guests to include
  • Send invitations
  • Prepare Shopping List
  • Shop for food
  • Food prep
  • Form Clean-Up Committees
  • Form Welcoming Committees
  • Form Table setting teams
  • Form Seating Plan and Place Card writing teams
  • Unpack recently purchased supply of non-gluten contaminated kitchen items
  • Make sure the Grill is ready to go – clean and with enough propane
  • From an entertainment committee - games, excursions, etc
  • Rent items needed by visiting grandchild
  • Make arrangements to pick up visiting family members at airport
  • Provide child-care for visiting grandchild while most of family is at work
  • Schedule Skype Conference Call for Backlog Grooming and Sprint Planning Meeting
  • Cook 3 dinners, 3 breakfasts, and 4 lunches


Over the years, I have found that THE key to an effective Scrum is to ensure that the entire Team participates in Backlog Grooming and creating the Sprint Backlog.   We are a distributed team and will remain so till Thursday evening.  Emails only accomplish so much.  A Skype conference call will be needed.  

The disciplines of Scrum help create an atmosphere in which the people involved experience freedom and creativity.   

- Arline Sutherland

Well, it's going well so far. The first big dinner is tonight. If you really want to use Scrum to improve your practice, whether it be software development, management, sales, or running a house, my next Certified Scrum Master Course is in Boston on July 26-27.


Saturday, June 02, 2012

Enabling Specifications: The Key to Building Agile Systems

Previously, I discussed the notion of "Agile Requirements" and this concept is embedded in the Nokia Test. There is not a definition of Agile Requirements that is commonly agreed upon, so I now use a standard concept that is better terminology for what is needed.

For many applications, particularly web applications, a story only needs notes and acceptance tests on a card or sticky note. For some applications, like mobile applications for physicians, unless a fully formed prototype is acceptable to a carefully selected group of test physicians, end users will refuse to use the application when it is installed in the hospital setting. Therefore, a fully formed enabling specification, with a fully working prototype, needs to be agreed upon before cutting a line of code.

Apple uses this routinely which is "Why You Can't Innovate Like Apple." PatientKeeper used this strategy during 2003-2008 which is one of the reasons they were the fastest company-wide set of Scrum teams I have ever seen. I called them "The Future of Scrum" at Agile 2005. Some people said PatientKeeper looked more like Kanban than Scrum so they were also the fastest Kanban teams ever seen. I have always run Kanban inside of Scrum since 1993 since Scrum is Takeuchi and Nonaka's view of lean teams. However, we tried to minimize the Kanban, just as Taiichi Ono did and as Toyota does today.

In 2007, I visited PatientKeepers patent attorneys as our CEO wanted to get a patent on a discovery of a reporting strategy for analyzing physician fee payments that would raise hospital revenue by 30% during the first month of use. I asked the Product Owner to bring along what documentation she had for review by the lawyers. There was a three page Agile Specification. This is a document that Product Owners at PatientKeeper use to describe the global concept of a feature. User stories are developed from this document.

Our goal was to work with the lawyers to understand how much documentation was needed for a patent application. The lawyers pointed out that a patent application is an "enabling specification." This is a legal term that describes a document that allows the average person knowledgeable in the domain to create the feature without having any discussion with the originators of the enabling specification.

The lawyers determined that our Agile Specification of three pages was not an enabling specification. To produce a document that would be approved by the U.S. patent office we would need five pages.

It turns out that an enabling specification is exactly what is needed to maximize the process efficiency of executing a user story. The average process efficiency of teams executing user stories is about 20%. This means a story that takes one ideal day of work takes five calendar days to delivery. Systematic Software Engineering, a CMMI Maturity Level 5 company, has extensive data showing that teams that drive story process efficiency to over 50% will double their velocity systematically for every team. (PatientKeeper was running at 10 times the velocity of our waterfall partner in India.)

The definition of an "enabling specification" is part of U.S. patent law which has been adjudicated extensive by the courts so it is not only a commonly agreed upon concept, you can take your requirements to court and the judge will tell you whether or not they are enabling specifications.

In general, requirements are NOT enabling specifications. On a recent project at a large global company we discovered that hundreds of pages of requirements were not enabling specifications. On the average 60% of what was in the documents was useless to developers. It caused estimates to double in size. Even worse, 10% of what was needed by developers to implement the software was not in the requirements.

The enabling specifications used at PatientKeeper provided a global description of a feature set framed as lightweight user stories with screen shots, business logic, and data structures. The enabling specification was used to generate user stories which then formed the product backlog. The global feature description was updated regularly by the Product Owner team and was a reference to the state of the system that allowed developers to see where the user stories in the product backlog came from.

A user story needes to be a mini-enabling specification for agile teams to operate at peak performance. If it is not, there will be the need for continued dialogue with the Product Owner during the sprint to figure out what the story means. This will reduce story process efficiency and cripple velocity.

A user story contains a template, notes, acceptance tests, and implies a conversation with the Product Owner. So the conversation may be part of the mini-enabling specification if the conversation is clear before the beginning of a sprint. This can be on a card for a simple application and will be on the order of no more than 3-5 pages even for a complicated mission-critical and life-threatening application like the PatientKeeper Platform.

As the lawyers pointed out, an enabling specification for a major feature needs to be no more than five pages. So all of the documentation needed, including transcribing all the conversations, should be on the order of 3-5 pages for a moderately large feature. This is what I mean by "Agile Specification." I now think "Enabling Specification" is better terminology.

2-231 Obtaining Patent Rights  § 2.07[6]
"A patent specification is enabling if it allows a person of ordinary skill in the art to practice the invention without undue experimentation."

See Jay Dratler. Intellectual Property Law: Commerical, Creative, and Industrial Property, Volume 1 for citations.