9 Changes to Build an Agile Way of Working Backbone
10 min read
To keep up with increasing innovation, complexity, and changes, organizations are trying to find new ways to get better outcomes. Using an Agile Way of Working has proven to give impressive benefits for both customer experience, collaboration, and employee engagement. A study from digital.ai found that the adoption of Agile has increased from 37% in 2020 to 86% in 2021 for software development teams, and adoption has doubled for non-IT groups.
In a pragmatic guide that I posted last week, I have discussed steps and key factors to address when adopting an Agile Way of Working. But what exactly are you going to change to get there? Is there a recipe or framework that helps us implement a silver bullet? Even though each organization has unique objectives and context, we see a number of key elements that you find back in almost every agile WoW organization. In this post, we are going to look at 9 changes that help you build an Agile WoW backbone and that you should at least consider for your specific adoption effort.
Table of content:
Change #1: From project to product
Change #2: Small, stable, cross-functional teams
Change #3: Define your product/service in small chunks
Change #4: Plan and execute in small increments
Change #5: Distribute leadership and decisions
Change #6: Nourish your workplace culture
Change #7: Adapt your work approach continuously
Change #8: Build Agile skills
Change #9: Adapt your environment and tools
Change #1: From projects to products
Agile is focused on value creation for customers. The projects that we use in traditional ways of working are focused on execution results. These are two different things. By taking a product (or service) approach, you create a customer focus from the start. Moreover, products do not have start and end dates. Instead, we continuously build the highest value increments possible in order to build better outcomes.
As an example, a marketing team moves its focus from the execution of big campaigns to customer experience with a high number of smaller campaigns. In order to make such change work, you need to change your approaches to organization structure, requirements, and planning which we will also cover in this list.
Change #2: Small, stable, cross-functional teams that focus on customers
In traditional ways of working, we tend to define projects for a specific timeline and then staff the project with resources. The effort of (re)allocating resources is complicated when multiple projects are happening at the same time. In addition, we cause unnecessary complexity for budgeting. But what’s even more important: we never get to build optimal relationships and trust between team members because the team is too short-lived.
In an Agile Way of Working, we work in small, stable, cross-functional teams. Small sizes make teams lean and dynamic. Stable and long-lived teams result in better relationships and better knowledge of customers because that’s all they focus on.
Now we would like these small teams to be able to build value for customers in the form of a particular product or service area. For this to happen, we need a mix of roles and skills. So the way we compose teams is to staff them with people from different functional areas. And this is fantastic news. How many organizations aren’t crippled by communication overhead and handovers due to functional silos? Inside the Agile teams, communication is easy and there aren’t any handovers.
Change #3: Define your product/service in small chunks
In traditional ways of working, we like to work with huge projects for which we specify up-front the content that we need to build. This is actually inconvenient for several reasons. Defining everything up front only works well if we know everything perfectly, which is seldom true in today’s world.
Wouldn’t it be better if we define (and build) the product/service in small steps so that we break down complexity? In an Agile Way of Working, we almost always use small increments where we ask the customer for early feedback on these increments. Such feedback is super important because it helps us build the right product. And the customer receives value much earlier.
Another benefit of incremental requirements is that we reduce waste. We reduce a bottleneck at the start of activities because we do not have to build a complete set of requirements anymore. And the amount of ‘wrong’ requirements reduces as well because we detect them early.
A practical way to implement such an incremental way of defining is to use ‘user stories’. A user story defines a small piece of value that we want to build. It works for both software and non-software contexts. These stories are often written on sticky notes, often physical sticky notes while we are brainstorming, and in an electronic backlog once we start to plan and execute. More about backlogs later.
Change #4: Plan and execute in small increments
In an Agile WoW, we plan the minimum amount of work necessary to deliver the next high-value increments, rather than creating long-term plans. Agile teams often work with plans that span 2 to 4 weeks, depending on the context. You may have heard of the popular Scrum method that works with ‘sprints’. Sprints are timeboxes, often 2 weeks long, and teams only focus on what they need to produce during those 2 weeks. By the end of the 2 weeks, the team delivers ‘done’ stories that can be validated, demonstrated, or even delivered to the customer.
Scrum is not the only right approach. Many teams have success with Kanban where you plan and execute individual user stories in a continuous pipeline. But also in the case of Kanban, the amount of scope that a team focuses on is limited. We even use hard ‘work in progress’ limits on the number of stories or tasks that we can work on, and this practice alone proves to give huge benefits to avoiding resource over-utilization and bottlenecks. The reason why I like Kanban so much is that it creates an excellent flow. Stories are taken up by team members as soon as they have the capacity. Plus, the overhead of planning and tracking remains at a minimum.
Planning and tracking in small increments also are very convenient when you are in discovery mode, for example for a new innovative product or service. In an Agile WoW approach, we often borrow here some lean concepts such as Minimum Viable Products (MVPs) that are initially nothing more than hypotheses of what could bring us high value. You need to validate these hypotheses in the field and short, lightweight planning and execution cycles really help here.
Change #5: Distribute leadership and decisions
A key improvement thanks to Agile Ways of Working is that we recognize that local expertise is important. In real life, it’s not feasible for a manager to have the best knowledge of everything. In Agile, and also in lean, we like flow and dislike bottlenecks. So one change we can make is to keep the know-how and decisions in the same place. The concept of self-managing teams in the software world has been extremely successful. It basically means that a team can decide how they work.
For example, one team may like to communicate via Slack while another team likes virtual whiteboards. Autonomy is a key motivator and it give better results. One point to pay attention to is that you want to make sure teams stay aligned to the shared vision and purpose. As Henrik Kniberg explains really well, alignment enables autonomy.
Change #6: Define and nourish an agile mindset
What is an Agile mindset? An Agile manifesto with values was defined in the software world in 2001, and several people have made attempts since then to modernize this manifesto. I believe that there isn’t one complete and perfect set of mindset elements but as we are talking about the backbone in this post, I’d like to highlight two ‘backbone elements’ that have helped the team that I have worked with.
Respect and psychological safety are key elements for any Agile team. Agile WoW relies a lot on close collaboration and total team accountability, and respect helps to accomplish both. Psychological safety especially plays a role when the team works in unknown territory, for example when innovation or new technology is involved. In those cases, we have to recognize that failure can happen, and that failure is actually often the only way to progress as long as you learn fast.
Focus on value and customers is a second element. This is not only something you can just accomplish with processes or team structures. Mindset is equally important. And yes, by supporting that value with the right other changes, you can nourish or discourage that mindset in a team. One particular technique that I find useful is to stimulate this mindset is the use of nudges. Small hints, reminders, or other small actions that anyone in the team does during the day to keep this attention to customers and value alive help amazingly.
Change #7: Adapt your work approach continuously
A down-to-earth aspect of an Agile Way of Working is that we do not assume that we know the perfect work approach from the start. And this is what reflects real life. Healthy teams therefore get started and take the time to inspect and adapt continuously as they progress. Improvements and changes often come from feedback or retrospective sessions which are quite popular in Agile teams. Making changes to the way your work may also happen because the context changes. For example, if a team starts to have more dependencies on other teams as a product or service grows, maybe it is useful to make some changes to the way we define or plan.
I mentioned retrospectives as a tool to review what you are doing right and what improvements you could benefit from. As a coach, I recommend retrospective as one of the most important practices to put in place from the start. With a relatively small investment of time (e.g. 1 hour max. per 2 weeks), you ensure through collective feedback and brainstorming that you act on items that hinder you from doing better.
Change #8: Build agile skills
There are several reasons why learning needs to be intensified and made more continuous when you adopt an Agile WoW. The Agile WoW approach includes new roles, processes, techniques, and artifacts that we work with. 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.
Since we work in small teams that support a product or service item end-to-end, it is important that we get T-shaped team members who have more knowledge and skills than only one specialized area. That wider set of skills allows them to contribute in more tasks and it facilitates collaboration with other team members who have different roles or specialties.
Note also that even if your role is the same as before, it’s still important to keep up with new ways of working. For example, if we start to define using user stories in backlogs, we need to learn the related skills. How to create good stories with value, how to elaborate and split them, and how to organize and prioritize them in a backlog.
Another really key point is that mindset, culture and collaboration are really important in Agile WoW. And to make that function well, 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.
Change #9: Prepare your environment and tools
To support the above changes, some changes in the environment are needed.
For the environment, the most important change in my opinion - in case don’t have it already - is to have an open space that enables close team collaboration. That also holds true when you work remotely. Make sure that you can easily connect and see each other during your work day. I stress this necessity also because I see many remote teams fall into meetings-all-the-time and one of the main reasons is because that is the only way people know how to collaborate. So it’s important you allow for spontaneous conversations and whiteboard sessions, regardless of your location.
For the tools, I see two categories of tools that you need for your backbone: team collaboration and work management.
To beef up your team collaboration, ensure first of all that you have a solid team collaboration and chat space with tools such as Teams, Slack, Discord and/or Mattermost. In addition, equip yourself with tools that facilitate the use of whiteboards and sticky notes (such as Miro). Whiteboards and sticky notes are my favorite tools for Agile WoW and with tools like Miro you can continue to use them when you are remote or distributed. The whiteboards are really practical for brainstorming, prototyping, and retrospectives, especially when they allow for simultaneously editing.
For the second category, work management, we need again two tools. One that helps us track, and one that helps us manage content. Even though we call this work ‘management’, the idea here is that we all manage the work items, so it’s important here that we have easy-to-use tools. Some of the collaboration tools such as Teams already give you the content management including wiki’s. For efficiently creating and managing backlogs, epics and stories, with team task boards and metrics, Jira or Azure DevOps Server are good examples.
Thank you for reading! I hope this list will help in your Agile WoW journey. As a next read, this post may help you to learn from a client case how to organize your transformation activities and build that Agile WoW backbone In the meantime, do feel free to share your comments about any other changes that helped you with your backbone.
