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

The Transformation Priority Premise

I just read the most brilliant new idea that I’ve seen since I learned TDD and Refactoring ten years ago. Naturally, it comes from the brain of Uncle Bob Martin. It’s called “The Transformation Priority Premise.” I’ll describe it briefly here. But, if you want to really understand it, you should go read Uncle Bob’s blog yourself:

Ok… So, what is the Transformation Priority Premise?

If you are familiar with Test Driven Development, you know the phrase “red, green, refactor.” That phrase encapsulates the process of writing tests before you write the code:

  • Red = Write a failing test and watch it fail.
  • Green = Write just enough code to make the test pass.
  • Refactor = Remove any duplication in the code without changing it’s behavior (all tests should still pass).

And, if you’re familiar with Martin Fowler’s book “Refactoring,” you know that a refactoring is a simple change to the structure of the code that is guaranteed not to change the behavior of the code. These are things like:

  • Introduce Variable – Replaces a constant with a variable.
  • Extract Method – Extracts one of more lines of code from one method into another (new) method.
  • Rename – Renames a variable, method or class.

These changes are so easy to implement that we can actually build tools that do them for us. Visual Studio comes with a handful of built-in refactorings. ReSharper adds significantly to that list.

What Uncle Bob is proposing is that there are similarly simple “Transformations” that change the behavior of a code base. Furthermore, he states that there is an order or priority in which we should apply these transformations – from simple to complex. He proposes the following (admittedly incomplete and probably mis-ordered) list:

  • [] –> nil
  • nil –> constant
  • constant –> constant+
  • constant –> scalar
  • statement –> statements
  • unconditional –> if
  • scalar –> array
  • array –> container
  • statements –> recursion
  • if –> while
  • expression –> function
  • variable –> assignment

Don’t worry if that doesn’t make any sense. I really just blogged it so I’ll have a quick reference. But, what’s cool about them is that they can actually help us pick which tests we should write in what order. For example, if we decide to write a test that requires us to add an if statement to our code, that test requires the “unconditional –> if” transformation. Knowing that, we can try to think of other tests that rely solely on transformations higher up the list.

The ultimate reward is that by writing our tests using transformation priority order, we should not ever get to a point where one test causes us to rewrite an entire method. Furthermore, because these transformations are all relatively simple in and of themselves, smart tools vendors may be able to build support for them directly into tools like ReSharper.

I’ve probably just confused the heck out of you with all this. Suffice to say that Uncle Bob’s posts are excellent. They include source code that he uses to show you how not using the priority order causes pain, and how using the priority order resolves that pain.

What are you waiting for? Go read those posts!

(Oh, and for those of you unfamiliar with Uncle Bob’s work, he references something called a Kata several times. The term comes from martial arts. It refers to a movement that is practiced over and over and over until it becomes second nature. Think “wax on, wax off”. Uncle Bob is a big fan of solving the same problems over and over and over to gain new insights into the potential solutions. And, he’s published several Katas ranging from calculating a bowling score to identifying prime factors of an integer. They’re worth your time, too.)

Coding Standards

One of the original practices of Extreme Programming was coding standards. Back in 2000, when I read my first XP book, I tensed up a bit at the thought of having to make my code look like everyone else’s. But, over the years, I’ve come to see the wisdom of it: once all the code follows the same standard, it becomes much easier to read.

In fact, now a days, I often reformat a block of code to meet a coding standard before I try to figure out what it’s doing. (But, only when I have strong unit tests!) Long story short, I haven’t had a good knock-down-drag-out argument about curly braces in nearly ten years! (Anyone want to have one for old time’s sake?)

With that in mind, I needed to look up Microsoft’s latest guidelines for .NET class libraries, today. Specifically, I knew they said something about using abbreviations and acronyms when naming things. But, I couldn’t remember exactly what the recommendation was. So, I looked it up. Turns out, Microsoft has done a rather nice job of structuring their design guidance on the web.

It’s not something you’ll need to refer to everyday. But, it’s good to know it’s out there…

http://msdn.microsoft.com/en-us/library/czefa0ke(v=VS.71).aspx

An Agile Approach to Mission Control

NASA’s Cassini spacecraft has been studying Saturn, it’s rings and moons for nearly six years, despite the original mission being slated to expire after only four years. But, due to better than expected performance and lower than expected fuel consumption, NASA has extended the mission for an additional seven years, to 2017.

In order to negotiate the flight path for the next seven years, the engineers in charge of planning the orbital maneuvers consulted with the five science teams affiliated with the project. Each team is assigned to study different things: Saturn, Titan (Saturn’s largest moon), the rings, the icy satellites, and the magnetosphere. Each team presented their wish list for the places they’d like to see over the next seven years, and the engineers got busy running the numbers:

The first time [the engineers] met with the discipline teams, they offered three possible tours. The next time, they offered two, and, in January 2009, the scientists picked one of them. Last July, after six months of tweaking by [the engineers], the final “reference trajectory” was delivered. It now includes 56 passes over Titan, 155 orbits of Saturn in different inclinations, 12 flybys of Enceladus, 5 flybys of other large moons — and final destruction.*

In essence, this team of engineers had to balance the wishes of the five research teams with the remaining fuel and gravity boosts available. The approach they took was to present alternatives and iterate on them until they found the best solution, given the requirements and the constraints:

“It’s not like any problem set you get in college, because you have so many factors pulling in different directions,” Mr. Seal said. “The best way to measure it is to look at how much better the next iteration is than the previous one” until “you’re only making slight improvements.” Then you stop.*

I can’t think of a better way to describe the iterative development process espoused by most agile software development methodologies, including Scrum and XP. You know when to stop when the remaining improvements are no longer worth the investment.

I wonder how many of our customers would like to see three options, then two, then one…

* http://www.nytimes.com/2010/04/20/science/space/20cassini.html