https://nkdagility.com/resources/5H9rOGhTB88 copied to clipboard!

Leadership Social Technologies

tech·nic·al·ly agile

Empowering Teams to Tailor Their Processes: A Path to True Agility

Empower your teams to adapt processes for greater value! Discover how to break down silos and foster innovation in this Agile reality check.

Published on 26 July 2024

Written by Martin Hinshelwood

6 minute read

https://nkdagility.com/resources/5H9rOGhTB88

In today’s fast-paced and ever-changing business environment, agility is more than just a buzzword—it’s a necessity. Yet, many organizations fall into the trap of enforcing rigid, one-size-fits-all processes that stifle creativity, innovation, and efficiency. Let’s explore why it’s crucial to empower teams to tailor their processes to their unique contexts, even if it means deviating from company-wide standards.

The Power of Tailoring Processes

One of the most critical questions to ask leadership about their way of working is whether their teams are empowered to change their processes based on what they learn. This is not just a theoretical exercise—it’s a practical necessity for any group of people to work as effectively as possible.

Why One Size Doesn’t Fit All

Every team is different. Even if two teams are working on the same product, their approaches may need to vary to maximize their effectiveness. While general guidelines, like how to interact with customers or the cadence of delivery, are essential, these should not be rigid constraints. Instead, teams should be empowered to adjust their processes based on their unique challenges and the lessons they learn along the way.

For example, what works for Team A might not work for Team B. Forcing a uniform process across diverse teams can lead to unnecessary waste and frustration. Empowering teams to tailor their processes can significantly enhance their ability to deliver value.

Real-World Consequences of Rigid Processes

I’ve seen firsthand how rigid processes can create waste and hinder innovation. Early in my career, I worked at Merrill Lynch, where a “one-size-fits-all” approach was imposed across the organization. This approach, driven by the needs of a trading desk, became the standard for every software development project, regardless of its relevance.

A Case of Overkill: My Experience at Merrill Lynch

At Merrill Lynch, I was tasked with building a small CRM system for a team of about 20 salespeople. The system was straightforward: a desktop application that allowed the team to quickly access customer information, make calls, and log interactions. However, the process imposed on us was anything but simple.

Here are some of the constraints we had to work within:

Architectural Sign-Off: Before starting, we had to get the architecture signed off, and any changes required additional approvals. This meant that even minor adjustments had to go through a lengthy review process, causing significant delays.
Pentesting Requirements: Although our system was internal and the data had minimal security implications, we were required to conduct a full pentest, costing us $20,000. This was an unnecessary expense for a system with low risk.
Infrastructure Overhead: We had to deploy the system across multiple environments (Dev, Test, UAT, Production), each requiring its own set of servers. The monthly cost for this infrastructure was about $33,000—an exorbitant amount for a system used by just 20 people.

These constraints led to significant waste and frustration. Instead of focusing on delivering value to the customer, we were bogged down by processes designed for a completely different context.

The Pitfall of a “One-Size-Fits-All” Approach

The situation at Merrill Lynch is a perfect example of how a “one-size-fits-all” approach can lead to waste. The processes that were valuable for a trading desk were overkill for a small CRM system. This inflexibility not only slowed us down but also cost the organization money and delayed delivering value to the end-users.

Moreover, our team was adopting modern engineering practices, including continuous delivery. However, because the organization’s processes did not accommodate this approach, we were penalized. For instance, if we didn’t submit a change request for deployment more than six weeks in advance, it was considered an emergency, and we received a “black mark” against our name. This punitive approach was counterproductive and discouraged innovation.

The Importance of Empowering Teams

The story above highlights why it’s crucial for teams to be empowered to change their processes based on what they learn. This empowerment is the foundation of true agility. When teams can adapt their processes to their specific context, they can:

Maximize Value: By tailoring processes to their needs, teams can focus on delivering the most value to customers.
Minimize Waste: Empowering teams to eliminate unnecessary steps or overhead ensures that resources are used efficiently.
Foster Innovation: When teams are free to experiment and adapt, they are more likely to develop innovative solutions to complex problems.

How to Assess Your Organization’s Agility

So, how can you assess whether your organization is truly agile? A tool I’ve found helpful is the U.S. Department of Defense’s “Detecting Agile BS” guide. This guide poses six critical questions to determine if your organization is genuinely practicing agility or just going through the motions.

Six Key Questions for Self-Reflection:

Are your teams empowered to change their processes based on what they learn?
Does your organization support continuous delivery and modern engineering practices?
Is there a culture of experimentation and learning, where teams are encouraged to try new approaches?
Are teams held accountable for delivering value, not just following a process?
Is there a focus on minimizing waste and maximizing value?
Does your organization reward innovation and continuous improvement?

If the answer to any of these questions is “no,” then your organization may not be as agile as it thinks. But this isn’t about pointing fingers or assigning blame—it’s an opportunity for self-reflection and improvement.

Moving Towards True Agility

True agility isn’t about blindly following a set of rules or adhering to a rigid process. It’s about continuously learning, adapting, and improving. It’s about empowering teams to make decisions that maximize value and minimize waste. And most importantly, it’s about creating an environment where innovation and creativity can thrive.

Practical Steps to Empower Your Teams

Here are some practical steps you can take to empower your teams:

Encourage Experimentation: Allow teams to try new approaches and learn from their failures. This creates a culture of continuous improvement.
Minimize Bureaucracy: Reduce unnecessary approvals and processes that slow down progress. Trust your teams to make the right decisions.
Tailor Processes: Recognize that different teams have different needs. Allow them to tailor their processes to their unique context.
Focus on Value: Shift the focus from following a process to delivering value to the customer. Measure success by the value delivered, not by adherence to a process.

Final Thoughts: The Path to True Agility

Empowering teams to tailor their processes is not just a nice-to-have—it’s essential for true agility. When teams are free to adapt and innovate, they can deliver the most value to customers while minimizing waste. So, take a step back, reflect on your current practices, and ask yourself: Are we truly agile, or are we just going through the motions? By empowering your teams and embracing true agility, you’ll not only improve your organization’s performance but also create a more fulfilling and engaging work environment for everyone involved. And that’s a win-win for both your teams and your customers. 🚀

Another key question to ask leadership about their way of working is if their teams are empowered to change their processes based on what they learn. This is one of those critical things that, in order for a group of people to work as effectively as possible, that doesn’t mean they work like another team working on the same product or another team working on a different product. It means that every team, although we’re going to perhaps follow some general guidelines about how we want to do business with our customer, perhaps that represents the cadence of delivery to our customer, we need teams to be empowered to change their process based on what they learn.

Because just because you’ve decided that something needs to be a certain way, doesn’t mean that that adds value to this team. It might actually be waste for Team A while it is value for Team B. We need to recognize that we want to maximize the amount of value that teams are able to create, which means we need to minimize any waste. A great example of that is I used to work for an organization; I was an employee of Merl Lynch back in the day. Because they had a trading desk software within the body of their organization, there were certain processes that had to be in place for all software in the organization, even if it had nothing to do with this trading desk bit.

So the trading desk defined those processes, and everybody had to follow them. I was building a small CRM system for a group of about 20 sales folks who were making calls, calling people up selling the mortgages. What they wanted was a way to tapy interface, pop the call, running it on my desktop or my laptop, and I’m able to click, see the phone numbers, call them up, see notes, that kind of just a simple CRM system. In order to deliver that, I had a whole bunch of constraints that I had to work within. One was that I had to have the architecture signed off before I started, and any changes to the architecture needed to be signed off as well.

So if you think about it, as you’re building the product, you can’t go, “Oh, actually that architecture I thought I was going to use is wrong; I need to do something different.” It all has to go through an architectural change review board, right? Central environment, and it was very time-consuming. They didn’t get back to you within a few days; they got back to you within a few weeks or a few months because they maybe only sat once over a period or they had a backlog of work.

That’s one thing for a small system that doesn’t have a lot of consequence or any consequence for the rest of the business and only affects a small number of people. That’s a little bit of overkill. I also had to have all of the systems that I used, even though they weren’t publicly facing, pent tested. So we had to pay an external company about $20,000 per pentest to pentest our system, even though it was internal and the data was of no consequence. It’s not the trading desk system; it’s a small data set for a small group of people. Yes, it has some PPI, but from a risk value factor, we probably could have done a lot less security overture and still provided on the compliance for the PPI external PPI compliance site.

So that was a bunch of waste that we couldn’t change. When I had to deploy to an environment, I had to have three servers: front end, middle tier, back end. The database had to run on one server; I had to have a separate server for the middle tier, the API, so it had to have APIs that were available, and then the front end had to run on a separate machine. You had to have those three servers as part of that mix, so you had to pay for them. It worked out about $33,000 per month for those three.

Then you had to have a dev environment, a test environment, a UAT environment, and a production environment. That was $3,000 per environment, and I had to have four environments for a little system that was just used by 20 people in a call centre. Total overkill, total waste for what it was. Those were processes that were imposed on us from the rest of the business. Even worse, we were doing continuous delivery, and in the organization, if you didn’t submit a change request for a deployment of your product more than, I think it was, six weeks in advance, it was considered an emergency, and you got a black mark against your name.

We were doing daily continuous deliveries on a number of different products that we were creating, so we got a lot of black marks. In fact, we got the most black marks of any department. I think the combined black marks of every other department in the whole organization because we were doing continuous delivery, because we were starting to use modern engineering practices, we were punished within the organization because that’s not the way we do things here.

So, are your teams empowered to change their processes based on what they learn so they can make everybody’s lives better and maximize the value that you deliver to your customers? If your answer to any one of these questions, or the answer of your business to any one of these questions, is no, we’re not doing that, then I probably wouldn’t consider that you’re already in the agile space. You’re not already agile; you might be working towards it, and you might have put in loads of effort, but unless you can mark every single one of these six questions as “yes, we do this; this is how things work here,” then we’re still lacking.

We’re still trying; we’re still working towards being agile. Now, this is just a litmus test dreamed up by the US Department of Defense, but they are probably the least likely place for you to expect something with this high a bar to have come from. I’m not going to go into a team and work with a team or a company, and if they’re not doing these things, then I’m going to say, “Well, you guys suck; you’re not agile because you’re not doing this.” That’s not how we work towards success.

But I think it’s hugely valuable from the perspective of self-reflection for you all to think about the processes and practices in your organization. How many of these six questions are you able to achieve, and what could you do to make it a little bit easier for the teams, for the people doing the work, to work towards this idea of not being agile BS?

Agile Values and Principles Agile Leadership Team Performance People and Process Agile Project Management Agile Strategy Agile Transformation Organisational Agility Agile Philosophy Team Motivation

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.

NIT A/S

CR2