Thoughts

When you're up to your ass in alligators ...

2012-03-05T00:46:23Z

Most teams use some sort of defect management tool which allows them (and other interested parties) to record defects along with meta-data about the defect such as severity and priority. Severity is usually an objective value but priority is subjective. For instance, severity is usually defined in terms like 'High - Results in crash or data loss', 'Medium - Work around available', or 'Low - Cosmetic' etc. High severity defects are sometimes low priority and sometimes low severity defects are high priority. For instance, the misspelling of a company name may be low severity but high priority while an application crash generated from a situation that is unlikely to be encountered by the customer may be low priority due to a cost/benefit assessment. Team members can assign severity but usually only a Product Owner is responsible for assessing the value of addressing (or not) a defect. This is because usually those people who are responsible for fixing defects are the same as those responsible for adding value via new functionality. Product Owners need to be able to prioritize the value of fixing a defect against adding new functionality.

When your team is faced with 'draining the swamp' of legacy defects, they must face the need for effective defect prioritization. The first step in addressing this issue is assessing whether the 'defects' are indeed defects (functionality that does not behave as previously agreed upon by all involved parties) or enhancements (behaviour that has not yet been designed/implemented/tested). In my view, if the team did not agree that some behaviour was expected, designed, implemented and tested, the behaviour is an enhancement to the current functionality. Once the enhancements have been distinguished from the true defects, those enhancements can be turned into Stories and prioritized just like any other Story which adds value to the application. The remaining defects then need to be prioritized in terms of the value they prevent the application from maintaining. Something of value used to work properly and now does not do so. How important is that to the success criteria of the product and/or release?

In order to mitigate risk on a software development project, one of the principles of Scrum is that teams try to focus on delivering the next most valuable functionality while keeping the product potentially shippable. We are to work on the next most valuable functionality in order to insure that if we run out of money or time (and we will) that we have created the most value for the money and time expended. This should apply in the world of defects as well as enhancements. Often the difficulty with doing so is that the number of defects in various priority queues are so large that it is difficult to assess whether the team is working on addressing the most valuable defects at any given time. If 100 defects are denoted as High Priority but we can't address them all in one iteration, which ones shall we address to accrue the greatest value?

In most defect management tools there are usually priority choices like Must Fix, High, Medium and Low. These classifications are perhaps arbitrary in that the only important thing about them is that each is related to the other by a higher or lower value. However many 'buckets' exist, treating them as static is not an effective mechanism for executing against priority. Prioritization is a subjective exercise and usually prone to changes based on business conditions and newly reported issues from the field. To that end, the highest priority queues should constantly be being emptied by the end of any given iteration. This means that Product Owners must be vigilante about either 'promoting' defects from Medium to High and from Low to Medium (which seems like busy work) or simply limiting the highest priority bucket to a queue size that the team is likely to be able to completely address. The key here is always making it apparent to the team which defects are the most important to fix in any given iteration. Very often I see queues of 100's of High priority defects and 10's of Low priority defects. This is usually the exact reverse of what we'd like to see! We are much better at managing smaller queues … for instance queues that we can see and contemplate in their entirety.

In order to keep a product potentially shippable at the end of each iteration, some teams adopt a Task Priority list describing a working agreement about the team's default task priorities:
a) Fix any build/install issues (if we don't have a build/install, we can't test)
b) Fix any automated tests (if our tests are broken, we don't know what works and what doesn't)
c) Fix any regression defects (if we have open regression defects then we have likely regressed in value)
d) Fix any current iteration Story defects (standard practice to meet acceptance criteria)
e) Implement new Stories

a) and b) above certainly keep the product from being in a known potentially shippable state while c) keeps the product from maintaining a known value. Issues associated with d) and e) above are about adding incremental value to already valuable software. On large multi-team projects, distinguishing those issues keeping the product from being potentially shippable from issues of maintaining or adding value can help with queue size. For instance Must Fix can incorporate a) and b) while c) can be distributed across High Medium and Low priorities. Note that in this context, Must Fix is not associated with a value judgement, it is associated with a fairly common Definition of Done that teams use to help them keep a product in a known state.

Of course the best solution to the problem of how to effectively drain the swamp is to prevent the swamp from forming in the first place.

Pragmatic Moneyball

2012-03-02T15:24:11Z

So much of the premise of the movie 'Moneyball' is rooted in the concepts of successful product management leadership. Once Billy Beane has announced his need (as the General Manager of the Oakland A's) to 'adapt or die', the crux of the solution to his problems rests in discovering the REAL problem.

After losing their star players to larger contracts offered by richer teams, the scouts and coaches of the Oakland A's begin to discuss how to replace those star players using their standard, time honoured criteria. When Billy questions their methods the following conversation occurs:

"We're trying to solve the problem."
   "Not like this you're not. You're not even looking at the problem."
"We're very aware of the problem."
   "OK good, what's the problem?"
"We have to replace 3 key players."
   "Nope. What's the problem?"
"Same as it ever is, we have to replace these guys with existing players."
   "Nope, What's the problem?"
"We need 38 home runs, 120 rbis and 37 double plays to be replaced."
   "Nope. The problem we're trying to solve is that there are rich teams and there are poor teams … its an unfair game."

The remainder of the film deals with a product strategy to address the real problem at hand; competing in a league where the payrolls of teams are vastly disparate. The scouts and coaches were trying to solve the apparent symptoms of the problem but not the problem itself. The strategy Billy Beane employed is spoken by his assistant, Peter Brand:

"Baseball team owners think in terms of buying players. Your goal shouldn't be to buy players but to buy wins and in order to buy wins you need to buy runs."

This product strategy leads to a different way of thinking about what's valuable about a baseball player. Billy and Peter acquire players whose primary value lies in their ability to get on base (by walk or by hit) and therefore be more likely to score runs. They are able to ignore other negative factors about those players and as a result acquire players not attractive to the big market teams still using traditional selection criteria. This in turn allows them to field a competitive team at a fraction of the cost of their competitors' teams. While not winning the World Series that year, the Oakland A's implementation of this product strategy changed the way Major League Baseball teams managed their teams from that year forward.

Applying the Dreyfus Learning Model to Focus Your Coaching Approach.

2011-06-26T23:05:52Z

Over the past five years, Jaron Lambert (@jaronlambert) and I have helped several companies and dozens of teams transition to agile product development processes. In working with the myriad of teams and people, we've learned that the best way for us to help people learn agile principles and techniques is to use the Dreyfus Skills Acquisition Model. This model employs the usage of non-situational rules for novice practitioners. The adherence to these rules promotes the transition to an advanced stage of learning by providing the student with a foundation for recognizing patterns and principles for application in new situations. We've discovered (as the model predicts) that skipping this stage of learning can lead to problems absorbing and implementing the philosophies and principles of the agile manifesto. To that end, Jaron and I have collated a set of rules we have found useful in working with Novice teams. This is a living collation and we'd be very happy to hear what other coaches and ScrumMasters (or others) think does and does not help their teams' learning process.

Jaron and I will be speaking about the 5 stages of learning that teams traverse (not just Novice) according to the Dreyfus model as they learn agile concepts and philosophies.

Environment

Co-locate where ever possible, set up your teamʼs space for optimal teamwork.

Maximize face-to-face communication; minimize email communication within the team.

Minimize distractions. Remove or minimize anything that distracts the team from finishing the work that they committed to (i.e. completing all the Stories in the iteration plan). Inform the Program/Project Manager of any distractions that canʼt be removed directly.

Roles

The Product Manager is the “messenger of the market” and articulates why we should spend time/money on any development. Product Managers describe what the market needs in a Market Requirements Document (M.R.D) and are responsible for describing those needs in User Stories.

Product Managers set the business priority and help define acceptance criteria during iteration planning, answer questions from the team during the iteration, and accept stories before the end of the iteration.

Program/Project Managers (Scrum Masters) shepherd the process. They provide the Product Manager with all currently available information so that the Product Manager can make informed and timely decisions. Program/Project Managers answer process questions from the team.

Program/Project Managers facilitate removal of any/all roadblocks for the team, ensuring that someone on the team is responsible for any roadblock and keeping track of unresolved roadblocks.

All other team members are responsible for delivery: reliably delivering quality software solutions (i.e. implementing stories).

All other team members provide the Product Manager with solution options (alternative ways to implement solutions to stories) with associated costs.

Release Planning

Review the MRD to ensure that the entire team has an understanding of the goals of the release (i.e. Problems, the users who have them, and the situations under which they have them)

Write stories using the template: “As a {persona} I want to be able to {do something} so that {some goal is achieved}”, See “Writing Stories”, Chapter 2 from User Stories Applied by Mike Cohn.

Size all the stories in the backlog using a modified Fibonacci sequence (0,0.5,1,2,3,5,8,13,20,40,100). The size of a story represents the overall complexity, difficulty, and effort to complete the story.

Add up the story sizes to get the total story points in the release.

Backlog Grooming

Product Manager grooms the Release Backlog for their product. They keep it organized and prioritized, and add or remove stories so the Release Backlog always describes expectations for the release.

Team Members are responsible for sizing the stories in the release backlog, and breaking stories from the Product Manager into smaller stories that deliver value within an iteration (see “Twenty Ways to Split Stories”, http://xp123.com/xplor/xp0512/).

Iteration Planning

The Product Manager decides priorities for the team to work on in the next iteration. Team selects the stories they can complete within the iteration and decides how they work on the tasks during the iteration.

Only plan to work on sized stories.

Only plan to work on stories with agreed upon acceptance criteria (discuss and agree on the criteria, and document it during the planning). Team breaks each story into tasks and clearly defined acceptance criteria.

Agree on the definition of ʻdoneʼ for the team (update it whenever necessary).

Agree on ʻRules of Engagementʼ (update them whenever necessary).

Iteration/Sprint Execution

The teamʼs priority of work:

Keep the build/install working and testable (getting a brokenbuild/ install, and getting broken automated tests working, is always top priority).

Keep existing functionality working (fixing defects with functionality that worked before the current iteration is #2 priority).

Keep the functionality being built this iteration working (fixing defects on this iterationʼs stories is #3 priority)

Build out current stories (implementing new functionality is #4 priority)

Philosophies to continually keep in mind:
- The fewer stories in progress the better (3 things shippable and 2 things unstarted is better than 5 things ʻalmost doneʼ).

The fewer tasks in progress thebetter.

Donʼt work on anything unless youʼve already agreed with your team mates how it will be tested and how you will know if youʼve been successful.

Donʼt add a new story to the current iteration mid-iteration (unless every other story is complete).

Donʼt split a story mid-iteration. Teams need to consistently complete the stories they committed to and establish a velocity. While they are gaining experience doing that, they will learn better habits faster by recognizing 0 points for incomplete stories and reflecting on how to better deliver on the iteration plan.

Daily Standup

Each member of the team updates the other team members on progress against the stories they are working on:

What did you accomplish yesterday (since the last standup)?

What do you plan to accomplish today (before the next staandup)?

What is getting in your way?

What is your latest estimate of how much time is left on your current task(s)?

Only people with work assigned in the iteration should speak.
Topics outside these questions should be addressed outside the Daily Standup.

Does the plan need to change as a result of the above? If so, change it now!

If anyone doesnʼt have enough to do today, decide what they will do at the standup.

All members of the team watch for “bad smells” in their scrums, and mention any apparent infractions. All members of the team work together to remove “bad smells” from their daily scrums.

Demos

Demonstrate only what the team accomplished (i.e. Stories the Product Manager has already accepted).

Record any issues, bugs, or enhancements that come up (and assign them or add them to the backlog after the demo).

Product Manager accepts (or decides not to accept) any remaining stories.

Avoid troubleshooting, discussing solutions, brainstorming ideas, exploring functionality, or anything else that takes away from clearly demonstrating the work that was completed this iteration.

Retrospectives

What was the teamʼs velocity this iteration? Has the team established a consistent velocity? If so, what is it? If not, what is preventing the team from establishing a constant velocity?

What did we say weʼd improve / stop doing last retrospective? Did we?
Each member of the team has a chance to say (focus on the process, not the people):

What went well / what should we keep doing?

What could be improved / what should we stop doing / what is holding us back?

Team identifies the most important item(s) or issue(s) to focus on next iteration (1 or 2 items / issues is enough).

Change or add to “Rules of Engagement”?
Modify the teamʼs definition of “Done”?

Agile at the Masters

2011-04-11T02:31:00Z

Watching today's Masters Golf Tournament in Augusta, Georgia I was struck again by something I've noticed before. In the game of golf, when more than one person has the same score, the person who has completed the most holes is listed as 'ahead of' or 'above' the person or people with that same score. Evidently, while having more holes remaining is surely an opportunity to get a better score, golf aficionados know that those extra holes are more often than not an opportunity to lose a stroke. They seem to place more value on what has been accomplished for certain rather than what the potential for the future might hold.

Thoughts on 'Potentially Shippable'

2011-03-11T22:32:17Z

Scrum calls for the delivery of a 'potentially shippable' product increment at the conclusion of each iteration. The reason it is 'potentially shippable' (rather than simply 'shippable') is that ideally it should only be a pure business decision as to whether enough value has been accrued to warrant actually shipping. Therefore, the functionality that is exposed to the user works as intended based on the implemented Stories/Acceptance Criteria which in turn presumes that the quality is fit for purpose.

The value of keeping software in a 'potentially shippable' state at regular intervals is twofold: a) a real/tangible indication of progress for use in making date vs scope decisions and b) the ability to garner meaningful feedback at regular intervals.

If the software is in a 'potentially shippable' state, progress towards the end-goal is based on working, tested workflows/functionality implemented in software and not based solely on overall task estimates. If the software is in a 'potentially shippable' state, feedback from existing customers, potential customers, and internal stakeholders can be meaningful. Otherwise feedback can be, at worst, invalid, and at best confusing.

One of the goals of iterative/incremental development is to minimize the difference between 'potentially shippable' and 'shippable'. Ideally it is simply a business decision whether there is enough value to actually warrant shipping. In practicality, however, for many teams there are activities that they need to perform prior to actually releasing that they are unable to perform every iteration. In some cases, the totality of all manual, automated and performance acceptance tests possible and/or necessary to execute and analyze in order to fully assess whether a given build is 'shippable' takes on the order of weeks to months. In other cases, there is just too much legacy code which is not covered by automated testing to allow for the creation of something considered 'potentially shippable' within any given iteration.

With this in mind, teams need to be able to focus on those activities that they can accomplish inside an iteration which will best lead them to having confidence that the iteration backlog Stories work and that previously implemented workflows still function correctly. Doing so will lead to a smaller gap between 'potentially shippable' and 'shippable'. If a significant part of the cost of change in a code base is the uncertainty created by the change and our inability to validate (in a timely manner) that our workflows have not been inadvertently effected, then we should always be striving to minimize the time it takes to do that validation. Validating quicker leads to finding and fixing problems quicker and cheaper. Automate, automate, automate.

IDEALLY:

- acceptance criteria outline the circumstances under which each new workflow functions and the associated expected results
- if the acceptance criteria are met, and we have proved that the acceptance criteria for previously accepted workflows continue to be met, then we are potentially shippable.

PRACTICALLY:

- acceptance criteria for any given Story need to include regression tests for previously working functionality (either manual or some subset of long-running automated tests) which the team has assessed are likely to have been effected by the code changes necessary to complete the Story in question.

- alternatively, the Definition of Done can be altered to include a statement about the inclusion of relevant, focused regression tests which are either performed manually or are a subset of an existing long-running test automation suite.

- those manual regression tests then need to become an ongoing part of the automated test suite

The usual objection to this approach is that it means that teams apparently deliver less in an iteration. This of course is a red herring as the teams were never actually delivering as much as they thought in an iteration because the regression testing necessary to deliver functionality was hidden in the 'stabilization/hardening' period prior to release. Moving that regression testing forward moves teams closer to the ideal and should lead to shorter stabilization/hardening periods.

I'm often asked "How do we measure if we are 'potentially shippable'?" My response to this is generally the same, "You're 'potentially shippable' if the software behaves the way you say it does." Without some way to adequately describe (and ultimately test) this behaviour, it is difficult to know if you are 'potentially shippable'. This behaviour is, of course, described in stories and their respective acceptence criteria.

Spike ... Do the Right Thing. [Redux on Aug. 30 post]

2010-09-24T19:29:00Z

Doing the right thing is often context dependent. I've had occasion with my current clients to discuss the concept of Spikes and how they are treated by numerous teams. I've realized that where a team currently resides in the continuum of learning iterative/incremental development has quite an effect on how I discuss this topic. The current industry norm is to treat a Spike as a type of Story. This has been reinforced by web-based tools limiting trackable items to Stories, Tasks or Defects. I've seen novice teams struggle with this notion and here's why:

Summarily, the purpose of a Story is to describe some piece of functionality valuable to, and testable by, a customer.

The purpose of a Spike is to investigate the solution options and feasibility of addressing a particular problem space or Story.

Stories should have direct customer value as well as a size estimate (representing effort, uncertainty etc) from the team, while Spikes have no direct customer value and are generally time-boxed to no more than 2 days.

From this perspective, Spikes should not be called Stories because they violate the spirit of the principal purpose of a Story (to express something of value to a customer). I think much of the confusion on this topic stems from our desire to want to name things based on how we manage them. I think people would like to manage Spikes in the same manner they manage Stories but then assume that means the Spike should be called a type of Story.

I've seen novice teams want (naturally) to do things like give the 'Spike Story' a size and then directly equate that size to the length of the time-box. This tends to negate the value of using Story Points for sizing Stories in a backlog.

Conversely, if a team treats a Spike as a Story and gives it a size of zero, that is inconsistent with the fact that they are spending time on it. It also grates against those who look for Stories which we "get for free" (and therefore give a size of 0) as a result of some overlapping work on another Story. These are subtleties which a mature team understands but a novice team, new to Stories, can find challenging.

So how about Spikes as Tasks?

I believe Spike activities have much more in common with Tasks than Stories. However, there are inconsistencies and pitfalls here as well. If a team treats a Spike as a Task inside a relevant story for an iteration, when the Task is complete, then the relevant Story should technically be removed from the iteration and returned to the release backlog (unless it is determined that the entire story can be completed before the end of the iteration) for future prioritization along with at least some of the resultant child/replacement Stories. Depending on the the size of those resultant Stories (and the team's velocity) some of them may remain in the current iteration. If we emphasize striving for completing all stories initially planned in an iteration we end up having to make exceptions for Stories containing Spikes. Another pitfall is that when a team employs "yesterday's weather" for their next iteration, they need to ignore the size of a Story containing the Spike task. Again, these things may be easily comprehended by a mature team but perhaps are contentious for teams transitioning to Agile methods, inexperienced in the use of Stories, and looking for absolutes (and THAT is a subject for a future post!).

How about neither Story nor Task?

In my experience, Spikes are generally an extension of Backlog Grooming and as such could be considered release overhead. Spikes are generally not included as part of the release backlog but they likely result in a set of more defined Stories which may be part of the release backlog. Perhaps it would be better for some teams to simply reduce team member availability during an iteration to account for the Spike time-box? After all, we do this for things like Backlog Grooming meetings. The one drawback to this approach is that there would be no explicit/transparent way for the team to manage the time spent on the Spike activity.

So why isn't a Spike just a Spike?

While the notion of a Spike overlaps the notion of Story in that both have a goal; and the notion of a Spike overlaps the notion of a Task in that both represent an activity, I think the differences between the 3 are signficant enough to warrant maintaining/managing a separate entity - 'Spike'. This is easily accomplished on a traditional index card wall, but is usually explicitly prevented when utilizing a web-based management tool. I believe this is one of the mistakes we as a community made when we transitioned to using these tools. When we were using index cards we simply called it a Spike and off we went. We didn't have to choose to create that entity as a Story or a Task so there was less confusion.

Of course this is all just semantics ... Story, Task, Spike, Backlog Grooming ... what's the big deal? The answer to this lies in the fact that we use words to communicate intent and without some consistency in the meanings of these words, it is difficult for people new to the concepts to keep it all straight. The English language itself is full of inconsistencies and similarly, it is not until one is familiar with the patterns that one can grasp and remember the exceptions.

In the end what do we care about?

I really only care that the size of the release backlog is consistent with the team's current understanding of the backlog, and that the team's velocity actually represents the rate at which they may be able to reliably and sustainably address prioritized items in that backlog. As Spikes occur, the resultant child/replacement stories will likely affect the cumulative size of the release backlog and the product owner can make the relevant business decisions with current information.

So depending on the individual team and their circumstances, any one of the 4 options might be the right thing. If you're using a web-based tool (that limits your trackable items to Stories, Tasks and Defects) to manage your iterations and your team is relatively new to the use of Stories, consider treating Spike activities in the same way you treat other iteration overhead activities.

The Test

2010-06-22T20:43:13Z

The Agile Fortune Cookie

2010-06-02T17:36:48Z

Golf, Poker and Software

2010-04-04T15:45:28Z

The Bus

2009-10-03T22:56:41Z