Agile

Have you ever wondered what the term agile really means? Here’s what it’s all about.

The Problem

For decades, most software projects followed a model called waterfall, which calls for making lots of decisions up front and sticking to that original plan until the work is done.

Waterfall isn’t designed to handle new or changing requirements very well. And that’s a big problem, since business needs and priorities change all the time. As a result, waterfall projects are often delivered behind schedule, over budget, or both.

Agile: A Better Way

In response to this flawed approach, a new process called agile was developed, starting with the publication of the Agile Manifesto in 2001.

The agile methodology aims to:

Deliver valuable work
early and often
while welcoming new requirements

In other words, an agile team:

  1. Focuses on the needs of the customer above all else;
  2. Makes incremental progress and frequently confirms that they’re on the right track; and
  3. Addresses the inevitable changes that come up instead of adhering to a rigid plan.

“What Would You Say You Do Here?”

Here’s where I come in.

As a Certified Scrum Master at Comcast, I’m responsible for ensuring that our software engineering teams follow the agile process in a reasonably consistent way. I assist our teams with any obstacles they encounter in their daily work, such as vague requirements or conflicting priorities among business requests.

I also lead a series of recurring agile meetings for our teams. As a former Web developer, I know all too well that frequent, poorly organized meetings can disrupt a software development team’s focus and productivity. With that in mind, I keep our in-person discussions to a minimum and run them as efficiently as possible.

In fact, unlike most meetings, which lack a clear agenda and accomplish very little, each of our recurring meetings is intended to yield a specific benefit.

Benefits of Agile

Over the past six years, I’ve seen the agile process lead to some impressive results. That’s largely because agile is rooted in real-world best practices and common sense:

1. Short cycles and limited scope

An agile team schedules its work in defined periods of time called sprints, which last a few weeks each. (My current teams at Comcast work in two-week sprints; see the table below for our recurring schedule.) Prior to each sprint, the team’s collective work is broken down into small, manageable pieces called user stories, which are business requests written in non-technical wording that describe what needs to be done.

Sprint Schedule
Day Meeting(s)
1 Sprint planning
(select set of user stories
for the new sprint)
2 Daily scrum
(review team progress
and identify blockers)
3 Daily scrum
8 Daily scrum
9 Daily scrum
10 Sprint review
(demonstrate work to
product owner)

Sprint retrospective
(discuss positives and
negatives of past sprint)

2. Realistic goals

At the beginning of each sprint, during a meeting called sprint planning, an agile team agrees to work on a specific set of prioritized user stories. The team members estimate what they can reasonably finish during the sprint based on their previous performance (a metric called velocity) and their upcoming availability (which accounts for holidays, scheduled time off, and other time constraints).

3. Mutual respect

An agile team is cross-functional, meaning that people in different roles—developers, QA analysts, designers, and so on—work toward a common goal and build trust with each other. The team members discuss their recent progress and identify any blockers to their work during a 15-minute meeting called the daily scrum, which is facilitated by the team’s scrum master.

4. A sense of accomplishment

On the last day of a sprint, the team gathers for a sprint demo. During this meeting, the team presents their most recently completed features to product owner, a proxy for the customer who decides whether to accept the work as a potential release to production. Even small pieces of completed work during each sprint can help to build momentum and improve the team’s morale.

5. Continuous improvement

Immediately following a sprint demo and before the next sprint begins, the team meets once more to conduct a sprint retrospective. During this final meeting of the cycle, the scrum master facilitates a group discussion about the previous sprint. The team makes observations about things that worked well and those that didn’t go as well, and collectively agrees on one or two tactical action items to address during the subsequent sprint.

Want to learn more? Feel free to contact me with questions.