year one of agile in weblion

We adopted Agile in WebLion in January 2011, using Agile Software Development with Scrum as our first guide.

before agile

Before making this change, we were highly collaborative in our own way. But we lacked the structured cohesiveness that Agile brings. We had no systematic process for vetting one another's work, no way of identifying when a task was truly done. And—I don't like admitting this—we worked alone or in pairs way too much.

agile resources in the webLion wiki: http://socuteurl.com/freshykissymidgypiggy

Add to this all of our projects. These varied enough in nature and complexity to make it difficult to distinguish priorities, dependencies, and monsters that might bite.

Our self-taught foray into Agile served us pretty well. We were getting better at requirements collecting, time estimation, sorting out dependencies... But the big change came in August 2011, when we took a NetObjectives course on Lean-Agile with Scrum. Today, we are more Lean than Scrum, but we've benefited from both disciplines.

roles

We're a small group with a handful of developers, so the work overlaps somewhat. Everyone has a voice in planning, evaluating tools and the environment, collecting and clarifying requirements. Nevertheless, clear ownership of the following roles helps to keep our projects on track:

• The Product Champion serves as the liaison between the customer and the team, clarifying requirements, updating on progress, managing expectations.
• The Technical Lead is responsible for the vision of our technical environment and capabilities, removing technical impediments, insuring that we have the tools to get our work done.
• The Scrum Master acts as the servant-leader, removing blockers; keeping the team focused, positive, and thinking creatively; challenging the team when necessary; addressing issues openly; leading planning sessions and retrospectives.
• The Development Team takes ownership of the work to be done, sticking to the concept of the Minimum Marketable Feature—delivering what the customer expects during the iteration with no gilding, no tassels, no frills. Team members keep stories and their tasks moving toward resolution, ask questions when uncertainty sets in, assist one another in removing blockers, help to maintain transparency.

organizing the work: minimum marketable features

When a new project comes down the pike, we sort its components into Minimum Marketable Features. 

Feature = Functionality = Value to the Customer

Features live in the Product Backlog—think of this as the long-term, big-picture to-do list. They are translated into a collection of Stories, each of which represents work that can be accomplished during a two-week Iteration. These Stories are tracked during an Iteration and ultimately resolved by the time the Iteration is done.

Each Story has the following:

• A list of Tasks that need to be done to resolve the story
• Exit Criteria that makes it clear what has to happen before the work is considered done.

Here's an example of a Feature living in WebLion's Product Backlog, with a sample Story and the Story's Tasks and Exit Criteria:

Feature: FacultyStaffDirectory extender product for [Customer]

User Story: [Customer] needs a FacultyStaffDirectory extender product so that 'Selected Publications' can be displayed in personnel profiles

Tasks:

Build extender product using x instructions
Add display template to [Customer]'s theme product

Exit Criteria:

[Customer] verifies that functionality meets needs
Extender and theme products pass automated tests
Extender and theme products pass code review

organizing the work: defects

Defects also live in the Product Backlog, the goal being to keep these to a minimum, since fixing bugs burns up time and gives nothing to the value stream. Each Defect has a minimum of three Stories: One for reproducing the error, one (or more) for fixing the bug; and one (or more) for deploying the fix.

Using the FacultyStaffDirectory product again, here is an example of how we organize Defects:

Defect: A-to-Z and textual listing fails on department objects outside FSD container

User Story: WebLion needs to reproduce A-Z/textual listing errors

Tasks:

List of Tasks would go here.

Exit Criteria:

List of Exit Criteria would go here.

User Story: WebLion needs to fix A-Z/textual listing bug

Tasks:

List of Tasks would go here.

Exit Criteria:

List of Exit Criteria would go here.

Deployment Story: WebLion needs to release FSD 3.1.1

Tasks:

List of Tasks would go here.

Exit Criteria:

List of Exit Criteria would go here.

iteration planning

At the beginning of each Iteration planning session, we put the previous Iteration to bed and get FogBugz ready for the next one:

1. Create a new Iteration milestone in FogBugz.
2. Close all resolved stories in the current Iteration backlog.
3. Move remaining open stories to the new Iteration milestone.
4. Close all resolved Features, Defects in Product Backlog.

Next, we deal with any new Features or Defects in the product backlog:

1. Prioritize new Features, Defects
2. Compose Stories 
3. Estimate Story points (1 Story Point = 4 hours of 1 person's work)

When we have dealt with new items in the Product Backlog, we adjust the priority of existing Features and Defects. Reasons to move an item to a higher priority might include the following:

• Value has increased (example: We find that completing x would benefit several other customers as well as the one who requested it.)
• Item has become critical (example: A minor defect turns out to be more of a pain than we originally thought)
• Item has become "hot," i.e., demand has escalated
• A deadline is identified for an item
• Stories from a Defect or Feature are needed to balance out the workload in an Iteration
• An item has become a blocker to getting other work done

Once we have updated priorities in the Product Backlog, about 48 Story points worth of items under Priority 1 get moved to the current Iteration—which is about how many Story points our team is capable of resolving inside 2 weeks.

When we have a new set of stories in the Iteration Backlog, we move them to the FogBugz Kanban board. Developers self-assign Stories, and the Stories begin their progresss across the Kanban board to verification. Team members verify one another's work. Once a Story is completely verified, the Scrum Master resolves it and moves it to the Completed column.

iteration retrospectives

We find that the method James Shore has written about for retrospectives is the most useful for our team. At the beginning of the retrospective, each team member talks about and writes on post-it notes the following:

• What was...
  ...enjoyable
  ...frustrating
  ... confusing
• What do we want...
  ...more of
  ...less of
  ...to keep the same
• New ideas (we have customized the process and added this one to the list)

We then engage in (mostly) silent affinity mapping, grouping related post-it notes. We agree on labels for each group, e.g., "Goal Setting," or "Better Verification Criteria,"  and then vote on a single group that we feel is the most salient at the time.

Within that group, we vote on a single post-it note. The issue on that post-it note gets translated into the Retrospective Objective. It lives as a Feature in our Product Backlog, and at least one of its Stories gets assigned to the upcoming Iteration.

The point is that the Retrospective is not a post-mortem; but rather, it is about identifying what we can start improving upon immediately. Along with spurring continuous improvement, this has been good for the team's momentum and morale.

what we've learned

Prioritizing the iteration backlog doesn't necessarily work. If everyone on our team had exactly the same skill set, we would be able to dispatch Stories in order of priority. In reality, it works best to self-assign according to what we can do. 

Time-boxing doesn't necessarily work. To date, our goal has been to complete x number of story points during a 2-week iteration. On a small development-and-support team, even relatively minor disruptions—surprise meetings, support requests, somebody out with the flu for a couple of days—can quickly kill the velocity. This can make time boxing somewhat meaningless.

On the other hand, time-boxing provides needed structure. As problematic as time-boxing has proven, I'm not convinced to abandon it just yet. Even if we do not complete all Story points within an Iteration, it is still motivating to have the goal, and it provides some useful measurement points.

Iteration planning can take a long time. This gets tedious if the whole team is involved in every aspect of planning, so the Product Champion and Scrum Master have taken on many of the housekeeping details.

Stories must be small. Small enough so that they can be completed during one Iteration. Overlarge Stories lead to Kanban Constipation; they sit in the In Progress column, blocking other stories from progressing, sometimes lingering Iteration after Iteration. They're a drag on the team's productivity and psyche. 

Adapt Agile to work with your organization. Pure scrum doesn't work for us because we're not strictly a development team. Pure lean is too open-ended; it doesn't provide us with enough structure. We're customizing Agile to meet our needs. And so should you.