Some people decide to start a long journey, skipping the introduction, chapters 1, 2, and 3 and they go straight to the middle of the book, losing pieces that will not be possible to recover. Some of these pieces help you to truly understand the context and the problems you face throughout the journey.
It’s like starting a game, going straight to level 4. But in this level, we face enemies that depend on combinations and magic powers, which the game character was just developing the first few times in level 1 and, as we don’t know what we need to do, we end up getting stranded in the game. And to be honest, I think that it’s impossible to “play any game” in real life without knowing the foundation that supports the knowledge, tools, skills, techniques, and shortcuts.
Learn to walk before you start running.
And that’s why this site wants to invite you to understand more about all the concepts that are around the subjects and themes we discuss here, supported on the shoulders of giants. So, I’ll be inviting some friends to write some articles on very important topics, which need to be learned.
Today we will better understand business agility with Rafael Calovi.
Rafael Calovi is an Enterprise Agile Coach who has shared very interesting articles about Lean and Agile, explaining the systems that enable and create the Lean Thinking and Agile Mindset.
At the end of this article, I will list Rafael Calovi’s articles, so you can learn even more.
So, here we go…
… With Rafael Calovi:
One of the hottest buzz words at the moment is ‘Business Agility’.
Paradoxically, this expression is most often mentioned and discussed within IT people circles.
Also, most if not all frameworks that are used to scale agile teams claim to – and I’m sure that some successfully – to be oriented to promote Business Agility.
These 2 things combined lead to a great misunderstanding: that Business Agility is an IT concept that requires scaled agile teams to work.
“… The need of the hour is business agility, not just delivery process and engineering agility or even IT agility. Both business and IT agility need internal organizational agility. In the context of this book, organizational agility is internal facing—it serves all members of an organization. IT agility serves the business. Business agility serves the market. Organizational agility is essential for IT and business agility…” – Sriram Narayan, Agile IT Organization Design
But let me tell you: there’s a good reason for the word ‘Business’ in Business Agility and you don’t need to scale agile teams to achieve it.
As a matter of fact, scaling agile teams before you understand Business Agility will likely result in your organization investing their time, energy, and resources in something that will not improve the flow of value (or simply put ‘waste’).
But I’m getting ahead of myself – what the heck is Business Agility in the first place?
According to…
Business Agility Institute: it’s “a set of organizational capabilities, behaviors, and ways of working that affords your business the freedom, flexibility, and resilience to achieve its purpose.”
© Scaled Agile, Inc.: it’s “the ability to compete and thrive in the digital age by quickly responding to market changes and emerging
opportunities with innovative, digitally-enabled business solutions.”
Wikipedia: it “refers to the rapid, continuous, and systematic evolutionary adaptation and entrepreneurial innovation directed at
gaining and maintaining competitive advantage.”
These are all great definitions, carrying tons of meaning compressed into small sentences.
What I’ll do here is to unzip – or ‘decompress’ for the young folks 🙂 some meaning from these definitions to make it clearer for you.
Business Agility begins with ‘Business’
One of the things you’ll notice when talking with organizations running initiatives to promote Business Agility is that most of them will begin focusing on the ‘Agility’ part and only then move on to the ‘Business’ part – meaning that they will prioritize the adoption of Agile practices within the IT teams and later on begin involving the Business Team.
Are you familiar with this approach? I’m sure you are.
The main problem with this approach is that it contributes to solidifying the illusion that Business and IT can be taken apart and optimized individually to improve the Enterprise.
Russell Ackoff, one of the greatest minds on Systems Thinking once said: “A System is never the sum of its parts; it’s the product of their interaction. The performance of a system doesn’t depend on how the parts perform taken separately, it depends on how they perform together – how they interact, not on how they act, taken separately. Therefore, when you improve the performance of a part of a System taken separately, you can destroy the System.”
Take a look at this short explanation directly from him (starting at 5:00):
If you still believe that “a System is the sum of its parts”, then what if I handed you the parts below and say: here’s a pocket watch. Can you tell me what time is it even though you have all the parts?
The realization that an Enterprise (a Business) is a System is paramount for the understanding of the concept of Business Agility.
As an Enterprise grows it’s only natural that it begins to create areas of specialization and leaders for each of these areas (such as HR, Finance, Marketing, Sales, IT, and so on).
But then, at some point in the growth path of the Enterprise, these different areas may begin to see themselves as Enterprises of their own.
Silos form within the company as the parts of the System begin to forget the importance of their interaction with other areas, focusing on simply improving their ability to generate outputs.
These Silos begin to believe that maximizing their own performance will certainly be positive for the company.
Just like a car manufacturing company where a team responsible for producing parts for a specific model improved their process in such a way that they now quickly generated tens of thousands of high-quality, cheap, and totally useless parts since that particular model was set by Marketing and Sales teams to be decommissioned in the next year due to low sales.
You cannot optimize the parts of a system and expect to improve the whole.
Unless the people leading the Enterprise realize that the Enterprise is a System, and thus NOT the sum of its different areas or units but instead the product of their interactions, any attempt to achieve the promised definitions of Business Agility will certainly fail.
Now that it’s clear that we should not promote changes to the parts alone without first realizing how these parts interact with each other, our next step in our Journey is to better understand these interactions.
In order to do so, the very first step is to understand what are the outputs of our System that are responsible for the generation of Value.
Understanding how Value is generated in our organization is key. This process is called “Value Stream Mapping” (VSM), and it consists of identifying the steps from a Business Operation perspective that are performed after a given trigger is fired, resulting in the generation of value.
It’s very important that when we talk about Value here, we’re talking about real value. The thing that ‘brings home the bacon’ to our company, that allows it to pay our salaries.
Also important is not to fall into the trap of limiting the concept of Value to the boundaries of a specific area or segment (a Silo) in the company.
Back to our car manufacturer example, Value would be something like “fulfill a customer order”, and certainly not “manufacture as many parts as possible to be used in the assembly of cars”.
Each organization will have its own definition of “Value” and possibly more than one Value Stream.
During this process, it will become clearer how the different areas (Silos) in our organization interact (or should interact) in order to generate Value.
For more information on (Operational) Value Streams, please take a look at this page from Scaled Agile, with lots of examples and some more detail.
The main idea for identifying and mapping the Value Stream is to (first) identify what Value is in your context and (second) how it’s generated across the different units, business areas, etc.
The Value Stream (VS) from now on becomes our System, and therefore we’ll use a systematic approach to optimize it, improving its ability to generate Value.
Improving the System with Agility
When we talk about Agility, we are actually talking about a ‘Lean-Agile’ mindset.
From a Lean perspective, we should now focus on creating a strategy that will promote Flow Efficiency in our Value Stream by continuously addressing existing bottlenecks, eliminating activities that do not contribute to the generation of Value, and looking for alternatives to reduce (and possibly eliminate) wait times such as the need for external approvals or handovers.
This is a great challenge since during the formation of Silos it’s very common that Resource Efficiency becomes more important than Flow Efficiency. In other words, believing that it’s acceptable that we are more concerned with being efficient at producing car components than actually delivering cars.
Lean will ensure that will be prioritizing Flow Efficiency first and only then looking to improve Resource Efficiency, with as little impact as possible on the Flow Efficiency, and knowing that it’s impossible to excel at both. For more details on Lean, I strongly recommend you to read ‘This is Lean’.
So now we understand what our System is, we have identified some good improvement opportunities aligned with our strategy to improve flow (more efficiently generate our Value) and now we need to get to implementing these changes into our System.
It’s time for the Agile Mindset.
We have this backlog of improvements in our System we want to make. This backlog also contains some new capabilities desired by our customers for the products or services that our VS provides.
Since we’re talking about improvements from a Value Stream perspective, that probably means that each of these improvements will then be broken down into smaller, more tangible pieces to be processed by the different teams that are organized around our VS. We can use the concept of a Lean Portfolio to manage these higher-level backlog items.
We’ll use agile practices to organize, refine and prioritize this backlog, making sure we have the right people involved in this process.
We’ll use Kanban principles such as “Visualize the Workflow” and “Limit WIP” to manage the work that will go into our teams.
We’ll need to identify who are the people who have the right skills to implement these changes, as most of them will result in changes or new Features to the Solutions that support the VS.
Teams will organize their work into small but still valuable batches, aligned with the higher-level VS initiatives. They will work in the shortest sustainable iteration cycles in order to promote rapid value delivery and learning.
We’ll be using alignment tools such as OKRs to ensure that each person working around the VS understands how the work they do connects and support the Business Strategy.
We’ll create specialized roles for the VS untethered from the existing company functional hierarchy and job titles, such as the Business Owner or the Product Manager.
They will be relentlessly looking for opportunities to bring innovation, experimentation, customer centricity mindset, and constant evolution required for survival during the digital age. They will be supported by Lean-Agile teams that will use the above tools and practices (and many, many others) to deliver high-quality solutions in the fastest sustainable time.
And finally, depending on how many people we have working together to promote the required improvements to our Value Stream there may be the need to scale our Agile Teams, promoting alignment, and improving communication and integration among so many people.
Did you notice that scaling our Agile Teams was one of the last steps in this explanation?
I hope that by now you realize how many things can go wrong if you start your Business Agility journey by scaling Agile Teams. Without first properly educating the Leadership on the main concepts of Systems Thinking, Lean, Flow and Agile. Without first identifying the Value Stream in your Business and having the people and Teams organized around it despite the existing Silos or functional hierarchies.
By failing to do so you’ll inevitably end up optimizing only parts of your System thus not achieving the full potential promised by the Business Agility definitions that were presented at the beginning of this article.
Some additional reading you may be interested in after reading this article:
I am incredibly grateful that you have taken the time to read this post.
Do you want to get new content in your Email?
Check my main categories of content below:
- Agile
- Blog
- Book Notes
- Career
- Leadership
- Management
- Managing Yourself
- Productivity
- Project Management
- Technology
- Weekly Pulse
Navigate between the many topics covered in this website:
Agile Art Artificial Intelligence Blockchain Books Business Business Tales Career Coaching Communication Creativity Culture Cybersecurity Design DevOps Economy Emotional Intelligence Feedback Flow Focus Gaming Goals GPT Habits Health History Innovation Kanban Leadership Lean Life Managament Management Mentorship Metaverse Metrics Mindset Minimalism Motivation Negotiation Networking Neuroscience NFT Ownership Parenting Planning PMBOK PMI Politics Productivity Products Project Management Projects Pulse Readings Routines Scrum Self-Improvement Self-Management Sleep Startups Strategy Team Building Technology Time Management Volunteering Work
Do you want to check previous posts about Project Management? Check these from the last couple of weeks:
- How Volunteering in Project Management Can Boost Your Career
- PMI Pulse of the Profession 2024 Key Insights
- The Art of Integrating Project Management and Product Management
- AI Synergy: How Artificial Intelligence Enhances Project Communication
- The Next Wave: Project Management Trends in 2024
Support my work by sharing my content with your network using the sharing buttons below.
Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee:
