9. Business Agility
Be open and have courage to experiment with agility at the organizational level.
Business agility and the agile organization are still very new concepts. “Business agility is not a specific methodology or even a general framework. It’s a description of how an organization operates through embodying an agile mindset” [Agile19]. Nowadays, most organizations are familiar with agile at the team level. Organizations from different industries are experimenting with it, implementing it, and succeeding with it. The level of agility differs by region, but it’s safe to say that most organizations have some experience at the team level—they have tried agile with at least one pilot project. Also, most new graduates are leaving universities with some level of agile understanding and experience, which indicates that agile at the team level has reached the late majority.1
Some organizations are already applying agility at the product level, delivering value end to end, and applying various scaling frameworks and cross-team collaboration models, but we are still at the early adopters stage, and not many organizations have implemented such a level of agility yet. However, many successful case studies have been published in which people talk about the impact of agile on the business, and the term business agility is picking up fast. As the Business Agility Report2 states, “Sixty-nine percent of respondents have been on the journey for less than 3 years” [BusAI18].
What is currently a hot topic is the agile organization, and without a doubt, we are still at the innovators’ stage—the pioneer green and teal organizations [Laloux14] have experienced amazing success with implementing agility at the organizational level. We talk about different organizational structures and cultures that operate under a different premise. They are value-driven, customer-centric, cross-functional. They care about people and create team-oriented cultures built on self-organization, autonomy, and decentralization. They change the way they work with people and invest in a different leadership style. In these organizations, all functions have become agile—agile finance, agile marketing, agile HR. It’s a whole new world.
Which parts of your organization are agile? (If any relevant parts of the organization are missing, add them to the list).
• Agile HR
• Agile Finance
• Agile Executive Team
• Agile Board of Directors
• Agile Development
• Agile Marketing
• Agile Sales
• ___________
What benefits would you see if all parts of the organization were operating in an agile way?
Radical Self-Organization
Pawel Brodzinski, CEO at Lunar Logic
People often ask me how we designed the transformation from a relatively flat but traditionally managed organization to what we call Radical Self-Organization. The interesting thing is that we didn’t. Right now, Lunar Logic is a company with no managers, where everything is transparent to all the employees, and everyone can make even the most serious decisions. As an example, anyone can set anyone else’s salary, including their own. There isn’t a single power reserved for the CEO. If the CEO can do it, everyone can.
And yet it is an accidental, or emergent, outcome. The initial changes we devised were small. Just a bit more transparency here and there. Fewer small decisions made by a manager and more by those who are affected. The big change was, indeed, the persistence and alignment of small changes. We were continuously distributing more and more autonomy across the board.
There were, of course, a few huge steps among many small ones. One of them was introducing a new salary system in which the payroll is transparent, and everyone can influence what anyone earns. Such a move can’t be undone. You can’t make people forget the data they know. We were preparing for this move for ten months, addressing all the concerns along the way.
Only a couple of years into this continuous experimentation with the organizational model, I started asking the question, If we keep doing this, what is the end game? Only then did I envision that, fundamentally, there is no ceiling for embracing autonomy and self-organization in every aspect of the company life. The realization swayed our perspective from thinking of what we wanted to change next toward thinking of what decision-making powers still need to be decentralized. The journey, in fact, never ends. Even once all the formal power has been distributed, we still need to support everyone with embracing and using it.
Of course, it isn’t as easy as giving people more autonomy. On the way, we learned the role of accountability, alignment, well-defined constraints, and technical excellence. We keep learning how to balance all the facets of an organization operating without managers. We reinvented hiring, changed how we work, and right now, we are reestablishing our strategy together.
Was it worth it? Totally. And it’s not just my subjective opinion that Lunar Logic is a much more humane workplace than the norm. We can measure it too. The average tenure is twice the industry standard. The perceived engagement is 75 percent up. Our financial results skyrocketed. Had someone told me at the beginning that this would happen, I wouldn’t have believed it.
Agile at the Executive Level
Agile can’t stay just at the product development team level. Every agile transformation not only changes the way teams deliver but also creates a disturbance and a gap between the management and employees. And the more agile the teams are, the bigger the disconnect that is created. Managers feel lost, forgotten, and they start to fear that those self-organizing teams might eventually not need them. One problem is that they’ve never been part of any agile or Scrum team themselves. They’ve seen them working, have joined teams for reviews and listened to their stories, but that’s not the same. People need the experience to understand a different way of working. You might still remember your first reaction when someone told you that this agile and Scrum method will be great. What? you thought, this silly process will never work! Speaking for myself, I still remember how I felt several years ago when we were exposed to agile. I didn’t like it, and I was not a supporter of it at all. Many people feel the same way as I did, and the same thing that was beneficial to me can help them as well: experiencing it for themselves.
One important step companies often skip during their agile transformation is getting top management on board. Executives deeply need their own experience with agile and Scrum. They can’t just read about it. If you really take the agile transformation seriously, it’s time to change the way you implement it. It’s not just a different process decided by C-level executives and implemented without their notice. It’s a significant change in the culture and mindset that needs us to start from the other side as well, forming self-organizing teams of executives. On your organizational agile journey, executives need to experience agile and Scrum; otherwise, the disconnect becomes bigger and bigger, and the gap between the agile-mindset teams and management grows until the whole organization becomes like a broken washing machine, spinning around in short cycles without delivering any real results.
There is no doubt you need agile team experience at every level. Very often, by design of the roles, a team starts as a group of individuals with their own goals, no common passion, no trust, and no unifying purpose, and then, step by step, they experience what self-organization is about, how cross-functionality works, and how this way of working is different and awesome once they embrace it. Applying Scrum at the executive team level is a great practice that helps people to understand the business value and prioritization and learn how to do refinements, planning, standups, reviews, and retrospectives, just like any other team in the organization. They get used to delivering value regularly, iterating, and getting feedback and collaborating. In the same way that a first pilot project is difficult for a product development team, it is hard—often even harder—for the executives, and without a strong sense of urgency and a strong enough reason for change toward agile, neither the organization nor the executive team can be successful in their agile journey. This hands-on experience is critical for organizational success.
Like any other exercise, getting started is difficult. Most managers at the beginning of the agile journey would say, “Other people need that, not me.” But I don’t think so. Leaders need to change first. The organization will follow. The first time you experience the power of true team spirit, you never want to go back, no matter where you are in the company org chart. It works the same way across the structure.
If you are ready to try, the first step is to get a real agile coach, not a consultant. Find someone who will guide you on this journey, someone who has embraced this way of working and will help you to overcome day-to-day obstacles, who will guide you toward agility without taking the steps for you, and who won’t sell you any simple recipe for success. The goal is not a speedy transition to agile; it’s to get hands-on experience with this different way of working.
Where on the scale of 1 to 10 would you place the executive team of your organization currently?
The farther on the right you are, the higher chance your organization is going to be successful with agile.
The CEO in an Agile Organization
Searching for a CEO with an agile mindset is frankly a nightmare. Everyone who’s tried it can confirm that. There are not many CEOs with enough agile experience yet in the world, and those few who have it are likely not looking for a job, as they are usually quite happy in their current organization. So, no matter which executive search firm you choose, or what you write in the position description, the search firms are no real help here. Unless you’ve already expended effort up front on growing the talent internally, you’ll need huge luck to get someone who has more than a basic understanding of agile.
No matter how desperately you are searching for a CEO, this is still just a small obstacle. The real need for change starts only when most of the organization already has an agile mindset. Since organizations have changed and agile is no longer solely the domain of IT, and since business agility has gained acceptance in nearly every department, the need for a change at the top level is inevitable. Why do we need a CEO in the first place? Why don’t we go one step further and change the top to become a role model for the entire organization? Shouldn’t we change the entire way we work? Shouldn’t the C-suite apply the same principles the teams do? Sounds like simple logic. And, as usual, it is simple to understand but hard to do because it requires courage—the courage to say, “We are going to be different. We will have an organizational ScrumMaster and an organizational Product Owner instead of a CEO because it is closer to the way we work at this organization, it fits our values, and last but not least, we believe it will help us to be more flexible and adaptive at the organizational level.” And that’s worth trying.
The organizational ScrumMaster focuses on the right culture, mindset, and structure so that the company becomes a high-performing, innovative organization that embraces agility. The organizational Product Owner focuses externally on the business and shapes the company’s purpose so that everyone knows where the company is heading and why and to ensure the organization is business-value driven. Both roles need to respect each other and be open with each other, as is the case in a single Scrum team, because together they will be part of the organizational team and the network structure of self-organizing teams. In Scrum, there are two roles instead of one for a reason. When you ask people if they would recommend combining the two roles, they answer, invariably, that it’s not a good idea. The same reasons that make us say it’s practical to have two different roles are valid at the executive level as well. When you think about it, having an organizational ScrumMaster and an organizational Product Owner fits the way we work much better than having a single CEO, as it supports the right organizational mindset, transparency, and collaboration, and it is consistent with who we are.
From a legal perspective, it is perfectly possible, and it’s not that much work either. You might need to change the bylaws a little, but there is no reason why you can’t do it. From a hiring perspective, it’s much simpler, as you are not looking for that superhero personality who can effectively interact with both internal and external sides. There is nothing preventing you from doing it. As I said earlier, all you need is courage. And that’s one of the Scrum values anyway. Experiment, and then inspect and adapt.
Now, do I believe that the organizational ScrumMaster and the organizational Product Owner will eventually make themselves redundant when the teams become self-organized? No, I don’t. It’s the same as at the team level. Even if the team is self-organized and knows the business well, there is still work for the ScrumMaster and the Product Owner. Similarly, at the organizational level, there is a need for the organizational ScrumMaster and the organizational Product Owner even after the network of collaborative teams becomes self-organized, business value-driven, and customer-centric. The organizational ScrumMaster and the organizational Product Owner would use the leader-leader style to help other leaders around them to grow, and in due course, the organization would become purpose-driven, with emergent leadership and a liquid organizational structure. Like in a Scrum team, the organizational ScrumMaster and the organizational Product Owner would then progress from explaining, telling, and sharing to coaching, facilitating, and keeping the system spinning [Šochová17]. And that’s what agile leadership is all about.
The Scrum Alliance was looking for a CFO with an agile mindset for almost a year, which seemed like forever. It was a long journey, and no one was living up to the goal of “transforming the world of work” and building “sustainable agility.” All the traditional executives lacked a deep understanding of the agile mindset, and all the agilists lacked the executive experience. In the end, the idea of applying Scrum at the organizational level was a game changer. By having an organizational ScrumMaster and an organizational Product Owner instead of a CEO, the entire executive team as well as the entire organization went flat. People always ask what difference agile can make, but in this case, the outcome was almost instant. The organization transformed into several customer-centric, cross-functional, self-organizing teams and started delivering value almost instantly. The focus shifted toward finding alliances rather than competing, and we became the thought leader on the agile space once again. It was a bold experiment, changing the entire way the organization operated and was structured. But so far, so good.
Living up to your values will pay back.
The journey so far of being a PO with a SM in co-leading Scrum Alliance has been great. I cannot imagine now not having a co-leader to do this job. By allowing each of us unique focus areas (myself external customer and on strategy, and Melissa [Boggs] on internal team building and organizational strategic structure) it’s allowed us to really play to our strengths. I don’t have to be all things to all people, because WE together fill the role of a traditional CEO.
—Howard Sublett, Chief Product Owner, Scrum Alliance
Agile Board of Directors
Are you wondering why you should be agile while your board of directors is not? There is no reason why the board of directors should not act as an agile team. However, as is true for people at every level contemplating a new way of working, change is scary. Most of the board members would be coming from traditional companies and would have no experience with agile. Governance is important, but the usual committee structure presenting a report to the board each quarter doesn’t prepare board members to react to challenges. First, let’s start with an overview of what any agile entity needs: the agile values of transparency, trust, respect, collaboration, and a shared understanding of purpose so that people have the same goals. The idea is to be a great team, not just a group of individuals. But applying radical transparency, getting feedback, and collaborating are often very hard at this level. Not that it wouldn’t be useful, but it’s not easy. Second, the board must be consistent with the organization. If agile stops at the board level, it creates a gap between the organization and its governance, and the whole organization will struggle. Finally, agile boards are not just governance bodies—agile boards of directors create purpose-driven organizations with a sense of belonging, which skyrockets organizational success. It’s critical that agile boards collaborate on the key strategic initiatives with the rest of the organization, which, if you think about it, is a huge step away from filtering everything in and out of the board through the CEO. The agile board of directors’ focus is on three principles: team, flexibility, and strategy.
Team over Individuals and Hierarchy
While traditional organizations are formed by stable departments and individuals, agile organizations form communities built around the purpose. Internally, there is usually a quite liquid structure to keep adaptivity and strategy focus in our complex world. It embraces the team as the key building unit and forms a collaborative network of teams. Similarly, the board of directors is a team that has one goal. Even if internally there is a structure of committees, each committee is a collaborative team as well, and all committee chairs and the board chair act more like facilitators than managers of the group. The board as a team is just a small part of the whole picture. We use the “team in the team” concept in Scrum—the development team is part of the Scrum team, which is part of the product team once it scales, and the product teams are part of the entire organization, which acts as a team, or collaborative network, in which all those pieces stay together only because of a strong purpose and a common goal. The same way that the board forms a collaborative team with the CEO, the board and the CEO would form a team structure with management and eventually with the entire organization. Too much hierarchy kills the collaborative mindset and team spirit. In the majority of organizations, there is always going to be some hierarchy, but maybe the way of working could be driven not by the hierarchy but by a common purpose and collaboration, with radical transparency as a prerequisite.
Flexibility over Fixed Plans and Budgets
The more we are responsive to changes through collaboration, the higher the need for adaptiveness in the organization. Agile organizations are moving from yearly fixed budgets toward the Beyond Budgeting principles [Beyond14a] and toward purpose-driven continuous planning over annual top-down fixed goals and plans. You will see more volunteer-based virtual teams over fixed departments and, at the board level, more transparent and collaborative committees. People are grouping around the common cause instead of the fixed plan, while planning itself becomes a continuous inclusive process instead of a top-down annual event. Anyone should be invited to join when they have something to add to the purpose of the event. Keep it transparent, inclusive, open. All you need is an iterative process with regular feedback and an opportunity to inspect and adapt.
Strategic over Operational
A good board of directors should be focused 80 percent on strategy and significant business issues and only 20 percent on reporting. Nothing new, right? It’s the same old 80/20 rule we often use in agile product ownership. Agile boards are going through a significant shift, refocusing on the strategic over the operational. Don’t get me wrong, governance is important, just as the importance of processes is noted in the Agile Manifesto:3 “While there is value in the items on the right, we value the items on the left more” [Beck01b]. The same applies here. Reporting is part of transparency—an almost unnecessary part because transparency makes all of the information available to everyone at all times. The board wouldn’t have to meet to get a status report. They should be meeting to discuss strategy, understand one other, have creative conversations and visionary sessions, give feedback. The boards should meet frequently, every one or two months (that’s their Sprint time), and should focus on communication and work between meetings. There is no need for reporting—all documents should be visible, so the meetings are reserved for conversations about the direction. As in the product environment, the shorter Sprints generate better understanding, feedback, and higher delivered value. Finally, keep in mind that the less fixed the structure and the plan, the higher the need for good facilitation, as without it you might end up in chaos.
From Outputs to Outcomes: A Board’s Journey with Business Agility
Sandra Davey, Chair, Board of CHOICE, www.choice.com.au
At a company board that I serve on as a professional director, we never decided to “go agile” or do an “agile transformation.” That wasn’t our language, our plan, our intention. It happened slowly with many triggers, and one of them was a realization of the disconnect between how the board was thinking and responding and how people in the organization were thinking and responding. Staff were working agile; the board’s first taste was seeing a shift staff’s focus from outputs to outcomes. Our people were rallying around outcomes or goals to achieve the change they wanted, and the challenge we now had was that the information coming to the board hadn’t caught up to reflect this fundamental change.
In the context of how the organization planned and allocated resources, there was a disconnect; the board was rallying around information and material in the form of traditional business plans, sixty-five items in this particular year, full of outputs, features, and dates (how and when), and yet the teams had moved to rally around goals and outcomes (why and what).
Here’s a typical example: an item on the business plan in the board papers would describe an output: “By Q4, deliver a mobile app to help Australian citizens select the best health insurance plan.” This type of information encouraged the board into “telling” or “instructing” mode and into the weeds; we’d soon be scrutinizing the detail with questions such as When are you delivering the health insurance comparison app? A board’s contribution shouldn’t be in the operational detail; it needed to be more strategic. Upon agreement with the Leadership Team, the board started using the OKR framework,4 liberating us from detailed “how and when output-based” conversations to more strategic discussion focused around outcomes. Instead of demanding that teams build a mobile app for health insurance comparison by Q4, the board focused on discussing the big issues affecting Australian consumers. Instead of asking for a “thing,” we began describing problems: How might we enable Australians to seek out the best health insurance plans for their needs? Describing outcomes, goals, and problems liberated the board from unnecessary detail but, importantly, left the organization to figure out the best way to get there and by when.
OKRs help us describe outcomes, not outputs. They help us describe outcomes as aspirational goals, leaving the people and teams to describe the key results, or what success might look like. Gone from board papers are detailed business plans, and in their place, three or four key OKRs that teams within the organization can rally around. These OKRs are companywide, thus keeping the board at a strategic level and leaving the organization to the tactical operational detail. OKRs have fundamentally improved the quality of the conversation at board meetings, keeping us focused on strategic outcomes and, importantly, liberating the people and teams to figure out the best way to get there.
Books to Read
Evolvagility: Growing an Agile Leadership Culture from the Inside Out, Michael Hamman (Lopez Island, WA: Agile Leadership Institute, 2019).
Outcomes Over Output: Why Customer Behavior Is the Key Metric for Business Success, Joshua Seiden (Brooklyn, NY: Sense & Respond Press, 2019).
In a Nutshell
In agile organizations, all functions have become agile: agile finance, agile marketing, agile HR. It’s a whole new world.
In order to succeed with agile, you need experience with the new way of working at every level, including executives and boards of directors.
Agile organizations work better with organizational ScrumMaster and organizational Product Owner roles than with the traditional CEO role.
1 A concept in the diffusion of innovation theory described by Everett M. Rogers in 1971
2 The Business Agility Report surveyed a diverse range of organizations representing twenty-nine countries, across twenty-four industries, and ranging in size from 4 to 400,000 employees. The only consistent factor between among is a common goal: to become an agile organization. Some have just started the journey, while others have been leaders for nearly a decade [BusAI18].
3 The Agile Manifesto of Software Development consists of four principles we value, the first of which is “Individuals and interactions over processes and tools.”
4 Objectives and key results (OKR) is a goal-setting framework for defining and tracking objectives and their outcomes.