How Agile Are You Really?

Three Helpful Criteria

Image by Clker-Free-Vector-Images from Pixabay

Agile is everywhere, especially in the world of software development. Unfortunately, the term ‘agile’ has become so overused that it risks losing all meaning. In an industry where everyone claims to be agile, how can we evaluate the quality of specific processes? What criteria can we use to measure agility?

The best place to start is with the founding documents: the Agile Manifesto and the Principles Behind the Agile Manifesto. These form the core of true agility and should guide any assessment. However, organizations have interpreted these documents in many conflicting ways. So, I thought some additional criteria could be useful.

Below are three overriding core practices of agile. If your organization doesn’t engage in these behaviors, then it is likely NOT agile. You can rate an organization’s agility by assigning a score from 1 to 5 for each practice. I have included both explanations and examples to help you determine the right score.

One more thing before you get started: it’s important that individual contributors, not management, do the evaluating. Since management is responsible for choosing and enforcing company processes, they’re likely to be biased in their favor. To get a more accurate rating, feedback should come from those at the ground level.

Give it a try and see how your company is doing.

1. Distributed Decision Making

Agile should wrest control from the corporate hierarchy. It should push decision-making outward and downward to the software developers. We’ve entered an era of knowledge work where managers are often the least qualified to make technical decisions, simply because they’re furthest from day-to-day operations.

When a group of developers met in Snowbird, Utah, in 2001 and agreed on values like “Individuals and interactions over processes and tools” and “Responding to change over following a plan,” they were championing distributed decision-making. Yet, today, managers are still enforcing processes, tools, and plans. Software is far too complex for anyone but individual contributor level developers to be making technical decisions. Agile was designed to put an end to the chain-of-command bottleneck.

Is management still valuable? Absolutely. But its role must shift—from directive to supportive. Better yet, management duties can be distributed among team members, allowing managers to return to individual contributor roles. The fact that agile seems to be universally adopted might actually be a bad sign—power doesn’t give up that easily. Clearly, organizations are co-opting agile while leaving too much power in the hierarchy, and then cheerfully declaring their compliance to agile principles.

Some forward-thinking companies, however, are embracing this shift. At Google, for instance, it’s not uncommon for managers to have 30 direct reports, making micromanagement impossible. With that many reports, managers simply don’t have the time or energy to interfere with distributed decision-making.

Another example is Morning Star, which has taken a more radical approach by eliminating managers altogether. Responsibilities like hiring, purchasing, setting salaries, strategy, and even firing are distributed among all workers. This and other manager-less experiments deserve the attention of the agile community. They’re showing us how to live up to the very principles agile was built on.

Here are some concrete process examples along with their ratings:

Level 5

1. Engineers choose and modify their own processes on a team-by-team basis.

2. Engineers decide what to work on and who they work with.

3. Engineers select their computer’s OS and have admin rights to their machines.

4. There are no titles. Each engineer has full authority over their own responsibilities. There is a notable absence of non-coding review and design teams/committees/roles.

5. There is a notable lack of company wide standardization. Even though teams tend to naturally converge on a handful of useful practices, they are allowed to experiment in many areas (i.e. languages, operating systems, deployment strategies, continuous integration strategies, code review requirements, libraries).

Level 3

1. A standardized process is mandated for all engineers, but they can modify certain aspects of how they practice it.

2. Engineers can provide input on what they work on and with whom, but management makes the final decision.

3. Engineers are assigned an OS but have admin permissions.

4. Titles are used for decision-making authority, though management takes engineering opinions into consideration. There are a minimal number of non-coding review and design teams/committees/roles.

5. Many aspects of engineering are standardized across the whole organization (i.e. languages, operating systems, deployment strategies, continuous integration strategies, code review requirements, libraries).

Level 1

1. A standardized process is mandated for all engineers, and they have no power to change it.

2. Engineers are assigned work items and teams.

3. Engineers must use a specific OS and do not have admin rights.

4. Titles are heavily used to determine who makes technical decisions. Advancement mostly involves moving into non-coding review and design teams/committees/roles.

5. Most aspects of engineering work are standardized (i.e. languages, operating systems, deployment strategies, continuous integration strategies, code review requirements, libraries).

2. Close to the Customer

You’ve probably heard the saying: “the business decides what to build, and engineers decide how to build it.” But this is the opposite of how it should be. Agile pulls developers closer to customers and much deeper into the business side of things.

The practice of assigning a customer representative to engineering teams (often called a Product Owner) is problematic. Most product owners act as a barrier between developers and customers rather than as facilitators. This eliminates a direct line of communication, leading to less effective outcomes.

Collaborating directly with customers can be uncomfortable for some developers, but this needs to change. Developers shouldn’t passively allow the product organization to take on this responsibility. In an agile organization, customer collaboration is central to a developer’s role.

Valve’s employee manual offers a prime example of a structure that embraces customer collaboration:

…when you’re an entertainment company that’s spent the last decade going out of its way to recruit the most intelligent, innovative, talented people on Earth, telling them to sit at a desk and do what they’re told obliterates 99 percent of their value. We want innovators, and that means maintaining an environment where they’ll flourish.

… This company is yours to steer — toward opportunities and away from risks. You have the power to green-light projects. You have the power to ship products.

A flat structure removes every organizational barrier between your work and the customer enjoying that work. Every company will tell you that “the customer is boss,” but here that statement has weight. There’s no red tape stopping you from figuring out for yourself what our customers want, and then giving it to them.

Here are some concrete process examples along with their ratings:

Level 5

1. Engineers meet regularly with customers, asking questions and observing how they interact with the product. Engineers use these insights to direct their work.

2. Engineers gain additional insights from Product Management, but they make the final product decisions themselves.

Level 3

1. Engineers are occasionally involved in customer meetings.

2. Engineers contribute some product direction but primarily work from a backlog defined by Product Management.

Level 1

1. Engineers never meet with customers.

2. Engineers take direction solely from customer proxies, like Scrum Product Owners.

3. Release Early and Often

To respond quickly to change, you can’t afford to spend too much time on the wrong path. The agile way to avoid this pitfall is to present intermediate results to customers early and often, adjusting your direction accordingly.

Several of the Principles behind the Agile Manifesto support this approach:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Working software is the primary measure of progress.

Simplicity — the art of maximizing the amount of work not done — is essential.

Developers should meet with customers regularly to present their progress. However, the practice of sprints or iterations distorts this principle. The distinction is subtle but crucial.

Sprints or iterations—which are used in almost every agile implementation I’ve encountered—miss the point in practice. Software should be released frequently to evaluate progress, not to impose artificial deadlines or apply scientific management techniques to optimize developer output.

To “deliver software frequently” simply means demonstrating progress every “couple of weeks to a couple of months.” It doesn’t imply a fixed delivery cadence or target scope, as sprints do. Sprints are an attempt to reintroduce the unhealthy planning and estimation practices that the agile movement originally condemned. The many ceremonies tied to sprints—such as burn-down/up charts, cycle time calculations, story points, estimations, and velocity—are agile anti-patterns.

The most compelling example of releasing early and often comes from the Open Source software movement, one of the most impressive distributed volunteer enterprises in history. Thousands of developers release software improvements daily, gather feedback, and even solicit help from users—this is the epitome of customer collaboration. The sheer volume and quality of free, open-source software in use today is remarkable.

Here are some concrete process examples along with their ratings:

Level 5

1. Engineers demo their work frequently.

2. Engineers decide when to demo based on the progress of their work. There is no artificially imposed release cadence. Engineers might demo every day for a week, then take a week before the next demo.

3. Engineers determine how much polish is necessary for a demo. Some demos may be “rough sketches” or prototypes to gather feedback before investing too much time in implementation, while others are finished products.

4. Process metrics are used only within the team and are not reported to management.

Level 3

1. Engineers demo their work at a regularly scheduled demo meeting aligned with a fixed, repeating sprint duration, which is mandated by management.

2. Demoed software must always be polished and meet a pre-defined “definition of done.”

3. There are a handful of process metrics reported to management about each team.

Level 1

1. Engineers demo their work infrequently, at intervals longer than a couple of months.

2. Process metrics are reported to management and used aggressively to drive productivity.

How did your organization score?

I hope it ranked high, and if so, you’re in a fortunate position. But don’t be discouraged if the score was on the lower end. Unfortunately, most companies today fall short in terms of true agility, despite what they might claim. The key is to focus on levels of agility, rather than on whether an organization merely professes to be agile. By doing so, we can push for improvements that will make working conditions better for all of us.