Thursday, November 22, 2012

How do I do #Stoos in my company?


Monday, Steve Denning and I held our Monthly Mashup webinar dedicated to the question, "What is Stoos?" If you haven't followed the linkedin discussion, I urge you to check it out! In any case, one of our participants, Gary from Chicago asked:
I am in the process of forming a new company which will operate in a niche within the chemicals industry.   I am not looking to change my organization, I am looking to start my organization using Stoos, Agile and Radical Management from the outset.  It would be helpful to know who within the global Stoos network might be available to consult regarding my startup keeping my developing organization on the path of being customer focused with empowered employees.
Great question! A couple of answers came back:
  • Several of the panelists are in that business (surprise!). For example, Steve & I teach a course on Radical Management. I also teach Scrum and lead Temenos visioning retreats to enable your your leadership team to create a compelling shared vision. In my own entrepreneurial work, I have gotten quite excited about the Lean Startup approach and am happy to share my excitement! 
  • Ask on the Stoos linkedin group or in the nearest Stoos Satellite - In your case, I would suggest starting a Stoos satellite; AFAIK the Denver Satellite is most active in the USA.
  • A number of the compatible frameworks have active user communities, coaches and trainers: Scrum, Kanban and Lean Startup come to mind, and these could be good places to start.
On reflecting, I'd also like to encourage you to take your destiny in to your own hands! The Agile Manifesto shows you how!

Apply the Agile Manifesto to your Company or Context

Remember the Agile Manifesto? "We are uncovering better ways of developing software..." What follows are 4 value statements and 12 principles that are surprisingly universal. Joe Justice, CEO of WIKISPEED, suggests adapting the Agile Manifesto to your situation and using the values and principles to guide your actions.

How can you apply the Agile Manifesto to your situation? Replace "develop software" with whatever you do or your company does. If you are an interior designer, you might say "We are uncovering better ways of designing homes..."

Now, go a step further! Look at your work from the perspective of the beneficiaries of your work. In the case of an interior designer: We are uncovering better ways to create living spaces for individuals and families. Now you have your own personal "Agile Manifesto!"

Once you have your own personal manifesto, you can go through the values and principles and ask yourself, how does this apply to my quest for better ways of working or creating value for my constituents? For each value and principle, identify one or two things that you can start doing differently tomorrow to apply that principle. Voilà! You're doing Stoos!

Maybe one or two of the principles don't apply to you, and that's OK. Maybe there is another principle that you have discovered, which for some reason is not in the software developer's Agile Manifesto. Is it compatible with the four values? Then that principle is OK too! You are creating your own manifesto!

Good luck! And I would love to hear back from people who go through this exercise and apply the results to their business!


Monday, November 19, 2012

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine.
What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a shared understanding of what it means to be finished, so everybody in the project means the same thing when they say "it's done". More subtly, the definition of Done is an expression of the team's quality standards. A more rigorous definition of Done will be associated with higher quality software. Generally the team will become more productive ("have a higher velocity") as their definition of Done becomes more stringent, because they will spend less time fixing old problems. Rework all but disappears.

So the Definition of Done should evolve as the project advances. Here is the first Definition of Done my team used when we started to develop the HappinessApp:
  1. Unit tests written and green
  2. Source code committed on server
  3. Jenkins built version and all tests green
  4. Code review completed (or pair-programmed)
  5. How-to-Demo verified before presentation to Product Owner
  6. Ok from Product Owner
For each Product Backlog Item ("story"), my team and I agreed on a workflow to show that the story has been implemented correctly. We call this "how-to-demo." More subtly, the combination of story title and how-to-demo limits the scope of the story and prevents scope creep during the sprint!

This definition served us well until we started releasing our beta test results to customers, starting with me. I was are first customer. So we enhanced the definition of done as follows:
  1. Potentially releasable build available for download 
  2. Summary of changes updated to include newly implemented features
  3. Inactive/unimplemented features hidden or greyed out (not executable)
  4. Unit tests written and green
  5. Source code committed on server
  6. Jenkins built version and all tests green
  7. Code review completed (or pair-programmed)
  8. How to Demo verified before presentation to Product Owner
  9. Ok from Product Owner
Very quickly, we discovered that an upgrade on an actual iPhone would overwrite existing user data. This was a bad thing (especially for a diary application!), so we added another point:
  1. Upgrade verified while keeping all user data intact.
  2. Potentially releasable build available for download 
  3. Summary of changes updated to include newly implemented features
  4. Inactive/unimplemented features hidden or greyed out (not executable)
  5. Unit tests written and green
  6. Source code committed on server
  7. Jenkins built version and all tests green
  8. Code review completed (or pair-programmed)
  9. How to Demo verified before presentation to Product Owner
  10. Ok from Product Owner

This version held up pretty well through the next 8 sprints or so until we finished developing the beta version. We did experiment with two other points which were inspired by Release It, the guide to designing and deploying production-ready software:
  1. Design review -> list of how-could-this-feature-break failure cases (at least 3 unhappy paths)
  2. Identified failure cases covered in design decision or unit test
Our developers had difficulties living this one, so we have put them on hold (until something important breaks, then I, as Product Owner, will have the basis for a discussion with the team ;-)

In retrospect, the Definition of Done and the engineering practices they imply have served us well. The product has been remarkably free of technical issues, so the team has achieved the proverbial "technical success." Next step for us is to get it out there and help in become an genuine success.

The Definition of Done is important to Scrum, but there are many facets to done-ness, of which the Definition of Done only covers a few. "What do you mean it's done? Only two little features have been implemented! Before we can call it done, all 150 features must be implemented!" I look forward to revisiting this topic in a future article, tentatively titled "The Three Faces of Done." In the mean time, my CSM Students (for whom this article was written) can explain it do you!




Sunday, November 18, 2012

What is the role of a Business Analyst in Scrum?

When I teach a CSM class, my goal is that my participants go home delighted (and of course that they learn about Scrum, that they are motivated to do Scrum, and can pass the online CSM exam). So after every class, I ask for feedback, in particular what could I do to get a better score. And for the next class, I strive to implement or address two or three of the points raised by my participants.

One issue that was raised was unanswered questions. It is annoying to ask questions and not get answers! Time is limited, so it is not always possible to answer all questions, so I thought, why not answer them on my blog? So here goes, first question:

What is the role of a Business Analyst in Scrum?

This question is a challenge because Scrum doesn't answer this question! Scrum is a simple, team-based framework for solving complex problems. The roles and ceremonies in Scrum are designed to ensure that inspect and adapt can occur regularly with complete and correct information. Scrum does not tell you how to solve the problem, nor does it tell what skills are needed to solve a particular problem. It just says that you need all the necessary skills in the Development Team to get from a Product Backlog Item to a finished Increment of functionality within the duration of one Sprint.

The Business Analyst as Product Owner

Traditionally, the business analyst serves as an interface between the customer and developer, helping the developer to understand the customer's requirements. The responsibility for this function is vested in the Product Owner, so one alternative is for the business analyst to take on the this role. This probably represents a substantial promotion for most business analysts, because the Product Owner is responsible for the return on investment of the project, a function which has traditionally been held by a Steering Committee or other oversight function. A danger of this approach is delegate the title, without delegating the necessary decision making authority.

The Business Analyst as part of the Development Team

A second approach is for the business analyst to be part of the Development Team. Scrum explicitly enables the Product Owner to ask the team for help creating and refining the Product Backlog, so it would be logical to have business analysis skills in the team. The challenge here is that Scrum does not recognize job titles or sub-teams. While a business analyst will mostly do analysis, she will be expected to help with development, testing or documentation, as needed. The team solves the problem as a team, and 'There is no analysis work to be done, so I'm going to twiddle my thumbs' is hardly a good example of team work.

The Business Analyst as part of a Product Owner Team

A third approach (one I have seen quite a bit in the wild) is for the Product Owner to ask for help defining and refining the Product Backlog, and getting it in the form of an assistant or two, usually someone with substantial domain knowledge. So these people help with the creation and refinement of the Product Backlog, while the prioritizing and decision making authority stays with the Product Owner.

How the work of the Business Analyst changes

Regardless of where the business analyst is integrated into the Scrum Team, the skills of the business analyst remain important to the success of the project. How the business analysts works will change subtly. If before she was mostly an author, writing and explaining spec, in Scrum she is more of a communicator. The difference is due to how the Product Backlog is converted into functionality.

The Product Backlog, the list of features to be implemented, can be thought of as a list of reminders to have a conversation. That conversation is between the Development Team and those who understand the customer's or users' needs. As implementation nears, that conversation will get more detailed. First big entries will be replaced with smaller ones, then entries will be enriched with acceptance criteria, implementation considerations, GUI sketches, whatever... So rather than attempting to communicate in writing and in advance what is desired, the business analyst will be discussing with the rest of the team what is to be implemented and protocoling the decisions. This discussion will take place shortly before the feature is to be implemented, so the discussion is fresh in everyone's mind when the feature is actually implemented.

In other words, detailing and specifying features still takes place, and the skills of the business analyst are still needed. The requirements and acceptance criteria are delivered incrementally as a result of discussion. The skills are the same, the needs is still there, but the the deliverables and how they are created have changed slightly.