Organizational Success

Agile teams achieve organizational success by focusing on delivering value and decreasing costs. This directly translates to increased return on investment. Agile teams also validate expectations early, so if an effort won’t be an organizational success, you’ll find out early enough to cancel it before your organization has spent much money.

Specifically, Agile teams increase value by seeking out business expertise and focusing development on the core value that their products provide. Agile teams release their most valuable features first and release updates frequently. When business needs change, Agile teams change direction to match. In fact, the best Agile teams will actively seek out opportunities to improve their plans.

Agile teams decrease costs as well. They do this partly by technical excellence; the best Agile teams generate only a few bugs per month. They also eliminate waste by cancelling bad projects early and replacing expensive development practices with simpler ones. Agile teams communicate quickly and accurately, and they make progress even when key individuals are unavailable. They regularly improve their process and code, making their software easier to maintain and enhance over time.

Technical Success

Agile teams work closely together, which helps them keep track of the nit-picky details necessary for great work. They streamline complex processes like release deployment, giving them the ability to release features exactly at the moment that makes the most business sense. The whole team focuses on finishing each feature before starting the next, which prevents unexpected delays and allows the team to change direction without waste. They create simple, continuously evolving code that’s easy to modify when plans change. They include team members with expertise in the whole production pipeline, preventing hand-off errors and delays.

Personal Success

Personal success is, well, personal. Agile development won’t satisfy everyone’s desires. It’s different enough that it can be uncomfortable at first. However, once they get used to it, people find a lot to like, no matter who they are:

Executives and senior management

They appreciate Agile teams’ focus on providing visibility, a solid return on investment, and long-lived code.

Users, stakeholders, domain experts, and product managers

They appreciate their ability to influence the direction of development; their teams’ focus on delivering useful and valuable software; and increased delivery frequency.

Product and project managers

They appreciate their ability to change direction as business needs change; their teams’ ability to make and meet commitments; and improved stakeholder satisfaction.

UX and graphic designers

They appreciate their ability to influence development plans; their teams’ willingness to iterate on ideas; and faster, more accurate implementation of design ideas.

Developers

They appreciate the improved quality of life that results from technical excellence; their improved influence over estimates and schedules; and their teams’ autonomy.

Testers

They appreciate being integrated as first-class members of their teams; their ability to influence quality at all stages of development; and more challenging, less repetitive work.

Operations

They appreciate being included in development discussions; having operational requirements integrated into development plans; developers’ focus on providing actionable telemetry and logging; and teams taking responsibility for post-release quality and up-time.

Working on Agile teams has provided some of the most enjoyable moments in my career. Imagine the camaraderie of a team that works together to identify and deliver products of lasting value, with each team member enthusiastically contributing to a smooth-running whole. Imagine how it feels to take responsibility for your area of expertise, whether technical, business, or management, with the rest of the team trusting your professional judgment and ability. Imagine how pleasant it is to address the frustrations of your project and see quality improve over time.

Agile development changes the game. Developing and delivering software in a new way takes a lot of work and thought. Yet if you do it consistently and rigorously, you’ll experience amazing things: you’ll ship truly valuable software on a regular basis. You’ll demonstrate progress on a weekly basis. You’ll have the most fun you’ve ever had in software development.

Focusing Zone

Although the Focusing zone is only the first zone in the Agile Fluency Model, the model isn’t a maturity model, as “IT’S NOT A MATURITY MODEL” describes. The core Agile philosophy is fully realized by the Focusing zone. That means that your organization will need to buy into the Agile philosophy in order for your teams to be successful.

What is that core philosophy? As we saw in “The Essence of Agile”: Agile is adaptive rather than predictive, and people-oriented rather than process-oriented (Fowler).

In practice, this means that Focusing teams regularly review and change their plans. They work as a tightly knit team to define their own work processes and self-organize around completing the work. All the while, they’re Focusing on providing value to their organization.

For most teams and organizations, this requires a shift in how they think about teams. Pre-Agile organizations make plans in advance, ask teams for estimates, and expect reports about how work is progressing relative to those estimates. Focusing teams revise their plans frequently—at least every month—and report progress by showing what they’ve completed.

Pre-Agile organizations break their plans into tasks, assign those tasks to individuals on the team, and judge individuals based on how well they complete their tasks. Focusing teams do their own task breakdown, decide for themselves who will work on each task, and expect to be judged on their ability to work as a team.

Can your organization buy into this core Agile philosophy? Again, lip service isn’t enough. Here are the concrete investments they’ll need to make for each Focusing team:™

• Create long-lived, cross-functional teams. Compose each team of people who can work well together and who have all the skills and background needed to accomplish the team’s work. Allocate them 100% to their team. (See [Link to Come] for details.)

• Create a productivity-focused workspace for each team. Unless your company has a tradition of remote-first work, this will probably need to be a physical team room. It’s best if each team has their own room. (See [Link to Come] for details.)

• Ensure that each team has access to someone with business value expertise who’s responsible for setting product direction and goals. They don’t need to be a team member, but they do need to participate in every planning session. (See [Link to Come].)

• Ensure that each team includes at least one full-time team member who’s responsible for determining the details of what the team’s software will do. (See [Link to Come].)

• Remove or revise HR policies that impede effective teamwork, such as competitive ranking and individually-focused rewards. (See [Link to Come].)

• Train managers how to manage the work system rather than individual contributions. (See [Link to Come].)

• Obtain buy-in from managers and key stakeholders that, rather than working to deadlines, teams are going to focus on delivering value in order of priority.

• Obtain buy-in from managers and key stakeholders that, until they reach Delivering fluency, teams won’t be able to provide useful estimates or forecasts. (See [Link to Come].)

• Coach and train team members in the Focusing practices described in Part 2.

These investments are a “good news, bad news” situation. The bad news is that, when the rubber meets the road, some organizations won’t be willing to make all these investments. The good news is that, if they refuse, you’ve discovered early that they’re not really on board with the Agile philosophy. You just saved yourself years of frustration and heartache chasing Cargo Cult Agile.

If your organization refuses to make these investments, that’s great. Now you know: Don’t try to be Agile. Choose another approach to software development, one that properly fits your organization’s culture. Waterfall is a fine choice! Keep your documentation lightweight and your delivery horizons down to 3-6 months, and you’ll avoid its most common failure modes. (If you’d really like to be Agile anyway, there is a bit of wiggle room. We talk about options in the next chapter.)

If you are able to get buy-in, that’s even better. With dedicated effort, fluency will take about 2-6 months to achieve. [Link to Come] shows how.

In exchange for these investments, once your team has achieved fluency, expect to see the value-related organizational success factors described in “Organizational Success”. Some aspects of personal success will also improve (see “Personal Success”). Specifically, senior management, product managers, and project managers will like their improved visibility into the team’s work and their ability to change direction as needed.

Here are the biggest benefits to expect from investing in Focusing fluency:™

• Fluent teams plan their work in terms of business value, not technical tasks, and they align their work to your company’s business priorities.

• Fluent teams demonstrate progress at least every month, and they discuss their progress in terms of business value, not technical tasks.

• When business priorities change, fluent teams change direction to match.

• Management knows when fluent teams are building the wrong thing, or aren’t making progress, and they’re able to intervene early.

• Fluent teams regularly improve their work habits, reducing costs and improving their effectiveness.

• Fluent teams’ team members collaborate well, which reduces misunderstandings and hand-off delays within each team.

You aren’t likely to see improved technical success (see “Technical Success”), though. In fact, technical quality could get worse. Traditional approaches to design rely on careful up-front work based on firm plans. That doesn’t mesh well with Agile’s emphasis on flexible, frequently changing plans. As a result, Focusing teams often end up with an ad-hoc approach to design, which isn’t sustainable.

Poor technical quality can be frustrating for team members, lowering their feelings of personal success. It usually prevents the team from making useful estimates and forecasts, which can be frustrating for stakeholders.

To improve technical success and make useful forecasts, you’ll also need fluency in the Delivering zone.

Delivering Zone

Companies who invest in the Focusing zone have taken an important first step: they’ve aligned themselves with the core Agile philosophy. This is critical! It’s the secret to Agile success.

But it’s not enough for long-term success. Although organizational success makes a company, and Focusing fluency will help you get it, lack of technical success breaks a company. Software built by Focusing teams becomes unmaintainable over time. Over the course of several years, costs will rise. The team wil eventually lose their ability to make cost-effective changes. They’ll tell you they need to throw away the software and rewrite. That’s a dangerous place to be.

Delivering teams prevent this problem by investing in technical success. They design their code so that it can absorb frequent changes. They keep code quality high, so they don’t waste time hunting bugs. They refine their production lifecycle so releases are painless and operations are manageable. They’re capable of Delivering reliable, low-defect software whenever it makes the most business sense.

This requires a shift in team members’ skills, and that takes investment. Specifically, for each Delivering team, your organization needs to make the following investments:

• Make all the Focusing zone investments (see “Focusing Zone”).

• Provide time for lowered productivity while team members learn new skills.

• Integrate all needed technical disciplines into the team, not just programming, such as QA and Ops (see [Link to Come]).

• Provide training and mentoring in the technical practices described in [Link to Come].

The first three investments are critical. The last one—training and mentoring—isn’t strictly necessary. Teams can be self-taught. It’s a cost/time tradeoff: Do you want to spend extra money on mentoring, or extra productivity on self-directed learning?

Either way, as long as you have the first three investments, fluency will take 3-24 months achieve, in addition to the time needed for Focusing fluency. Part 3 describes how. The exact amount of time each team will need depends on the quality of their existing code and how much coaching they receive.

In exchange, expect to see the technical success factors described in “Technical Success”, the cost reductions described in “Organizational Success”, and the team member success factors described in “Personal Success”. Combined with Focusing fluency, that’s all the success factors described at the beginning of this chapter.

Here are the biggest benefits to expect from investing in fluent Delivering teams:{footnote_1_2_afm_copyright}

• Fluent teams release their latest work, at minimal risk and cost, whenever their business partners desire.

• Fluent teams discover and fix flaws in your production lifecycle early, before they can do damage.

• Fluent teams provide useful predictions upon request (with some caveats; see [Link to Come]).

• Fluent teams have low defect rates. They spend less time fixing bugs and more time building features.

• Fluent teams’ codebases have low technical debt, which means changes are cheaper and faster.

• Low defect rates and technical debt are good for job satisfaction and morale, which improves fluent teams’ retention and productivity.

Optimizing Zone

The vast majority of companies would be satisfied with Focusing and Delivering fluency. But Agile imagines more. In its full glory, Agile is a world in which teams twirl and dance in response to changing market conditions. They experiment and learn; develop new markets; outmaneuver the competition.

Optimizing teams achieve this level of agility. They understand what their market wants, what your business needs, and how to bridge the two. Or, as in a startup environment, they know what they need to learn and how to go about learning it. They not only have the ability to deliver reliable software, they also know what to deliver. They’re constantly Optimizing their product plans to achieve the most value possible.

This requires a shift in organizational structure. Optimizing plans requires deep business and product expertise, and that means having product and market experts join development teams full-time. For each Optimizing team, your organization needs to make the following investments:{footnote_1_2_afm_copyright}

• Make all the Focusing zone investments (see “Focusing Zone”).

• Ensure that each team includes at least one full-time team member with expertise in determining how the team’s software fits into its market and how to achieve maximum value. They will be responsible for setting product direction and goals. (This is similar to the “access to someone with business value expertise” Focusing investment, but now they’re part of the team full-time. See [Link to Come].)

• Give each team full responsibility over a particular product(s) or market segment(s).

• Give each team responsibility for their budget, plans, and results. Judge them on their results, not their adherence to plans.

• Enable and expect managers to work collaboratively across the organization to remove obstacles to team performance.

• Provide coaching to managers about how high-performance, self-organizing Agile teams change the nature of management work.

These structural changes require high-level permission in the organization. It can be difficult to obtain. It typically takes teams at least a year of building trust via Delivering fluency before they get permission for these investments. Once that happens, Optimizing fluency takes another 3-9 months to achieve. That said, Optimizing is a never-ending process of experimentation, learning, and discovery. Part 4 describes how to begin.

These are the biggest benefits to expect from investing in fluent Optimizing teams:™

• Fluent teams deliver products that meet business objectives and market needs. They include broad-based expertise that promotes optimal cost/value decisions.

• When discussing progress with leadership, fluent teams describe where their products stand in their market and how they’ll improve their position.

• Mutual trust between fluent teams and their organizations leads to rapid, effective negotiation.

• Fluent teams coordinate with leadership to cancel or pivot low-value projects early.

• Fluent teams learn from market feedback to anticipate customer needs and create new business opportunities.

Strengthening Zone

There’s one final zone in the Agile Fluency Model. It’s largely speculative: a possible future for Agile. It’s also only appropriate for organizations on the bleeding edge of management theory and practice. That puts it out of scope for this book. Briefly, it involves distilling teams’ collective insights and channeling them into organizational improvements. If you’d like to learn more, start with Shore & Larsen.