How does agile apply to an entire organization?

Before we dive into the main subject of this blog post, it is important to recognize the 20th anniversary of the meeting of “The Agile Alliance,” Feb 13, 2001 at the Snowbird ski resort in Utah. That weekend, 17 leaders in software development came together to try to solve the challenge of documentation-driven, heavyweight software development processes. The group came from many different backgrounds like extreme programming, scrum, DSDM, adaptive software development, Crystal, feature-driven development, and pragmatic programming. What emerged from the weekend was “The Agile Manifesto” and the rest, of course, is history.

Now, back to our regularly scheduled blog post.

Organizations that shift towards an agile structure are likely to see benefits in planning, adaptability, stability, and long-term profitability. There are, however, many misconceptions about organization-wide agile methods. Among the most persistent is the idea that practicing agile in certain departments or across multiple teams is the same thing as practicing agile at the organizational level.

Many organizations have embraced agile in limited capacities, but few are exercising agile at the organizational level. This can be seen in the limited adoption of agile across organizational teams. While 95% of respondents in our State of Agile survey said they use agile in some capacity, a plurality of respondents (44%) admitted that “less than half of our teams are agile.” Just 18% of respondents say that “all of our teams are agile.”

Even if 100% of teams are agile, though, it doesn’t mean that the organization itself has an agile approach. To be truly agile, the operations themselves must act in agile planning and execution cycles. The organization should also be built as the sum of respective teams, with each department and core discipline reflected at the top/macro level. With this architecture, work can be performed in an agile manner at the very top level of corporate governance, mirroring the work cycles conducted within even the smallest agile teams.

Organizations capable of exercising agile methodology in macro can ensure responsiveness, efficiency, and adaptability to rapidly changing situations. While this level of adherence to agile principles isn’t wholly necessary (yet), it is one of the most effective ways to cope with uncertainty in an increasingly volatile global business climate.

Consistent agile across the organization is key

Organizations that employ agile within DevOps and innovation teams appreciate the advantages the methodology offers. Shorter work cycles mean not just faster work but faster feedback. There’s less on the line if a new idea fails, meaning innovation no longer feels punishing. There’s a shorter gap between releases, so problems get fixed faster, and new features are always coming out.

An organization that prizes these benefits may fail to appreciate that they can extend to all departments, and they work best when the company functions agilely as a whole.

For example, strategic planning can move from a quarterly or yearly cycle to two-week sprints. Adding new meetings and quicker directives may sound exhausting initially, but the reality is that it leads to less effort overall. A yearly review and strategy report is a massive undertaking. Following up on a new directive instituted two weeks ago is not. The organization checks in more often, spends less time with each check-in, and corrects course more often to produce more consistent value over time.

These capabilities are only possible when every single component of the organization operates according to agile principles. With a focus on small teams, iterative development, fast feedback, and continual improvement, employees can be more engaged and innovate more often.

Inconsistent agile is a major source of transformational failure

Looking at the other side of the coin, inconsistent agile implementation across the organization leads to struggles and challenges. Some of the biggest challenges that tend to emerge include:

• Bottlenecks ⁠— When an agile team delivers work to or expects work from a non-agile team, long delays can result. This breaks the agile/DevOps cycle as it was intended to function.
• Waterfall management ⁠— When an agile teams function within a larger non-agile framework, what can happen is that deliverables get requested in a non-agile way. Budget approvals may only allot so much money for development, constraining what should be flexible work. Agile teams may also be asked to plan ahead for months or quarters at a time, which is impossible when work directives are revised continually.
• Legacy holdouts  ⁠— Modern organizations have evolved in a specific way over the past century. Getting rid of legacy structures can be uncomfortable, even scary, for some. Managers may fear that their power or influence in a revised structure would diminish. This can lead to cultural inertia and inconsistent agile practices.
• Management disarray ⁠— Engaging in organizational agile in good faith can still fail to produce a workable revised management structure. Ideally, agile teams govern top-level activities, much the same way boards and committees do. If the organization fails to understand how its chain of command should reflect its value creation chain, it may put in place new practices that work contrary to agile goals.

It is true that transforming to organization-wide agile will not be without its growing pains. Knowing that, one of the most important directives is to commit to agile practices, both within practices and within the culture. Otherwise, implementing agile inconsistently can lead to greater problems while pre-existing problems remain unsolved.

What does organization-wide agile look like?

When an entire organization functions in an agile way, planning and daily work cycles look similar at the top to how they do at the very bottom.

From this perspective, an agile organization can break down its operational qualities into the following performance areas:

• The organization understands its core profit-generating activities as a limited series of products, which must be continually maintained in order to generate the desired value for customers and internal stakeholders
• The organization approaches intended work not as a series of upcoming projects but as activities necessary to maintain the core products they offer
• Work is conducted through small, cross-functional and multidisciplinary teams; since work can be broken down into multiple components, planning and strategy in organizational agile will be conducted through multiple teams, and top-level strategy will be agreed upon by a delegation of these teams, which may be reflected within the C-suite or a similar grouping of top-level representatives
• Because product maintenance is an ongoing process, agile teams are not dissolved once a work phase has been completed
• The top-level agile team will establish a set of core values and brand promises; business-outcome-focused goals are set based upon these core areas that make up the corporate “vision”; work in agile teams (at any level) reflects the intended value-producing goals
• Organizational work is intended to be conducted in short phases or sprints; at the end of each sprint, there is an evaluation period followed by planning for the next phase ahead
• Legacy trappings of waterfall project planning or budget cycles trapped in long-term periods like quarters should be gradually phased out within every department
• Technology should be leveraged to take advantage of new, more-efficient capabilities and new ways of offering value, both internally and externally

These qualities are reflected in a 2018 report from McKinsey that laid out the following “trademarks of agile organizations”:

1. North Star embodied across the organization — The business seeks out opportunities to create value for the market, guided by principles and core competency areas
2. A network of empowered teams — Work is performed not by individuals but by relatively small, nimble, persistent teams that are responsible for a key component of value creation
3. Rapid decision and learning cycles — Planning and budgeting involve activities in upcoming weeks and months, not quarters and years. Each cycle is concluded with a period of reflection and evaluation, allowing lessons learned to be infused within the next cycle.
4. Dynamic people model that ignites passion — Agile teamwork is fueled by creativity, ingenuity, and a high level of skill attainment. Each employee’s contribution is valued, and management exists to facilitate the conditions needed for everyone to remain productive, motivated and focused on the right goals.
5. Next-generation enabling technology — Technology is not a means of support or a tool but something that is, “seamlessly integrated and core to every aspect of the organization as a means to unlock value.”

These trademarks represent a monumental shift from the old way of doing business, which was often focused on having a small team of managers dictate work that was to be performed over the next few months. It is true that many workplaces have already moved away from strict waterfall managerial techniques. However, the “command and control” approach is still reflected in directives that focus on either: A)  short-term projects, or B) long-term production schedules built to deliver products that rarely change. Neither bucket really works for modern digital products. All activities should instead be directed towards producing/ supporting long-term products that continually evolve and change, optimizing value creation over time.

This long-term focus holds true even if one or more of those products is abstract. For instance, marketing teams aim to sell an “emotional product” that best reflects the organization’s brand values. When marketing takes an agile approach, the team will define the brand’s emotional component initially, and then revise messaging over time to reflect current knowledge and demands.

Find your “North Star” to align agile work

One of the most important steps to making an agile transition is to identify which values, priorities, and brand promises should guide all work from top to bottom. Modern corporate organizations already understand the importance of defining what they stand for. It’s become a critical part of differentiating your brand and leveraging each accomplishment to fit within a larger PR narrative.

This work shouldn’t just be the domain of a small PR, marketing, or branding team. Instead, an agile team should be formed of delegates from each major discipline or department within the company. This team can discuss proposed values and decide whether they fit the reality of smaller goals and work accomplishments within their specific domain. Importantly, agreeing upon values is not just a one-time project, either. The values should be revisited regularly, adapted, and revised to fit the current reality and understanding.

This set of values and principles gives shape to the organization-wide vision of what daily work is supposed to achieve. If all employees understand this vision, then they can be capable of making decisions that align with top-level priorities, ensuring everyone is working towards a common organizational goal.

Our own company seeks to embody this working principle with the adage “focus on outcomes, not outputs.” Business goals should reflect a specific situation, similar to how user stories inspire development teams to seek a specific level of functional utility. With this approach, goal achievement is not just the sum of met requirements. Instead, an emergent set of circumstances is created, enabling a specific intended outcome to become a reality.

Focus on teamwork over management (turning most corporate structures inside out)

Another key feature of organization-wide agile is that teams form the basic unit of decision-making and work execution.

Traditionally, top-level managers issue directives to departmental executives, who then oversee the completion of work needed to satisfy the directives. Teams are a reflection of their overseeing manager; a way for an individual manager to accomplish the work assigned to them through a system of delegation.

Within this framework, departmental executives are taught to adopt an assembly line mentality: send orders from on high, and let mid-level managers execute the orders through teams of low-level workers — with little to no wiggle room for creativity or flexibility.

In an agile organization, this dynamic is turned inside out. Ideas and directives are generated from within the teams themselves. Managers are tasked with overseeing and supporting the work of their respective teams.

Instead of issuing orders, management defines goals, determines ways to measure success, and hands down targets for teams to achieve. Rather than ordering teams to accomplish these goals in a certain way, managers report to higher-ups what solutions teams came up with for the best path forward.

Keep in mind that one major barrier to flipping to a team focus is that teams in a non-agile organization are still expected to plan for and deliver requirements on an extended schedule. While someone inside, say, a feature development team will focus on short-term 10-14 day sprints, their manager may be asked to deliver a plan for development activities over the next few quarters. When truly practicing agile, planning this far ahead is impossible! Instead, top-level administrators should expect to check in periodically and measure progress towards long-term goals (which should also be continually revised to reflect the current reality).

“There is a big cultural shift from waterfall practices to agile,” notes Scott Erlanger, director of product marketing, agile and DevOps at Digital.ai. “The idea of frequent releases and constant managing of a backlog is a big adjustment for those used to planning out big releases.”

Ditch the project mentality in favor of persistent product teams

Traditional business environments separate work into two broad categories: daily work and projects. If something isn’t in the scope of daily, repetitive work, it is seen as a “project”.

Projects are managed in much the same way a newly manufactured product is: the requirements and scope of the project are determined, a budget is issued to have the project completed. Roles are assigned, along with team members, and the project is expected to be completed within specifications, including the chosen timeframe.

Events like COVID-19 have shown us we can’t possibly predict the outcomes of projects that last longer than a month! Parameters can and will change. When they do, the project team is stuck justifying necessary adjustments to get the resources or permissions they needed to realistically achieve the original intention.

As the Project Management Institute (PMI) observes: “No matter how much detail such a project has, the complexity of an enterprise project is almost always underestimated. The very nature of the project makes that almost inevitable. When a project will cause a change in behavior, it is certain that as the project evolves, those affected will see it in with a changing perspective.”

“You can’t get there from here”

When reflecting on the challenge of long-term, project-style planning, PMI references the old joke reply when you ask for directions: “Oh, you can’t get there from here.”

The joke is that it’s impossible to understand how to reach your destination from your current position. Instead, you have to reach a point where it’s easier to take a direct route to that destination.

In the same fashion, it’s okay to define a far-off goal for a project team to achieve, but the journey towards that goal is never a straight line.

To get to that point, the team should instead focus on creating shorter milestones. Managers should give teams the autonomy to chart the next milestone or correct course in order to achieve the actual objective, not just hit the originally intended trajectory.

For example, a manager should not just say “we need all products available on the cloud by next May,” which may be an unrealistic goal or one that quickly meets unexpected barriers. Instead, they can say: “we need to give our customers better access to our products across devices and without the need for software outside a browser or app API,” which then allows teams to achieve this outcome on a product-by-product basis.

Good projects end; great products are forever

Planning in milestones addresses a shortcoming of traditional business management: its focus on projects. The fact is that projects have a clear endpoint; once it is reached, the project is over, and the project team is usually dissolved.

What agile does is recognize that there is always a return trip. The journey was planned for the purpose of reaching a certain goal, one that is not permanently fulfilled by one successful execution. The trip must be repeated because in business the cliche is true that “the journey is more important than the destination.”

To ditch the travel metaphors: project teams are formed to satisfy a goal that really doesn’t go away the moment the project is completed. If a marketing team is preparing for the launch of a new app-based service, the end of the launch doesn’t mark the end of the work needed to be done. The business’s customers expect to derive continual value from the new product. Once the DevOps team can deliver the needed functionality, the marketing team can then perform a data feedback role. They will act as a go-between, gathering sentiment from customers and explaining what vision the product helps achieve. Now, marketing is now working at the service of a long-term product rather than a short-term project.

Some of the world’s most persistent brands understand that in order to deliver the same product they are famous for, the product must continually change while the values and brand promises stay true to their foundational principles.

When an organization truly practices agile, then it will continue to support the value-creating product it offers to the public. Rather than focusing on short-term projects, it will seek to accomplish long-term goals, like earning brand affinity, by planning short-term work milestones.

Commit to being completely agile, not just doing some agile

The journey of organization-wide agile transformation can be winding, and enterprise leaders need to be willing to admit that the destination can change. The “destination” is also a moving target; the goal is to keep ending up there at the conclusion of every short-term sprint.

The idea of an unfixed destination can be scary, but fully committing to agile transformation despite bumps along the way is vital for not just transformation success but the continued survival of the business in an increasingly disrupted world.

Most critically when transitioning to agile: business should never do half measures!

“The worst thing that can happen is to start the transition and then give up halfway,” writes industry reporter David Roe. “I’ve seen many examples of companies which haven’t successfully transitioned to agile management. Instead, they’ve got some type of a hybrid system and caused a lot of internal issues.”

Let the vision established by your top-level agile team drive you: a vision of not just greater efficiency but workers who are more satisfied with their jobs and customers that are happier than ever with your products with each passing day.

If you are planning on or have implemented agile digital transformation in your organization then share your experiences with us. The State of Agile survey is the largest and longest running agile survey online. We’d love to hear from you.