The Why of Agile
As of 2019, more than 80 percent of software development projects are reportedly using an agile approach. Software industry reports also indicate the majority of software projects are considered "failures" by their sponsors. Clearly, agile alone is not a magic bullet.
So what makes WWT's agile teams able to deliver successfully when others do not?
To answer this question, let's first take a look at what agile really is.
Agile basics
Agile is not a process or a set of practices. Agile is not Test-Driven Development (TDD) or pair programming, team stand-ups or retrospectives. Agile is a set of four values and twelve principles used to guide decision-making throughout the project life cycle, also known as the Agile Manifesto.
To help teams apply the values and principles in the Agile Manifesto in a tactical way, software development frameworks like Scrum and Kanban were born. The most common of these frameworks is Scrum, with more than 90 percent of all agile teams around the world reportedly using some aspects of the practice.
Product owner
Regardless of framework applied, an agile project begins with a product or project vision. The person in the role of product owner controls this vision, and their primary responsibilities include communicating the vision to the software team, prioritizing the team's backlog of work, and approving completed work.
The most important responsibility of a product owner is prioritization, also known as saying "no" to work that does not truly serve the vision. This means a product owner needs to evangelize their vision with stakeholders and continually justify why they say "no" to some requests and "yes" to others. If the product owner fails to do a good job of listening to stakeholders and explaining their decision making, the project is at risk of losing stakeholder support and the team is at risk of building the wrong thing. That's why there should only be one person in the product owner role. Multiple product owners can cause confusion for the team when a clear decision is needed and there is no one person to provide it.
Product backlog
With a product vision and a strong product owner, the next thing an agile team needs is a product backlog. The Product Owner works with stakeholders to develop a roadmap, which is broken down into what are commonly known as epics, features and user stories.
The first "big rock" on a roadmap is broken down into small, vertically-sliced user stories the team can work on independently (i.e., small increments of valuable software that go all the way from front end UI to back end business logic and data). The fact that these product backlog items are vertically sliced is critical to keeping the software in a working, deployable state. This way, the product owner can choose to pivot the team to other features at any time, thereby keeping the competitive advantage of being hyper-responsive to user feedback. I'll discuss this aspect of agile software delivery in greater detail later.
To keep the backlog healthy, the product owner and team need to meet regularly to review the product backlog, refine user stories, write acceptance criteria for user stories and agree on what "done" means for that story. By performing regular product backlog refinement, the agile team always has a backlog of work broken down at an appropriate level to keep the team delivering at a sustainable pace. So when the team goes into their planning meetings to determine what shippable increments of work they can accomplish within a given timeframe, enough work is ready for them to assess and pull — and they can do so with confidence.
Stand ups and retrospectives
In addition to planning and backlog refinement, agile teams practice rigorous inspection and adaption cycles. Agile teams have a quick daily meeting ("stand up" or "daily scrum") to plan the day's work. They also end each delivery cycle with a demonstration of working software to the Product Owner, who then approves the work and provides the team with feedback or changes.
Agile teams also meet regularly to retrospect on team processes, including taking a look at key metrics and events, and looking for ways to continuously improve their processes and interactions as a team.
Why care if software is developed in an agile way?
Simply put, because it's the only way to control software investment and ensure that investment will have the right return.
Agile software delivery requires working software — software that goes from user interface all the way to services and data — delivered in small slices iteratively. In our Application Services agile teams here at WWT, we take this a step further by expecting our teams to deliver a vertical slice of valuable working software — software slices that mitigate risk, prove out hypotheses and create important feedback opportunities with our customer and users throughout the project life cycle.
The value of agile is in the control of software investment. Every one to two weeks, our teams deliver a working piece of software to a production (or prod-parity) environment, and that software can be deployed to users or further iterated upon. At any time during the project, the customer can choose to redirect their investment — and they'll still have working software they can use.
At any time during the project, the customer can choose to take an application or feature set in a different direction. With Application Services' approach to agile, customers are never locked in by big, up-front system design.
In the second part of our series on agile software delivery, we discuss in greater detail specifically how WWT delivers on the agile value proposition.