A Pragmatic Guide to Agile Ways of Working

 
 
 

17 min read

About this guide

The reinvention of working approaches

Many organizations today are trying to reinvent their working approach to keep pace with changes in markets, technologies, talent and lifestyle. Teams are changing their structure or work methods, organizations are kicking of transformation initiatives.

A study from digital.ai found that the adoption of Agile as a working approach has increased from 37% in 2020 to 86% in 2021 for software development teams, and adoption has doubled for non-IT groups. Deeper studies show adoption of Agile does not always mean that a company is truly Agile but the trend towards more Agile ways of working is definitely present.

A central theme in those reinvention efforts is “New Ways of Working (NWoW)”. How to start a new working approach that is better suited for today’s challenges. NWoW has become a science in itself. What we especially want to understand is how the combination of culture, work methods, technology, and workplaces can give better outcomes.

Lessons learned from the software industry

The software industry is a very interesting case. Since early 2000, more and more teams in this industry have adopted Agile ways of working (Agile WoW). The benefits that companies report in productivity, ability to deal with change, and customer satisfaction are outstanding. And what’s not to be neglected, employees have become happier.

This time, instead of prescribing a new lifecycle model or project management methodology, the new approach is based on a mindset shift. So with all that success, would it not make sense to ask yourself as any team - software or non-software - how could you also benefit from such a work approach?

Agile Way of Working for both software and non-software teams

Non-software teams have indeed started Agile journeys as well. Surveys like the annual State of Agile Report indicate that non-IT Agile adoption has doubled between 2020 and 2021. The digital need for pivotability and innovation is one of the drivers. Operational improvements are a valid motive as well.

The two key challenges we have now are:
1. How do we fit new ways of working based on Agile thinking for the specific context that an organization or team is in?
2. How do we remove the barriers that prevent organizations from broader adopting?

What this guide will cover

This guide will facilitate that effort. By showing you what is possible with Agile ways of working for different contexts and targeted outcomes. And by walking you through an Agile journey including where to start, how to prioritize, what changes to make and what skills to learn.


What exactly is an agile Way of Working?

Agile started in the software industry

During the last two decades, the Agile approach has helped software engineering teams and organizations achieve significant improvements in value creation, efficiency, and adaptability.

An important differentiator of the Agile approach is that it introduced a new mindset rather than prescribing a life cycle method. I was working at Microsoft just before 2000 and we were already working Agile-ish then with cross-functional teams, iterations of limited length, doneness with continuous quality.

The Agile Manifesto formalized the base set of Agile values and principles in 2001. An example value is to adapt to changes over holding on to rigid plans. Based on this manifesto, software teams started to create new ways to structure teams, define requirements, plan execution, and many other changes.

Unfortunately, many software professionals have taken an outside-in approach to Agile and only learned an Agile process model like Scrum to get started. The danger here is that you use recipes without understanding the ‘why’ and how to adapt.

Three ultimate traits: value creation, frictionless operating, and resilience to change

If I look holistically at how my coaching clients and other organizations have reached better outcomes with an Agile way of working (WoW), three main traits stand out for me: they create value, they operate frictionless, and they are resilient. These three traits are also crucial in today’s world where the amount of change, uncertainty, and complexity have higher levels than what traditional organizations can handle.

 
Three ultimate traits stand out: value creation, frictionless operating, and resilience to change.

So how do you build these magical traits? With improvement attempts in the past, we often tried to introduce new project management methodologies or lifecycle methods. In the case of Agile WoW, methods are not the primary focus. Instead, we put people and customers at the center and build capabilities that implement the Agile mindset. We will see how this is done.

Rooted in values and principles

Agile WoW is rooted in Agile thinking. Originally developed in the software industry, these values and principles encourage the incremental delivery of value, carried out by small self-organizing teams, with close customer collaboration and with flexibility in plans.

A key notion is that the how-part of Agile ways of working is not prescribed. And this is a good thing! Context always matters. Sure, there are patterns that you often see back in some form - like team structures or delivery lifecycle processes. But how we handpick and tailor capabilities is actually part of the Agile journey that a team goes through.

Lean is also in the mix

Note that Agile WoW also incorporates many of the “lean” concepts. Lean is a management approach that was invented in the manufacturing world long before the software industry started with Agile journeys. Lean emphasizes customer value, flow efficiency, and minimal waste, backed by strong culture and leadership.

Most often, you see that these "Lean-Agile" teams aim to maximize value, optimize flow, and improve continuously while minimizing waste, all of this backed by strong culture and leadership. The optimal amount of lean in your Agile mix depends on whether your goals are focused on customers, operational efficiency, product leadership or other.

Companies with focus on product innovation heavily use lean techniques, especially in the product discover phase. Examples: Lean Startup build-measure-learn cycles, Design Sprints and Lean Minimal Viable Products (MVPs) that all help to validate product ideas early.

Agile versus agility versus Agile WoW

Even though some folks use Agile and agility interchangeably, their meanings are not the same. Agile is a mindset, Agile WoW is applying Agile in your work approach, whereas agility is one possible benefit from agile WoW.

Agility is an attractive benefit to have when you need to pivot business strategy fast. By mobilizing or changing teams, plans, product definitions, technologies, and skills, you are able to adapt quickly to new demands. Agile is the enabler here. In a related post I explain the differences between Agile and agility in more detail.

Make Agile your second nature

What is special about Agile WoW is that it’s mindset-based. And once Agile is part of your mindset, you “are” Agile, not just “do” Agile. So all your decisions and actions become natural.

What I have also experienced is that it's much easier to empower and motivate people with principles than with recipes. Agile can then become an adaptive approach and you can evolve it over time in line with your evolving work, and life.

Why is agile way of working so important now?

Dealing with change and complexity

We have seen several trends in the industry during the last two years that have put high demands on the way we work. The VUCA world became ultra VUCA.

The pandemic caused a shift to remote and hybrid work, causing collaboration, culture, and personal well-being challenges.

More companies embarked on digital transformations, with changing business models, plans, technologies, and skills. At the same time, the complexity of problems has increased.

Agile WoW is an enabler

Traditional ways of thinking, working, and leading are not good enough to handle such significant shifts. We need to upgrade our working approach, and this time it requires more than the efficiency improvements or process methods that have helped us the in earlier days.

We now need to work better with customers, have systematic approaches for innovation, advance collaboration, and build change resilience.

 
Agile Way of Working has demonstrated to be an excellent enabler, organization-wide.

Agile has demonstrated to be an excellent enabler. Agile (and Lean) ways of working make teams and organizations more aware of customers, value and data. Agile WoW helps organizations to mobilize more easily and with fewer frictions. It helps validate new product ideas earlier, make requirements and plans more flexible, and make us learn more skills continuously. Plus, quite important, Agile WoW also builds up change resilience in people, which is a crucial mindset and leadership topic.

Agile helps the whole organization

Agile WoW was initially about optimizing how we deliver products at team-level. This was very practical for software teams that struggled with efficiency problems. Nowadays, Agile WoW affects the whole organization.

Agile-at-scale enables effective collaboration and delivery between multiple teams, for example, supported by a process framework such as SAFe and/or Agile organizational model such as Spotify tribes and squads.

I have trained and coached marketing teams that use Agile approaches for their campaigns. Finance departments start with Agile budgeting and funding. HR teams use Agile practices for hiring and performance reviews.

So we see that Agile happens organization-wide with customer focus, business agility, and frictionless collaboration across all teams in the organization.

How do you start an agile way of working?

Focus on agile capabilities rather than on a framework

When implementing the Agile approach, it may be tempting to take a prescribed framework like Scrum or SAFe, and do nothing else. And the certifications you can obtain in these frameworks may give the impression that you have completed the move to Agile successfully.

An Agile WoW is much more than following a framework. Agile WoW includes behavior changes, skills, new work styles, new collaboration mechanisms, work environments, and much more. Together, these elements result in new ‘capabilities’ which generate better outcomes. We will talk more about capabilities in the next section.

Identify outcomes and value drivers

Transformations to Agile ways of working are done to enable the achievement of outcomes (and not because we want to tick off the Agile checkbox). So it makes sense that we clarify desired outcomes and associated value drivers to everyone involved so that we can support those targets.

My favorite tool for visualizing targeted outcomes is a two-dimensional diagram in which you see both the importance and timing.

Take an Agile approach to adopt an Agile way of working

A piece of key advice I’d like to give for introducing Agile ways of working is to do it actually in an Agile way, meaning use a clear and shared purpose, build new changes and skills iteratively, and take just-in-time decisions about what to implement next based on what we know and experience in the current state.

Tailor your Agile WoW to the context

To kick off an Agile way of working, have you ever considered taking the Agile Manifesto and implementing each value and principle one by one? If you ask yourself the following two questions, you will discover that introducing an Agile way of working cannot be done with a one-size-fits-all recipe.

Question 1: Should each organization prioritize Agile working values and principles in the same way?

Probably not. When I start coaching a team during Agile immersion, I always ask them to prioritize the 12 Agile Manifesto principles, and the resulting top-5 always has specific items for each team. And this makes sense because for some teams customer intimacy is the most crucial value dimension while another team may need to focus on execution performance.

Question 2: If two teams do have the same prioritized Agile principles, should they implement the exact same methods and practices?

Not necessarily. Look for example at the principle of self-organized teams. Should every single team take all decisions themselves? It depends on your current state, maturity, people, dependencies, and probably some other parameters.

So the right choices depend on your context. So now that we are convinced that we should custom-fit the implementation of Agile way of working, how are we going to organize ourselves and drive such transformation effort?

Context first of all includes what is the type of work you do. Are you a marketing, sales, or HR team? Do you develop products or services? What technology do you work with?

Secondly, what outcomes does the business need to achieve and what value do you need to produce? A recent client in medical devices initially prioritized quality because of regulatory compliance and health risks. After they started a digital transformation initiative, innovation became the primary target and it meant that we needed to adapt both work culture and processes.

Assess your current state and constraints

To fit your Agile working approach well, you need to make sure you understand your starting state. A digital native startup has a different starting context than an existing traditional organization.

What does your current culture consist of? And what is the leadership style? Are they adequate to support an Agile way of working where we want to empower people and make local decisions fast?

What is really important is to understand your current constraints for the Agile capabilities you want to develop. What blockers, resistance or other factors do you need to make changes for?

What skills does the staff possess and what are they capable to learn? Are we working distributed over different locations with maybe also different cultures? Do we work in the office, remotely or hybrid?

With an understanding of both our goals and contextual parameters, we can start to think about the Agile capabilities and skills we need to develop.

Use a change backlog to plan and communicate

So by this time you probably have noticed that we cannot start Agile WoW by simply creating a blueprint. Fixed, long-term plans don’t work. Rather, I suggest that you make incremental changes based on a living change backlog. Such backlog is not a blueprint but rather a prioritized list of items that you evolve and re-prioritize as you go.

To decide which items you put in such a backlog, I often take the perspective of the Agile capabilities that the team or organization needs, the “what”. These could be your epics in the backlog, umbrellas for sets of changes that give you some new capability. Under such epic/capability, we can then elaborate the “how” in the form of new practices, tools, roles, communication, models, skills, etc.

With a centralized backlog in place, you accomplish several good things. It serves as a single source of truth for all changes that we are going to make. We use it for planning, design, communication, and governance. The result is that everybody involved in the organization stays informed and aligned without the overhead of special meetings or status reporting.

Use experiments to deal with uncertainty and resistance

Execution based on a backlog sounds like a straightforward plan-do-check-act (PDCA) type of cycle for each change. In real life, change management is not so obvious.

Changes may have big consequences, you may not be certain about the outcomes, or the change may cause resistance in the organization.

Experiments can help in those cases because they allow you to validate the benefits of the new state before rolling out full-scale. When you do an experiment first, the acceptance of the change is easier because the change isn’t permanent yet while it is being validated.

The message here is “we want to try out a change, ensure first we get the benefits, and welcome feedback and adaptations before rolling things out”.

Make Agile learning an implicit part of people’s job

To support the new roles, practices, and even behaviors, people need to obtain new skills and competencies. For new roles such as Product Owner, Agile Master or Data Analyst, learning hard skills still remains important. The big focus now, however, is on soft skills that help people to collaborate better, lead better, and deal better with change.

Setting up an Agile academy is an excellent initiative to make continuous and social learning possible. Such an academy can be used for on=demand learning in the flow of work where people have access to both external and internal learning resources. And where learning can be shared and discussed so that on-the-job experiences are spread.

Which agile capabilities should you develop?

The scope of Agile WoW is wider than team-level Scrum

To illustrate the scope of Agile WoW, let’s do a quick comparison with the team-level Scrum Agile method that many teams get immersed in when they start with Agile. Scrum is a framework that prescribes which process steps, roles and artifacts you need in order to implement incremental delivery cycles with short iterations carried out by a small cross-functional team.

The main capability that Scrum implements is iterative, delivery execution of valuable functionality increments. Scrum includes a few practices that help you with other capabilities such as continuous improvements through retrospectives. But the main capability is planning and execution efficiency.

Agile WoW on the other hand is more holistic and complete, and more capabilities come to play.

 
Agile WoW is more holistic and complete, and more capabilities come to play.

Agile WoW capabilities define the ‘what’

If you want to work the Agile way, you basically need to possess a set of team-level or organizational ‘capabilities’. This is analogous to product or service capabilities: we are talking about the abilities or qualities that help the organization (user) achieve business outcomes (customer value).

Therefore, defining the needed organizational capabilities is a logical step once we know the business strategy. I really like the use of capabilities because they make your Agile WoW vision concrete and allow you to align with the leadership team on what you want to accomplish. Note by the way that in Agile (software) development, product capabilities are often defined in the form of ‘epics’ which are key work item types for the collaboration between the business and product development. You can do the same here.

Let’s look at some examples of capabilities. If your business strategy primarily relies on new products for upcoming market trends, then market sensing, innovativeness, and versatility are good organizational capabilities to have.

If operational excellence is your main business driver, your capabilities could include speed, quality and/or cost efficiency. If customer intimacy is the primary value dimension, then you want to build capabilities such as customer experience and data analytics.

Agile WoW elements are tactical & ‘how’

To build a capability, we need to implement one or more Agile elements. An element is basically a new change or skill related to practices, behaviors, roles, artifacts, tools, or technology. Oftentimes, you see that multiple elements contribute to a capability.

Let’s look at the versatility capability that we wanted to build in the above example. To build such capability, you could implement a combination of elements: use flexible team structures to be able to mobilize new teams quickly, continuous learning to develop T-shaped people, and/or platform technologies to change products fast.

Note that you do not always have to implement all the elements for a capability at once. For example, I am a fan of stable teams so I would probably focus on the flexible skills created through active learning rather than the flexible team structures.

In a related post, I describe the key changes that you need for building an Agile WoW backbone.

Practical tips for agile WoW

Limit the amount of change in progress

When you introduce Agile WoW in a team or organization, you need to establish the pace at which you want to make changes. I have seen the best results when we planned the changes in so-called ‘waves’. Each wave could span 1-3 months and you plan a limited set of changes in each wave that will bring you to a new state of Agile working with additional values and outcomes.

An alternative is to implement changes in a Kanban pipeline with a maximum number of changes in progress at any time.

Both approaches are actually quite easy to do when you have organized all your elements and associated changes or skill-building activities in a backlog.

Involve change teams

One of the best ideas that I have initiated as a transformation leader is the use of change teams. Even if you have a small group of coaches, it is wise to actively enlist people who will use the change and let them actually participate in or develop the change.

You accomplish several things with this. Embracing the change will become a natural process - especially helpful if you have people with resistance or reservations about the changes. And once the change is rolled out, you have some people in the teams who can champion the changes and communicate first-hand about possible problems.

Use pilots or canary-style deployment in case of risks

Not all changes are without risk. Risks could come from uncertainty, cost, and unknown consequences for customers, or others. To tackle such risks, you can use pilot teams that use the new change first before you roll out the change to the rest of the organization.

Or, as an example for customers, if you have developed a new way to collect feedback from customers, you could roll out that change to a few people first and review the results before deploying at large.

Give room to adapt

We have seen that implementing Agile WoW is not a linear process and that details depend on context. At the same time, Agile is about continuous change and about empowering people to shape their best way of working.

So when you implement a new practice or behavior, make it a task for everyone involved to review and adapt continuously.

Also, in case a new practice or other change is not trivial, consider creating a first version and let it evolve. That is often better than overthinking the first version and not getting any benefits early.

Create an agile WoW backbone

Having seen quite a few teams applying Agile WoW, you can see that some elements are often present. In fact, some of these elements are needed to work Agile, regardless of the business strategy. I call them Agile backbone elements because you always need them. They help you with value identification, quality interactions inside cross-functional teams, planning just enough, executing at a sustainable pace, distributed leadership, customer collaboration, responding to change, and psychological safety. Here are my top-9 changes:

  • Move from projects to products

  • Create small, stable, cross-functional teams

  • Define your product/service in small chunks (e.g. epics and user stories)

  • Plan and execute with small increments (time-boxed or not)

  • Distribute leadership and decisions

  • Nourish your workplace culture

  • Adapt your work approach continuously

  • Build Agile skills

  • Adapt your environment and tools

Many of these elements should be quite high on any Agile WoW transformation backlog because they will literally give you a backbone. You need to organize your teams, define roles, set your cultural values, and decide how you align, plan and execute. rates on how to build an agile WoW backbone.

In this related post, I elaborate on each of the nine elements.

Build skills relentlessly

There are several reasons why it’s essential to increase learning when you are on an Agile WoW journey. We are changing roles, processes, and techniques. For example, for the new Product Owner role, you cannot assume that we can continue with our existing product management or business analysis skills because. Both the methods and collaboration styles are different, and you need to master that.

Also, since we work in small teams, it’s important that team members become more T-shaped. This means, having more knowledge and skills than only one specialized area. A wider skill set allows each team member to contribute to more tasks. And it facilitates collaboration with other team members with different roles or specialties.

Another really key point is that mindset, culture and collaboration are really important in Agile WoW. And to make that fly, we need more than hard skills. So you see that modern Agile WoW teams seriously invest learning in power skills for collaboration, leadership, creative thinking, and resilience.

Agile WoW is a continuous journey

We have seen that some systematic steps can help you to get started including:

1. Set a vision with desired strategic outcomes
2. Identify the Agile capabilities to support the strategy
3. Build a change backlog with elements that help to develop capabilities
4. Implement backlog items through change design, experiments, skill building, and coaching
5. Continuously measure and learn in order to always focus on the best next changes

The idea is to execute these steps iteratively. You should repeat steps 1 and 2 for each wave while the other steps should happen continuously.

While doing all this, look at the growing capabilities and outcomes. And try to measure them - quantitively or qualitatively. That will ultimately tell you whether you succeeded or not.


What’s next?

I hope this guide has given you a first complete overview and a feel for what is involved in introducing an Agile WoW. This guide should enable you to get started, organize your change efforts, and plan the first activities based on Agile capabilities.

In connected blog posts and courses, I cover many related deeper topics including:
- Agile vs. agility, and whether you need them both
- how to build Agile WoW backbone elements in detail
- client cases
- specific Agile capabilities and contexts (such as marketing and HR)
- Agile operating models - what are they and how do they help digital transformations
- how to organize and design Agile training programs
- how to make culture shifting happen
- how to build change resilience

Thank you for reading and please feel free to share your own experiences of Agile WoW journeys. Social learning is a powerful Agile practice!

 
ABOUT THE AUTHOR
Bruce Schoor
Bruce Schoor is an Agile/Digital coach, trainer, and transformation leader. After a track record at Microsoft, he has been globetrotting for the last 15 years upskilling and transforming organizations into Agile ways of working. Bruce shares these experiences through coaching, workshops, and e-learning at his AgileXL Academy.