Week 1.10: Agile Development Overview

I wanted to give an overview of the Agile Development process I was trained in whilst working for Symbian Software. Because of the size of the organisation, this is more of an Enterprise Agile implementation but scales very well right down to a single team of 1.

This is the first in a series of posts I’m planning to write that will lay down the whole process.

As the next image shows, Agile Development is driven from the product’s roadmap. I should point out here that a product roadmap typically consists of two distinct regions:

• The ‘strategic’ part of the roadmap sets the longterm direction of the product. It will typically start from around 12 to 18 months out and may extend into 3, 5 or even 10 years.
• The ‘tactical’ section of the roadmap is concerned with the immediate to near future, starting from a couple of months time and extending out to 6 to 18 months. The tactical roadmap pulls items from near end of the strategic roadmap for early release planning and subsequent implementation.

Roadmap items are too big and complex to be worked on directly. Instead they are broken down into smaller chunks that are far more digestible and therefore easier for the development team to work with. The output of this phase is to put these work items onto a big ‘to do’ list, commonly referred to as the ‘product backlog’ or just ‘backlog’ for short.

During the main development phase, the team takes items from the backlog and loads them into ‘sprints’ — short, timeboxed periods where the team will actively work on them.

The goal is to complete all the work in the sprint and push the code into main code base by the time it ends. It is therefore very important to break the backlog items down into manageable chunks of work. We’ll look at how to do this in a later post.

Agile, combined with a good code line management strategy, means the main branch (aka ‘Master Code Line’ or MCL for short) is always at or very near product quality. This is checked through testing and peer review prior to committing and then automatically with an automated build and test system that runs on the MCL and main development branch. Build breaks and test failures are found quickly and the appropriate teams notified thus maintaining the integrity of the code on these branches.

As mentioned before, sprints are short timeboxes that form the unit of execution for the project. They are highly iterative in nature and run to a regular heartbeat. As such, each one has a defined start date and finish date which means they have a fixed duration. Most Agile teams I’ve worked with tend to run on a 2-week heartbeat but I’m working with one team at the moment, my hardware team, that have chosen to use 1-week. It works very well for them.

As the size of the team is also fixed, each sprint has a known bandwidth. We’ll come onto this more in a later post when we look at planning in more detail but knowing our bandwidth, the amount of work the team can deliver in the sprint, help both with planning and predictability.

The next diagram gives a very quick overview to planning and running a sprint.

Before the sprint begins it is ‘loaded’ with items (stories) from the product backlog. Each sprint has its own backlog that contains only the items the team is committing to deliver during that sprint.

When the sprint has started, the it’s backlog is locked to prevent changes and the team begins working on the stories.

Changes to the plan are recorded as scope churn and need to be managed and agreed by the team in conjunction with the Product Owner — the person who owns the product backlog, oversees each sprint and to whom the team make their sprint commitment to.

Both of my sprint teams are measured on their predictability, their ability to deliver the work they commit to at the start of the sprint. We also track scope churn to measure incoming disruption.

Lastly, Agile is only as good as the team’s ability to plan. Failure to plan leads to very low predictability, products never completing on time but the team is maxed out with work: the engine is revving high but it’s going nowhere fast.

To resolve this, the sprint teams starts planning the next sprint whilst they’re working on the current one. Forward planning in this way let’s them adapt to incoming requests, changes with product requirements and build on the results of earlier sprints. In many ways it’s like a marching army.

Conclusion

I really enjoy this model of working. It’s based on the same process we rolled out when I was working at Symbian Software. After an initial pilot to tune the process we moved our entire development resource over to Agile in the space of about a month.

My business was run in this way too and I found it particularly useful to balance client work (working IN the business) with building the business (working ON the business). Because of the need for forward planning it helped smooth the feast:famine cycle so prevalent in small businesses to a more continuous revenue stream.

When I joined my current employer back in April 2018, I was asked to roll out Agile to the development team. By the end of May we started our first sprint and have been running Agile ever since.

The benefit was enormous. We started a group of siloed individuals, each working on what they wanted to with no thought about scope, priority or release dates. In fact, the software team hadn’t made a release in over two years!

Rolling out Agile transformed them into a team. Visibility went up. They started talking to one another, even helping each other out. We defined and agreed the scope of the next release which was made 12 months later.

Perhaps the biggest success was on our newest product, a £1.5m development project, part funded by Innovate UK. At the time of the project kick off in June 2019 we set and agreed a milestone for the first software release of 22nd November that year. We hit that date on the nose, fully tested, complete with test spec., user manual and installer. To prove this wasn’t a fluke we repeated it 3 months later for the next release.

List of Images

Figure 1. THORN, 2018 Working With Agile — Overview

Figure 2. THORN, 2018 What is a sprint? — Agile

Figure 3. THORN, 2018 How does a sprint work? — Agile

Figure 4. THORN, 2018 Sprint Planning — Agile

References