Look Forward Consulting

Upcoming Conferences

Carlton — Wed, 04 May 2011 12:31:32 +0000

Been really quiet these past months, but I wanted to share some upcoming places where you can see me in action.

PMI San Diego Annual Conference – On May 13th, I will be giving a class on Estimating and Planning. On May 14th, I will be giving a short tutorial on how to use Innovation Games to prioritize.
San Francisco Agile Conference – my colleague and friend, Angeline Tan (@agilemeister), invited me to be a speaker at this conference she has been working very hard to organize. On June 16th, I will be presenting Improve Flow Through Prioritization.

You can still register for both the PMI San Diego Conference and San Francisco Agile Conference.

Writing Good User Stories

Carlton — Tue, 08 Feb 2011 03:39:57 +0000

User stories are tool that originated from Extreme Programming and have become the de facto way Agile teams document and collect their requirements. There is a lot written on user stories (link, link, link), so I am just going to talk about what I consider important in writing good stories since I see a LOT of really bad ones out there today.

For those who do not know, stories are a lightweight artifact that allows us to both capture the business’s needs AND plan the work. They are typically written on index cards (yes…little 3×5 or 4×6 cards) in the language of the business or customer. With user stories, we only write enough to capture the user’s needs and no more. We tend to view stories not as complete specification of the requirements, but as placeholders for later conversations between the developers and the business.

When used properly, a user story’s lack of detail provides us a great deal of utility – we can use the same document to talk about a requirement from a high-level, zoom in on implementation details and jump back out, all in the course of a few sentences. Then once we are done talking about requirements, we can consider risk, identify dependencies and create a project plan without ever having to put down the index card. Wow !! I know of no other requirements artifacts out there allows us such utility.

Over the years people who are really successful with stories have settled on some commonalities found in all stories:

Role: who, or what, is going to use this feature?
Feature (or capability): what is the Team going to deliver, or add, after they finished their work?
Value: why does the business even want this feature? What impact to the business will it have?
Acceptance Criteria: how will we know if this feature is done?
Estimate: how much does the Team think this feature will cost?

IMO, in order for a story to be considered complete it has to have ALL the characteristics described above. I find that when people have trouble with defining all the characteristics, the stories are not what I call ripe, i.e. they have not been thought through well enough to be usable by the Team. In addition to these characteristics, stories also should follow the INVEST criteria (this great article by J.B. Rainsberger talks about INVEST as well).

Mike Cohn has written a great book on user stories. Unfortunately, for all the goodness in the book, folks seem to have focused on the one bit of junk in the book – the user story template. In his book, Mike offers up a template some teams found helpful with writing stories and from there this template has been the source of so many bad stories that I am not going to give it anymore more ink (or bits). What I object to about the template is that it causes people to stop thinking as they mechanically fill in role, feature and value and omit acceptance criteria and estimate (presumably because they are missing from the template). When I see people struggle with stories, it is because they are trying to jam their business into some template that helped some unnamed team (who probably doesn’t even use this template anymore) five or six years ago and – surprise – it doesn’t fit where they are right now.

There is a thinking process that needs to occur before you write a single story. The steps I tend to see people completing who are successful writing stories are listed below. Please keep in mind, while these steps are linear in my post, one can jump back, forward and skip around as it makes sense. The goal is to have answered these questions by the time you have finished your user story exploration.

What are the roles (or users) that will use your system?
What are their needs? How does the product help them accomplish that?
What features (or capabilities) do you want to provide these roles?
Why are these features valuable to the business? What sorts of business outcomes can we expect from these features?
What are the priorities of these features? Did we make a promise to deliver some already?
How would you know if these features are done?

Finally, people have a tendency to want to write a lot of details on the front of the story card. I have two suggestions for these people. First, use smaller cards – really. User stories are NOT specifications or requirements documents. They are just index cards capturing the user’s needs and reminders that we have to capture those implementation details later. If you are trying to cram more and more onto an index card, that might be sign that you may need specs or some type of design documentation in addition to user stories. Second, the types of details that people are trying to write down are actually acceptance criteria. By pushing those details into the test cases, we keep the story in the language of the business and retain the focus on the feature and value your Team is providing.

SoCal Code Camp Fullerton

Carlton — Sat, 29 Jan 2011 15:55:01 +0000

It is time for Code Camp in Fullerton this weekend. I will be speaking on Saturday on this two topics.

Scrum Roles in Action: in Scrum, there are three basic roles – Team member, Product Owner and ScrumMaster. Each role is defined with some basic specific rights and responsibilities and filling in the rest of what one is supposed to do is left as an exercise for the participants. In this workshop, we will review the rights and responsibilities for the Scrum three roles (plus stakeholders) and discuss what those roles look like when preformed well.
ScrumMaster Toolkit: are you just getting OK results with Scrum? Has Scrum not delivered on the much anticipated quantum leads in productivity everyone had been promised? One common source of lackluster performance comes from following routine behaviors and ordinary patterns of teamwork associated with the “old way of doing things”. In this hands-on workshop, Carlton Nettleton will share powerful techniques from his coaching toolbox that breaks these old patterns, unlocks the potential of Teams and gets them moving toward high-performance.

Scrum Bill of Rights

Carlton — Mon, 24 Jan 2011 18:27:27 +0000

One of the things I admired about Extreme Programming (XP) was the simplicity of the roles defined in the Green Book. In XP, there are only two roles: Customer and Programmer. When you are using XP, the Customer makes business decisions, Programmers make technical decisions and one role may not substitute their judgement for the other. In short, Programmers do not make business decisions and Customers do not make technical decisions. Kent Beck and Martin Fowler even went so far to add a Bill of Rights, which clarifies what people can expect for one another.

Scrum does not have anything similar, so I decided to create my own (modeled on the XP rights). Feel free to distribute and share.

Every Team member has the following rights:

To produce quality work at all times.
To know what is needed from the business with clear declarations of priority.
To ask for, and receive, help from peers, management, and customers.
To experiment with new ideas, technologies and roles to grow both as a professional and an individual.

Every Product Owner has the following rights:

To receive the greatest possible value out of every week.
To know what can be accomplished by the Team, when and at what cost.
To see incremental progress in a viable product proven to work by passing acceptance criteria they specify.
To be informed of schedule changes promptly in order to take effective countermeasures and reset expectations with the stakeholders.
To collaborate with the business on setting the future direction of the product.

Every ScrumMaster has the following rights:

To try out different ideas, approaches and techniques to remove impediments which impede the flow of value.
To be given time for initiatives to take hold and produce change.
To take measured risks and learn from setbacks.
To be supported by senior leaders in the organization.
To be provided access to different parts of the business while identifying and removing impediments.

Every Stakeholder has the following rights:

To receive regular status updates through interacting with a working product.
To change their mind, substitute functionality, and adjust priorities without paying exorbitant costs.
To cancel the product at any time and be left with a working product providing real business value reflecting the investment to date.

Combining Scrum Roles

Carlton — Sat, 22 Jan 2011 16:45:34 +0000

This question started an interesting exchange on the Scrum Development list at yahoo!

The Scrum Guide states that a person can be “Team Member” and “Scrum Master”, a ”Team Member” and “Product Owner” but emphatically rules out ”Scrum Master” and ”Product Owner” roles by one person. I understand that all these “role combination” lead to one person being split between two set of duties that are required to be performed. But why does only the “SM & PO” combination find particular mention as not acceptable.

The way I teach the Scrum roles is that the Product Owner is responsible for the business outcomes and the ScrumMaster is responsible to ensure the process is implemented correctly and improves the flow of value. These responsibilities require very different skill sets and it is rare that all are in one person or that one person wants to learn them all. When the two are combined, one is responsible for doing the work of two people in an 8 hour day – which is then a violation of the Agile principle of sustainable pace.

IMO, I often see people wanting to combine ScrumMaster with Product Owner or as a Team member, i.e. continue as a contributor. As a friend of mine pointed out to me, this desire to combine the roles often speaks to hidden assumption\perception that there really is not enough stuff for a fulltime ScrumMaster. Some people look at the framework and think: “ScrumMaster facilitates some meetings (check), updates Burndown chart (check) and does self-organization (check), not enough here to justify 100% allocation.”

Oh how wrong! Being a ScrumMaster is a full time job. First, one has to help the Team become self-organizing. That is a lot of work, requires close proximity to the Team and many hours of observation. It is not something you can “phone in“. Second, as ScrumMaster you are accountable to the stakeholders to improve the flow of value and help remove the organizational waste, i.e. impediments. A lot of that effort is building relationships with different stakeholders and participating in efforts to remove organizational roadblocks (sometimes called kaizen). You cannot be writing code, doing design or however you contributed in the past, if your responsible for identifying and removing impediments.

Scrum Roles Defined

Carlton — Fri, 21 Jan 2011 16:52:00 +0000

I do a lot of work with Scrum and the ones that struggle the most are the ones where the Scrum roles are poorly defined and\or not filled properly. Scrum is a balanced framework and when the roles get muddled, the framework begins to adopt the dysfunctions of the organization and is not as powerful as it could be.

In Scrum there are three roles – Team member, Product Owner and ScrumMaster. Those three working together are called the Scrum Team (or just the Team). I add a fourth role – Stakeholder – to recognize all the people who orbit a Scrum Team and influence them. I define all these roles like this:

Team: dedicated collection of self-organizing, interdependent, co-located individuals representing different functional roles with all the necessary skills to turn Product Backlog items into a potentially shippable increment within the Sprint.
Product Owner: an empowered individual applying their personal and professional judgment to make decisions in the best interest of different,often times competing, business stakeholders to maximize the business value the Team produces each Sprint
ScrumMaster: a dedicated individual responsible for improving the performance of the Team and the business by any means necessary.
Stakeholder: any person who has a direct, or indirect, interest in the work of the Team.

Keep in mind, these are role definition, not job descriptions and they are very loosely defined. It is important that each role is filled. In general, the Product Owner is concentrated on the providing valuable business outcomes to the business, while ScrumMaster is aiming his\her efforts at the execution of good Scrum and improving the flow of value to the customer. Meanwhile, the Team remains centered on learning how to self-organize and deliver potentially shippable increments regularly. Stakeholders provide feedback on the value of everyone’s efforts.

When Scrum falters, it is often because people are not committing to their roles. Other times, organizations chose to overload one, or more, roles in a single person, disrupting the balance of the roles. Recall, the Scrum framework was designed to provide the maximum amount of flexibility with the minimum amount of control. If these roles cannot be filled with individuals who will fully inhabit them, or they are overload, the control mechanisms of Scrum become unhinged, visibility is diminished, accountability is lost and the framework loses its meaning.

When Scrum is done well, there exists a natural tension between each role. This tension exerts a force that tends to prevent the other roles from meddling in responsibilities that are not their own. Since there are considerable gray areas on the role boundaries in Scrum, each role will eventually bump into one another as they discover what are the boundaries of their responsibilities. This friction is an essential part of learning how to do Scrum and making it meaningful to your business. Through the of process of inspect-and-adapt, the precise definition of each role – Team member, Product Owner, ScrumMaster and stakeholder – emerges as your organization gains experience using Scrum.

One of the main reasons why I add a Stakeholder role to Scrum is because many Scrum implementations improperly keep these people out of the process. Scrum was not designed to keep the Stakeholders from interacting with the Team. In fact, Scrum was designed to bring these folks closer together. What Scrum tries to do is give the Stakeholders a more meaningful, structured way to interact and provide the Team with feedback via the Sprint Review. This is the opportunity for the Team to hear direct, unvarnished feedback on what they really think. This is why Stakeholders have a dashed line connecting themselves with the Team, rather than a solid line.

Font Matters

Carlton — Wed, 19 Jan 2011 16:03:49 +0000

I came across this article today about the importance of font to improve reading comprehension. In the past four months, I have been doing a LOT of instructional design for the variety of classes my business now offers. Much of this work is based on Sharon Bowman’s awesome, awesome book, Training from the Back of the Room, and one of the six trumps that is relevant regarding font selection for class material is below:

Different trumps the same

I have been mixing up fonts in my handouts because I felt if I used a standard font, it would be sightly inconsistent with the classroom experience I am trying to create. In all my classes, I work to create a learning environment where peers are sharing experiences with another and interacting with the material. The variety of fonts on a page were just another manifestation of my training philosophy. Glad to hear it actually helps with retention.

Review of Scrum Training on Nov 10th

Carlton — Tue, 16 Nov 2010 13:34:29 +0000

Last week, I conducted a one-day Scrum training in Irvine with Conscires. The class was completely sold out and a great deal of fun. Catherine Augustin wrote up an awesome review of the class. Don’t worry if you missed out on all the fun – we are holding another class in January.

Reading a Release Burndown Chart

Carlton — Mon, 08 Nov 2010 22:59:18 +0000

In Scrum, we use a lot of easy-to-understand tools to communicate status. A very common tool is a burndown chart. In this diagram, I am showing a sample Release Burndown chart for a Team with eight Sprints in their release and will talk about how this is commonly used on a Scrum Team. At the start of the release, the Team estimated 130 units of work would be delivered in eight Sprints. At the end of Sprint #1, they delivered twelve units of work (the green bar) and 118 units remained (the red bar). As the release progressed, a little more of the Product Backlog was delivered by the Team in the next two Sprints.

In Sprint #4, the scope of the release increased by thirteen units (the yellow bar) and the Team only completed three units of added functionality. In the figure, one can see the velocity of the Team increased during Sprints #5 and #6, completing twenty and twenty-one units of work, respectively.

At the end of Sprint #6, it was clear the scope of the release was too large for the Team to complete before the deadline. The Team’s velocity of twenty-one units per Sprint and the concept of yesterday’s weather, indicated the Team would not burndown all the remaining work before the end of Sprint #8. As a result of this data, twenty-five units of low business value Product Backlog items were dropped, or descoped, from the release by the Product Owner. When Sprint #8 was completed, nine units of work remained, but it had marginal business value.

Scrum Gathering Amsterdam – Nov 15th to Nov 17th

Carlton — Mon, 01 Nov 2010 14:38:36 +0000

If you are looking for me in November, you can find me in Amsterdam! I will be attending the Scrum Gathering and will be leading two really interesting sessions.

Powerful Questions: picking the right question or reframing an issue can introduce a profound shift in the conversation. In this hands-on workshop, we will discuss how to create your own powerful questions and practice this skill. Leave with a practical tool you can use with your Teams today.
Removing Impediments with Drawings: pictures convey ideas more clearly and have a greater impact than a simple conversation. In this hands-on workshop based on Dan Roam’s book, The Back of the Napkin, we will learn the six types of diagrams used in business and how select the right picture for your problem. Come ready to draw diagrams that will create a shift in how you visualize your impediments and help remove them from your organization.