Part 2: The Agile “iterative” cycles

Here is where the fun starts. Now we get into the meat of the #agileforteams process. First I’ll introduce the various loops, or iterative constructs. Next I’ll introduce you to some theory which will underpin everything in this section: the principle of #smallbatches. Then I want you to meet my best friend in Agile: Pivotal Tracker. Finally we’ll cover, in depth, each step of the Feature Lifecycle, supported by Tracker, in a practical way so that you can use this section as a reference when (not if) you start your journey with your team.

Loops, feedback and getting up to speed

Agile is a human-centric process. This means that we acknowledge that we’re people working with other people. It’s not like machines working together primarily - if it were, it would be so much easier. If you’re anything like me, you know it’s much easier to get machines to communicate. People on the other hand, are a whole different level of crazy. Conversely, using the principles of agile, we do to some degree want to automate our working style like a machine. More succinctly, we want to become like a production line. A production line scales manufacture of its product by performing the same actions repeatedly, consistently and at speed while minimising waste. In agile we want these things too.

If we can punch out features consistently then we have something we can measure, track and use for forward projection. If we can make our steps simple and easy, then we can make them repeatable and fast. Where an element becomes painful (eg. updating the “hours remaining” each day), we can identify it quickly because we do it so often. Then we kill it or automate it, thus eliminating or minimising the cost. In this way, we receive feedback at a pace proportional to the duration of the cycle.

The cost of a defective or inefficient element (eg. having to create a Pull Request for even the smallest changes) is proportional to the duration of the cycle too, because we discover it and reduce it faster if we cycle faster. It’s critical then, that we create small loops so that lost effort goes unnoticed for as short a time as possible. Just like a bug in code, I don’t want to know about it next week. I wanted to know yesterday!

When a given cycle or feedback loop matures (that is, it grows, with integrated feedback changes that make it more stable) we can then begin to see it speed up. Now, contrary to some popular management theory, it can’t accelerate indefinitely - these are still people underneath. But what you will find is that over time, the speed naturally increases and you find a rhythm or a pace that is largely free from waste and can be maintained over a long time.
Q. Why might you want this?
A. Predictability.

So what are these “loops” then?

In #agileforteams we subscribe to three main loops or cycles.

The Build Cycle lives within the Feature Cycle which lives within the Iteration Cycle.

On the outside (the biggest loop) we have the Iteration. In Scrum, this is called the Sprint. Iteration is a more generic agile term so I’ll use that. The Iteration is the duration over which the team measures delivery to produce a metric that represents their capacity to deliver. This will become clearer later.

Inside the Iteration, we have the Feature Cycle. That is, during a single Iteration we start and deliver many Features. Ideally a feature should be something a pair or single developer can deliver in a single day. But in practice, they range from a few hours to a few days. The team should strive to ensure that a Feature doesn’t exceed the length of the Iteration.

Finally, within the Feature, we have a Build Cycle. That is, once the building of the feature commences, we expect that we show or “release” parts of the Feature to the Product Owner (defined shortly) at least once before completing it. This cycle doesn’t have to loop more than once or twice, but sometimes it does if it’s a big feature. The aim here is the same as before - collecting and integrating feedback as early as possible to avoid heading down the wrong direction which is just another name for waste.

If you’ve used a variation of these techniques before you’ll probably see a peculiarity emerging. If an Iteration is say 1 week, and an median Feature is about 1-2 days, and inside that you’re “releasing” something multiple times, then each Feature is going to be pretty small, right? And you’re going to be deploying pretty frequently as well right? Great observation! This brings us to our next section and perhaps the most critical thing you’ll learn about in this ebook, and about agile in general: #smallbatches.