So, what do I mean by "Agile?" (Part 3)

Release and Iteration Duration and Structure

Release and Iteration lengths are highly dependent upon local circumstances. But, given the ability, I prefer to do Quarterly Releases and Weekly Iterations.

Quarterly Releases

Quarterly Releases may seem like a long time. But, many businesses are incapable of absorbing change much faster than that. So, unless you’re at a web start-up or in a highly regulated industry, I say try to match your release schedule to an existing organizational heart beat, like quarterly financial reporting. (Though, perhaps you don’t want to try to release new code the same day, week, or month you release financials.)

As for the structure of a release, here’s what I like to see:

  • Twelve development iterations with one day of slack each
  • One review, deployment and planning iteration

Alternatively, I could also support a structure that looked more like this:

  • Three development iterations
  • One slack iteration
  • Three development iterations
  • One slack iteration
  • Three development iterations
  • One slack iteration
  • One review, deployment and planning iteration

A development iteration is a normal iteration. The customer pick stories for the team to build, as described above. A slack day or iteration is just like a development day or iteration except that Team decides what work to take on, from exploratory testing to refactoring items on the Technical Debt Backlog, to spiking new technologies. No new stories are implemented during slack time, though new tests may be added to shore up code coverage. And, the review, deployment and planning iteration is exactly that: review the release, deploy it, and plan the next release.

Weekly Iterations

Short iterations allow for rapid customer feedback. Longer iterations allow for more work to be accomplished. In my experience, Weekly Iterations provide the best balance between getting stuff done and running off into the weeds. Plus, it has the side benefit of guaranteeing you your weekends off!

I like to see the following structure to iterations:

  • Planning happens first thing in the morning on the first day of the week.
  • Review happens on the afternoon of the last day of the week
  • The rest of the time is devoted to implementing user stories, exploratory testing, etc.
  • Except for weekends, which are reserved for personal use

So, what do I mean by "Agile?" (Part 2)

As I hinted in my previous post, planning is broken down into three levels:

  • Product Planning
  • Release Planning
  • Iteration Planning

As I am not a product planner, I will not try to discuss how that process happens. Rather, I’ll focus on the active development process through Release and Iteration Planning. First off, I like some to see symmetry between releases and iterations. The only difference is the scale at which the two types of planning occur. Specifically, I like both releases and iterations to include:

  • Planning,
  • Review, and
  • Retrospective

Here’s what I mean by each…

Planning

Each release and iteration should begin with a planning session designed to select some number of user stories from the parent backlog for inclusion in the current cycle of the process. For example, during Release Planning, user stories are selected from the Product Backlog for implementation in the next Release.

Review

Each release and review should end with a review meeting wherein the Product Owner (and other stakeholders) is shown the running acceptance tests and asked to approve or reject them. If an item is approved, it becomes part of the next release. If it is rejected, it is placed into the backlog for the next iteration (or release, potentially). These meetings are also often the source of additional user stories for the backlog. For example, the Product Owner may accept a user story as it is, but desire that something about it change in the next iteration before accepting the feature in the release review.

Retrospective

At the end of each iteration and release, after the review meeting, the whole team should get together to discuss process improvement. Some teams do this without the Product Owner. I recommend including them, as their perspectives are valuable and it serves to reinforce the concept of the “Whole Team.”

Next up: Release and Iteration Duration and Structure

So, what do I mean by "Agile?" (Part 1)

Since you’re reading my blog, I’ll assume that you’re either a relative, or you’re already somewhat knowledgable about agile software development. So, let’s jump right in... (Sorry, Aunt Gina.)

Given my drothers, I prefer to mix and match terminology and practices from Scrum and Extreme Programming. Here’s what I like to do:

Roles & Responsibilities

Product Owner is responsible for: 

  • Defining and/or collecting the set of features to be implemented in the product
  • Maintaining a Product Backlog of User Stories ordered by Business Value
  • Presenting user stories to the Team during Release Planning
  • Selecting user stories to place on the Release Backlog
  • Presenting user stories to the team in more detail during Iteration Planning
  • Selecting user stories to place on the Iteration Backlog
  • Accepting or rejecting user story implementations during Iteration Review
  • Presenting implemented user stories to other stakeholders during Release Review
  • Determining whether or not to deploy software during Release Review
  • Answering questions from the Team throughout the process

The cross-functional Development Team (or Team) is responsible for:

  • Estimating stories with T-shirt Sizes during Release Planning
  • Estimating stories with Story Points during Iteration Planning
  • Splitting large (epic) stories into smaller, more manageable stories 
  • Calculating their team velocity using Yesterday’s Weather 
  • Incremental Design and Test-First Programming of user stories
  • Maintaining a backlog of Technical Debt
  • Maintaining code and test quality with Refactoring
  • Presenting implemented user stories to Product Owner during Iteration Review
  • Assisting Product Owner with presentation of implemented user stories at Release Review
  • Asking questions of the Product Owner throughout the process

Coach (or Scrum Master) is responsible for: 

  • Identifying and resolving roadblocks hindering the Team, including, process, technical and managerial issues, and more.

The Whole Team, which includes the Product Owner, Development Team and Coach, is responsible for:

  • Conducting Release and Iteration Planning meetings
  • Conducting Iteration and Release Review meetings
  • Conducting Iteration and Release Retrospective

Next up: Release & Iteration Duration and Structure

More pictures from p&p

While I was with patterns & practices, Microsoft invested a considerable sum of money to build the team a custom space that that lent itself to agile software development. My friend Darrell Snow was largely responsible for securing the project and shepherding it through the 40 some odd cooks who want to put their fingers in the stew. Overall, it turned out amazingly well - though the team spaces could be a bit bigger, IMHO. Even so, I really miss working in that space.

Most of the photographs below were all taken shortly after the team moved into the space. For context, the first picture shows what our team room looked like before the new space and the second picture is a floor plan of the new space.

Some people doodle…

I think up silly tag lines for things. Here are a few of my favorite tag lines for Code Gardener:

  • That’s a big ball of mud!
  • Better get your Wellies
  • Have Wellies will travel
  • Get your hands dirty
  • Roll up your sleeves

But, the one I’m currently using is still my favorite: Weed & feed your software.

Nostalgia

While trying to figure out how to SEO this new site, today, I ran across a few pictures from my time at Microsoft. It brought back some fond memories. One thing I've got to say for that company that you don't often hear is that their facilities are amazing - especially the p&p offices and the conference center where these shots were taken.

Business Cards

Code Gardener Business Cards After coming up with the new logo for Code Gardener, I thought it'd be fun to get some business cards made up. So, I downloaded a free trial of Adobe Illustrator (which I now know that I truly need - there goes $600!) and created a card based on the same design. I'm not completely happy with the placement of the text. But, it's a good first draft.

I'm having moo.com print them right now. Click that link and buy something! I'll earn referral points that I can put toward my next order. Go ahead! Give it a try!

New digs…

So, I got tired of fighting WordPress and spending money to host it. I wanted something a bit simpler that would let me focus on writing. So, I’ve moved CodeGardener.com to Posterous, and refreshed the look considerably.

I’m still not done with the redesign. The links in the navigation pane aren’t all working yet. And, I need to work on the other views (search, tags, etc.) But, the general look and feel is pretty much complete.

Overall, the process has been pretty smooth. It was refreshingly simple compared to WordPress. Though, Posterous has a nastly little habit of applying styles to your content without your knowledge. As I discover ones I don’t like (e.g. the large-quote, medium-quote, small-quote nonsense), I’ll stomp on them with some CSS of my own.

Best of all, I’m sending this post via email, which is exactly what I wanted. Hopefully, I won’t have to spend several minutes fixing it once it hits the web.

UPDATE: Raw email didn’t handle paragraphs the way I wanted. Let’s try using Markdown.

UPDATE 2: Markdown works great! Might even want to go back and implement it more broadly throughout the site, since it’s so much easier to read than HTML.