Holistic Agile

ho·lis·tic hōˈlistik/ adjective

characterized by comprehension of the parts of something as intimately interconnected and explicable only by reference to the whole.

What do you think scaling means?

Is it okay that only IT and software delivery teams are Agile?

Does it matter if HR and Finance, Sales and Marketing and other business units still do things the way they always have?

The truth is, without change throughout the whole organization it cannot truly be Agile. (Unless it started out that way; kudos to you if your organization did.)

But there is an assumption in many cases that Agile is only for software development teams or IT.

We have to open our minds to the possibilities of Agile and understand it's not a prescriptive set of steps but a different way of looking at things; a different way of doing what we do.

When we talk about scaling many of us think of starting with a pilot team and then scaling to the rest of the teams within the group--that's product delivery scaling--or we think of scaling to other groups within the organization--platform scaling, or we might think of scaling to leadership and helping them become more Agile in their thinking and interactions--vertical scaling.

There are frameworks out there to assist with those types of scaling--LeSS, DaD, SAFe, Nexus, etc. But they're all focused on software development to a certain extent. There is another form of scaling we're starting to hear more about.

Horizontal scaling or scaling outside software. I've heard it called holistic Agile and I like that because it deals with the whole not parts.

Most companies think that Agile is all about the development and delivery of their product and that it doesn't apply to anyone outside the teams delivering that product and maybe internal groups like IT. The truth is Agile is a complete cultural and mind set that must be implemented in all areas for true success and benefits. The great news for everyone is it works. Companies whose names you will recognize have done it and are reaping those benefits.

One example is Gap Inc. They adopted Agile in their HR department because, among other things, they wanted to cut down the time it took from resumes received in house to a candidate being hired. And many times not the best candidate; they were losing the best candidates to other companies, because it took them at minimum anywhere from 10-54 days and with maximum delays anywhere from 31-123 days!

That's a huge problem, especially if you need that person for critical development on a product that must meet a market timeline. It could mean the difference between success and failure for that product and maybe the company. And they're not the only company with this challenge.

The Gap HR team goal was to completely revamp their process and cut down the time it took to screen, interview, and hire a candidate by about 2/3 of the shortest time it took them currently. The amount they accomplished in three months might make your head spin. But that's what happens when you look at what you're doing in a new way.

Because many organizations think about Agile as a prescriptive methodology, they believe they just follow the steps and voila! they will be Agile. 

Just as looking through polarized lenses give you a different perception of color, and certain drawings change when looked at from different angles or by squinting your eyes, Agile helps you view things in a novel way.

Once you look at something through the Agile lens, you'll start seeing things you missed before. Think about those magic eye pictures with the hidden 3D picture. If you slightly unfocus your eyes the hidden picture jumps out at you. What you see completely changes. But the truth is, the thing itself--the picture--hasn't changed; only what we see or how we see it.

There's a reason MBAs predictably fail at the marshmallow challenge while kindergartners best them every time. The years of training to see things a certain way has rendered them unable to do anything else… to see it any other way. Participants in the exercise are given 20 sticks of spaghetti, one yard of rope, one yard of tape, and one marshmallow; then they're asked to build the tallest free-standing structure they can using these items in ~18 minutes. Oh, and the marshmallow must be on top.

The MBAs spend about 30% of the time they're given planning the perfect structure and allocating roles. They end up with a structure about 10 inches tall; the average structure is about 20 inches tall with kindergartners achieving that along with architects and engineers.

How can this be?

Innovation can't be taught. If you're taught that everything can be planned, and must be planned in advance of beginning, you are killing innovation. If innovation is dead then you can't see things in a new way, a new light, or with new eyes. Creativity and innovation are critical for companies to achieve the ability to pivot and change.

Those MBAs aren't stupid people and they might be creative in other areas of their life, but they have been inculcated with the belief that in work the plan is the thing--the plan is right and the plan will get them through. So much so that they spend about 60% of their time implementing the plan they created to build their structure and only at the end do they place the marshmallow at the top… only to watch the whole thing bend or crumble under the weight. They leave themselves little or no time, or thought space, to pivot and try something else. They worked on their plan in a vacuum.

The kindergartners on the other hand build something small and stable with the marshmallow on top in just a few minutes. They play and experiment with the rest of their time. They don't believe there is one right way to accomplish the goal. In the same time it takes the MBAs to build one structure the kindergartners build 4-5 different attempts. They don't know going in what it will look like or what will work but they end up figuring it out.

So what does all this have to do with scaling Agile outside software? Well, executing on a flawed plan is a guarantee of failure. Flawed plans occur when we don't take into account--or even know--all the variables, or more importantly, allow ourselves to experiment.

Innovation is part of the answer. We must believe that innovation is more important than the plan. Because IT IS. Sure, you need a starting point and a shared understanding of where you're headed but innovation isn't about being a fortune teller or seeing the future. It's about figuring it out as you go.

In nearly ten years of experience in Agile environments, I have seen many companies saying they want to "be Agile." They hire coaches and spend money on training to get everyone in software development to be and do and think and act Agile. Many times when they look back a year or two later they are confused about why they aren't experiencing the huge leaps in ROI they expected or seeing droves of customers adopting their offering. Some of them say 'well Agile doesn't work.' Rarely do they say, 'we need to figure out why this didn't work for us.'

When I talk with executives and ask them whether they think they night need to change their approach and look at how they do things in the rest of the company, they tell me 'oh things are working just fine in [insert department here].' The problem is they think they're working just fine because they aren't looking for what isn't working.

One of the things I tell people when I begin coaching them is once you start doing this thing called Agile you will see the things that don't work. They will be illuminated very quickly and clearly. The choice is to acknowledge them and address them… or leave them as is.

So what do you need to scale to the rest of the company? There is no special adjustment or implementation. Make the decision and then do the same thing with those other departments/areas as we do with software development and IT. It's not exactly the same but it's not that different.

We know what one what The Gap did with hiring in HR; the next step would be to start changing how we approach compensation and increases. How do we incent teams rather than individuals? Annual individual reviews create friction because it pits people against one another and that is anathema to Agile teams.

How about Finance? How do we fund teams or products rather than projects? Doing this removes a lot of up front guessing, negotiating, and jostling for supremacy in the money wars, as well as the creative financing on the back end when there is money left in other projects but not the one that we really need to finish and release. If we decide as a company what our highest priority is and everyone knows that and then fund that priority we don't have the problems the current status quo creates.

How about security and networks? Yes, it's absolutely critical to our company health to meet all the regulatory and compliance laws and rules, but we don't have to accept the bottleneck created when the security/network group is inundated and unable to review pending releases. How about we build those reviews into the overall roadmap/timeline and process rather than think of them as an afterthought? Remember when testing used to be the afterthought? Or how about we ensure that we build in the compliance and regulatory items in by adding someone from that group to the team?

The most important thing to do is to focus on building that cohesive, collaborative team feeling with everyone across the organization. Provide safety so everyone feels comfortable sharing their ideas--from the cleaning crew to the c-suite; provide clarity of vision and purpose so everyone knows what is most important to the company and understands their part in making it happen. This will foster a culture where dependability is de rigueur; no one wants to be the bottleneck or considered unreliable.

None of this is rocket science and you may have heard other people talking about these concepts. It's also important to know that you can't wait for someone else. You must step up and advocate for the change.

So if you're an team member, you need to ask the question, "Are we going to implement Agile to other departments outside IT/software development?" Back it up with some data; "There is a 6-week delay while we wait for approval from finance or network/security. If we were all collaborating from the get go we might be able to cut that in half or completely remove it." And you need to push back when you're handed an unrealistic deadline or given 5 number one priority items to work on; use real data as back up because that's what gets leader's attention and response.

If you’re a manager, you need to listen to your teams, look at your group and ask yourself what changes will make a beneficial impact, pull your colleagues together to talk about how you can get started; hold a stand up with them to keep track of how things are going and discover when and where you may need to tweak. Find a mechanism for sharing the impediments you encounter with your leadership so you can get help from them. Talk with your leaders about how you can get faster decisions; maybe outline a new paradigm where some decisions are made without executive input--share those decisions and results in full transparency so we can continue to build the relationships and trust we need to make it work.

If you're an executive, you need to start listening more and working with your people to figure out what should go into the vision and goals and how to make them crystal clear so everyone knows what they are. If deploying the product is the most important thing, then HR must fill the open headcount and Finance must approve the funding and not be bottlenecks. Sometimes that means cutting down the number of initiatives on the roadmap; maybe focusing on 1-2 instead of 5-10. You need to allow room for failure and encourage innovation and make time for both. You also need to learn how Agile really works; you can't cook without a recipe unless you have some experience as a chef.

If you're in Product Management you better be working with the customer every day to be sure what you're giving them is what they need and that the 1-2 items the organization is focusing on are the right things. And when that changes make sure everyone knows so we stop spending time and money on the wrong things.

Agile can be applied everywhere. It can and does work outside software development and IT.

It doesn't happen overnight; however, it does create short term wins while you strive for the long term change.

And this kind of environment creates joy, as Rich Sheridan talks about. Who doesn't want to work in a place filled with joy?

You should get started today looking at things in a new way and helping your organization do that too.