A while back I was helping a marketing department with Agile, and that’s a story for another day. This story starts with a comment from a VP who was sponsoring the problem that this marketing team was working on.
He said, “we tend to make it hard on ourselves to get work done with all of our processes. Let’s break the machine.”
The Spock in me thought, “why don’t we make however we get work done around here the actual process? Then we don’t need to worry about breaking the machine!”
Easy to say, hard to do.
Every organization has documented processes in some form or another. Then there is the actual way work gets done:
The Process: In order to get production log files, login to system X and create a ticket. Your request will be responded to in less than 24 hours. Reality: Take Bob out for a coffee and ask him a few questions
Agile breaks your organization because it tries to turn the way-things-get-done, and all the unspoken rules, into the official process. That makes some people nervous. Instead of entering a ticket in a system, Bob would be part of the team, or at the very least, sit near the team so team members can grab him when they need him. That eliminates the need for a system, and possibly, for Bob to need a manager.
When something goes wrong, people responsible for that thing want to know whether or not the process was followed, even though they know that’s not how things really get done. If the process wasn’t followed, heads will roll! If this happens too many times, a process person is appointed to create a new process that ensures compliance!
Last week in my change workshop, the class had a discussion around how change management integrates with agile teams. For me, the discussion was simple. If it’s business process change, IT change control, or any other non-transformational change, the change manager sits with the team.
There’s no magic or complex model, or certification needed to go sit with the team. It doesn’t mean those things aren’t coming because we love inventing models to replace human interaction, but it IS that simple, and here are two examples:
This picture is a big visible release wall. At this organization, we ran 15-minute standup meetings three times per week. We’d get anywhere from 20 – 30 people in these meetings. We talked about risks to existing projects, and that was it. When we learned that IT change management was having a hard time dealing with their governance, we created this release wall. Every Monday, the IT change manager ran another 15-minute standup meeting after the project risk standup to talk about how the releases went on the previous weekend, and also to remind people to cut their change records for all scheduled releases the following weekend. You could call this a new process, but it was created organically through conversations, and by piggybacking a new habit onto an existing one. We didn’t spend months designing PowerPoints, creating a comms plan and other nonsense, we just did it. The key was, the IT change manager owned this, not us.
This picture shows a big visible board that the coach of this team was working on. Instead of creating plans in isolation, we created them with the affected teams and visualized our work next to their work. That meant we needed to duplicate our sticky notes because we had a larger Kanban board in our team room. Here’s how the process worked: One day one of the consultants said: “hey, I tried this out with my team…they like it.”
We all said “cool idea, let’s try it! But how do we keep our board in sync with what we’re putting next to their Kanban boards?”
We agreed to have our team Kanban board updated for our weekly meeting. Some of us brought the portable Kanban board into our team room, while others took pictures of their portable Kanban boards and then came back to the team room and did the sync.
For those interested, this is called managing the interactions between systems. We think we need a specialist role to come up with the rules for managing that interaction but in reality, all we need to do is make sure the conversation happens.
In my workshop, I asked the group why doing something like this would be hard, because I legitimately do not understand why it would be. They said hierarchy and fear would get in the way. This process might be too fast and loose for some.
This is precisely how Agile breaks your organization. You see, there are official rules of engagement for how change managers interact with the rest of the organization. The two examples I gave would probably be met with “well, we can’t do that here because they won’t let us”. Step 1: Find out who they is. Step 2: Go talk to them.
I once worked for a large organization that communicated across horizontal organizational boundaries through forms. Need help with Agile? Go to the Sharepoint, download, and fill out, the intake form and if you do it right, you’ll get help. In fact, in this organization you needed to talk to 4 or 5 people in the SAME department (each with their own form), just to have the opportunity to ask for permission to run an agile project.
Why? Because someone needed some way of showing progress towards Agile, and they needed to produce enough evidence that something was happening and people were busy. Sounds like a Dilbert cartoon, but what’s the alternative?
Need an exemption from the release policy because the stakeholder demanded the shade of green be changed on the main header of the web app? Fill out the form.
Need a development environment? Fill out the form.
I think you get the point. Oh, and the solution to this is simple. Talk to people. Instead of asking people to fill out a form, have a conversation and you, as the owner of the form, fill it out yourself!
Now, there are reasons why these processes exist. Cover-your-ass is one reason, but sometimes there are legitimate paper trails needed for regulatory or compliance purposes. Segregation of Duties is one. You need to provide proof that developers do not have access to production. That means providing a paper-trail, and an account audit of permissions for production accounts. Of course, that doesn’t mean developers haven’t somehow been able to use the password of their Ops buddies, but let’s enjoy this fiction for the sake of argument, shall we?
Organizational Design to the Rescue!
Most organizations follow a similar path to Agile. They bring in someone to run the Agile Transformation and then try to make each individual function Agile. Here’s our QA Agile process, here’s our Agile requirements gathering process etc.
The alternative is to redesign the organization to support an Agile way of working.
Organizations want standard Agile practices because they want thinned out processes that work with their existing structures and hierarchy. If the teams are creating their own processes, it’ll be hard for project managers to manage multiple projects. It’ll be hard for a team member to join another team because they’ll have to learn a new process. Forget standard processes, simply create working agreements within whatever organizational constraints exist. Redesigning the organization might be a better alternative, but it can have serious consequences. Those consequences include laying off people who don’t fit into the new design, the risk of exposing the organization to regulatory problems, and the risk of having good employees leave.
Remember the example of how to integrate change management and agile teams from earlier in this article? What happens when all the change managers are placed on agile teams? What will the manager do? What will the director of change management do? What if there aren’t enough change managers to staff all the team? Some projects will have more demand for change managers, others will have less. It’s reasonable to expect people outside of the core team to be able to support multiple teams.
This might sound like a matrix organization, but it isn’t. A matrix organization temporarily loans people to temporary team structures based on executing time-bound projects, but those people are returned home when the project is finished. Redesigning an organization around Agile means those people stay together permanently. I always consider Agile Coaching to be a service. That is, my work and the process I use is directly affected by how the teams that deliver value operate. I don’t create processes for them to follow, the demand I see from teams dictates how I work, and what I work on.
Organizations that value centralized control don’t think that way. At another large organization, we had a situation where so many teams had gone Agile, the centralized Ops team couldn’t keep up so they tried to make it more restrictive to release in order to maintain control. That’s another example of how Agile breaks your organization. That’s a signal that a centralized control department shouldn’t exist. The function should be merged with the teams. Agile folks will say “right on!!!” but Spock-like people will say. “Hang on. All you’re doing is moving the bottleneck from a centralized team to the dependency between teams.”
And you’d be right. That’s exactly what is happening, logically. The difference is, the teams with the dependencies will need to create a social contract on how to manage those dependencies instead of being forced to follow a process they didn’t create.
Every time we cross boundaries in our organizations, there’s the potential we’ll break something. Agile is fantastic at exposing these problems and when it happens, people who stand to lose something are frantically running around with super-glue trying to keep it together.
We call this change resistance. It’s not, by the way, but that’s how change people refer to this phenomena. If you thought you were going to lose your job because of Agile, how would you react?
What’s the Solution?
The great thing about the internet is that it’s made all of us experts. Each camp will propose the solution they believe in. Mindset people will say we all need to develop the Agile Mindset. Scrum people will say teams need to be courageous because that’s one of the Scrum values. Framework people will say that we need to implement the framework properly. Change people will say we need urgency, top-down support, and communication to make it work.
I have one principle I follow when trying to help organizations untangle this mess. Find out who has to live with the consequence of the change, and facilitate a conversation between them. It doesn’t always work, but it’s not my organization. I’m only responsible for breaking it, and helping the people figure out which options are best for fixing it.