Blind to Agility

A recent experience has further caused me to realize the bureaucracy of large organizations will always crush any ability to truly work in an agile way.

This team has been on their “agile journey” for close to a year. The team has grown and split and have been extremely experimental with their process despite the organizations size. Scrum is the chosen framework of the organization, and for all of the pain that it caused to real agility, it has actually helped to an extent. Pain is felt at the end of nearly every Sprint when things are almost done and what to do with them, but this team is lucky enough they no longer estimate with Story Points so that pain is diminished a bit.

But this recent experience disturbs me.

The next Sprint was due to start on a Thursday. The team and customer met together to discuss a specific set of functionality to be built next the Wednesday before this next Sprint would begin. There was agreement around the Stories that were created, and a shared understanding was achieved headed into Sprint Planning. That Thursday, during Sprint Planning, the goal was laid out that supported these Stories being included in the Sprint. The team without hesitation said these Stories support that goal and so the fun began.

Thursday the team started building out the Stories. Friday they had some of the functionality far enough along they wanted to gather some quick feedback from their customer. The team and customer got on a call, we are remote of course still during COVID, and walked through what had been built thus far, and asked some questions of the customer. The customer stated that after seeing what had been built, and thinking about its value, they would like to remove a large majority of the planned Stories, and only focus on a couple.

This to me was incredible. We had created a partnership with our customer. We didn’t spend time and effort building out software that ultimately wouldn’t have provided the value they wanted at the time and were able to shift focus. And all of this over a couple of days. I was almost euphoric with excitement.

Then I had a conversation with organizational leadership. I shared this story with them. And the feedback I received to share with the team was stunning.

“If this team would learn to estimate better and use Story Points, maybe they never would have started on these other things to begin with.”

“Well now what are they going to do that you replaced 6 Stories with 2 Stories? Are we just not utilizing all of our resources now?”

“This makes us look incompetent to our customer, like we don’t understand them at all.”

Now I saw this as an opportunity to possibly educate and enlighten organizational leadership again on agile values and principles. And that what this team just experienced is working with agility. Apparently I was wrong in that.

With this organization, and most other large organizations I have encountered, the value is placed on standardization, estimation, and velocity metrics. The need to drive teams to improve based on these things and ensure 100%, who am I kidding, 150% resource allocation are far more valuable. This thought process is incredibly disturbing to me.

Bureaucracy

Statements I have heard with large organizations that say they are “Agile”.

“We like standardization without bureaucracy.” – So that is interesting, and when I have dove into these statements, this is what I get.

• “Teams are free to work in whatever Sprint cadence they want, as long as it is 2 weeks.”
• “Teams are free to forecast when things will be done, as long as they estimate with Story Points. And those Story Points equal some standard set of time.”
• “Teams need to be exactly X number of people. No more. No less. So they can be autonomous and communicate with their manager.”
• “There are 6 people on that team, they should be able to get done 3 stories per person every 2 week Sprint.”
• “QA will be on every team, and they must sign off or it doesn’t go to production.”
• “We have Business Systems Analysts on every team, they are the Scrum Agile Project Managers.”
• “Teams should release their software at the end of every Sprint after getting approval during the Sprint Demo.”

I will stop there. What can you do with organizations like this? To be honest, I don’t think there is anything that will change them. The example I provided is about as agile as it gets in a working scenario. We gained a shared understanding with our customer as a team, we started building, we shared early in the build process to get some feedback on if what we were doing is going in the right direction or if a change was needed, we shifted based on the feedback from minimal effort and time spent, and are going to deliver something more valuable to our customer. It doesn’t matter to me if that value was created with 5 stories or 2 stories. What our customer deemed as valuable to their software was provided.

In case anyone is lost here, we do not build software for ourselves, or the analysts, or the developers, or the qa specialists. We build software to solve problems for our customers. Yes this holds true if you build software tools for internal users as well. They have a job to do. And when we build something to help them achieve whatever objective it is in their job that they need to achieve, we are changing their world.

The ability for a team to be autonomous in how that happens is extremely important. No set of standardization in your process or velocity metrics you choose to utilize matters more than the working software for the user.

If there is one thing I will say to large organizations that somehow continue to think in these ways…

“Give your people the tools they need, trust them to get the job done, and get the hell out of the way.” – Me and many smarter people than myself