“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan” – Agile manifesto

Agile (in its many flavors) is the de facto standard for work management in software. It identifies core priorities for software collaboration and outlines a flexible structure for managing requirements. This facilitates best practices and a shared methodology.

It helps to consider what agile replaced, the waterfall process. Waterfall defines a linear process with all requirements up front, then design, development, testing, and release following one at a time. This made for inflexible contracts, failure to meet customer needs, missed deadlines, and burned out developers.

Agile flips this on its head with regular customer interaction and requirement correction. Process is kept minimal and people are the most important.

Example

Suppose you are starting a project with a customer. To write a contract you need an idea of what work will be done, how much effort it will be, and a statement of work both parties can agree to.

The process starts with a meeting between a few customer reps and dev team members. The meeting is largely a discussion between the customers and developers to understand the customer’s needs. As each need is clarified, the developers write down a short summary. This is often done with note cards, sticky notes, or rows in an excel sheet. It is not the details for implementation but a description of need. Think “As a user, I want to …”. These needs are commonly referred to as user stories.

After both parties feel they have developed a good understanding, the note cards can be reviewed to ensure the understanding is mutual.

The developers then give a rough effort estimate for each user story. If a story it too big or unclear, split it up. As a rule of thumb, stories longer than two weeks are too big.

Armed with estimates, the customer prioritizes the stories. This could be priority categories or a ranking of the top N stories. This priority list serves as the vision for the project and basis of the contract.

Moving forward, the customer will meet with the team every iteration (typically 1-2 weeks). The team can give an update on progress, get feedback, and the customer can adjust priorities. The customer then chooses what work will be done in the next iteration. They can only assign as much work as can be finished in the iteration (according to the estimates). During each iteration, the scheduled work is set and cannot be changed.

These iterations are repeated until the project is complete.

Satisfying the customer

The highest priority in agile is customer satisfaction. Allowing the customer to set priorities ensures that the team is always doing the most important work for the customer.

Involving the customer regularly also allows the team to clarify tasks and discover requirement changes early. As decisions pop up, the customer can be included in weighing the choices. It is strongly recommended that the customer or a customer representative shares office space with the team.

However, it is also important that the developers are interpreting the customer requests. The customer may not always understand their need and how technology can fill it. The exchange between groups clarifies purpose to the fill the customer’s need, not just their request.

Short and complete increments of work also help to satisfy the customer. It maintains a sense of progress and builds trust by making the team’s effort clear.

Leveling Expectations

Agile levels expectations by dividing responsibilities and facilitating interactions between them.

For example, customers prioritize, developers estimate, and work in an iteration is fixed. This allows the customer to control their outcomes. At the same time, the developers don’t have to worry about work changing under them. Developers are also in control of how much work is sustainable each iteration. Both parties know what to expect at the end of an iteration.

Since the customer and developers are in regular contact, there are fewer surprises. Issues or changes in scope cause less conflict because both parties have maintained a shared understanding.

It is also easier to add and remove contributors. Expectations are clearly encoded in short user stories and detail is only fleshed out as the stories are assigned to be done. Each unit of work is a complete chunk of work. Thus, the learning time needed to contribute is minimized.

Incremental Delivery

“Simplicity–the art of maximizing the amount of work not done–is essential.” - Agile Manifesto: 12 Principles

The best way to shorten work is to never do it in the first place. Agile evaluates frequently and only fills in enough detail for the work at hand.

Frequent evaluation minimizes the time before outdated work is detected and deferring detail makes changing priorities cheap. Only tasks that are implemented get extended specification work.

Incremental delivery also keeps the code in an always-working state. Each story fills a self-contained need and provides value on its own. Since work is fixed during an iteration, this means work should never be discarded mid-completion. Without rules for clear and small stories, it is easy for work to snowball together, leaving work vulnerable to invalidation midway.

This always-working state facilitates consistent pace. The most value the team can deliver at a time is already being delivered. Thus, there is less pressure toward overtime and oversized goals.

Design Synergy

“Continuous attention to technical excellence and good design enhances agility.” - Agile Manifesto: 12 Principles

The 12 principles of the manifesto also make it clear that agile is not a silver bullet. It must be paired with good technical practice to experience the full benefit.

Martin Fowler, one of the manifesto signators, elaborates through the Design Stamina Hypothesis. Applications with weak design practices become harder to modify over time. Eventually, the system is so complex that any change is difficult, and the software can’t change fast enough to match requirement changes.

In contrast, systems with good design practice can maintain relatively constant effort-to-output.

Reflection

Agile is more of a guideline than a complete prescription. It is also about the people. Be self-aware and adjust to what works for your people. It is recommended to hold a retrospective every iteration to consider what can be done better.

TL;DR

Agile (in its many flavors) is the de facto standard for work management in software.

If focuses on people and provides simple guidelines for delivering value, leveling expectations, and adapting to change.

The process is flexible, but not a silver bullet. Be self-aware and adapt it to each team.

Example#

Satisfying the customer#

Leveling Expectations#

Incremental Delivery#

Design Synergy#

Reflection#

TL;DR#

Further Reading#