Being on the first team of a big international company to go Agile was exciting.
They were building a brand-new application that was going to, among other things, allow them to finally retire a very outdated legacy system that was causing a lot of operational and technical problems. The team was strong and talented. The director was young and progressive and had the cutest British accent. One of the members of our consulting team was an Agile coach. And there were several other senior-level analysts and product managers on board.
Establishing Agile practices at the team level wasn’t too
bad. We had a team room, met every day, turned the projector on, and talked
through our tasks and issues just like an Agile team should. We were co-located
and cooperative and enthusiastic. Or at least, not hostile. The developers,
like code-slingers everywhere, had a “well here’s another new thing” attitude,
but so long as they were able to build good code and do interesting work, they
were satisfied.
The mid-level management folks were less happy. Some of the
more astute realized that Agile meant the lines were being re-drawn and they
didn’t see themselves in the new organizational geometry. Some of them bailed.
Some of them adjusted and found new roles within the evolving landscape.
Months went by. Our team worked hard to stay one step ahead
of the developers. It was a bit like being a detective, finding the systems and
processes and teams that would be impacted in the future by the work we were
doing. As our director said, we were in charge of “kicking over the rocks and
seeing what was living underneath.” Slowly the application grew and went in
front of user groups for demonstrations and feedback and refinement. It was an
Agile success story.
So….
Like I said, it was a really big company. And more and more
teams started switching to Agile. It became official. It become canon. It
became a juggernaut.
The heart of Agile is small, self-directed, responsive teams. The heart of big corporations is standardization, measurement, and control. Rock, meet hard place. Now, there are folks who will tell you that scaling Agile is totally do-able. There are books and classes and certifications and conferences, oh my.
What everyone is really doing is trying to fit Agile into American corporate culture. It doesn’t work. What you end up with is chunky waterfall with a fancy new lexicon to describe the same old shit. Nobody really wants to go back to the excesses of waterfall. The long planning cycles, the analysis paralysis, the heavy change management processes, the piles of documentation. So, why don’t we Agile better? How did something so simple, so radical, and so intuitive get so fucked up?
I’m not the person with the answers, but I can share a few
examples that might shed some light on how it goes sideways.
Standardization – Imagine an organization with many Agile teams working in different business areas on different applications in different states or continents. Now, tell all of those teams that they must use the exact same structure and standards for their product backlogs, that they must build complicated and time-consuming dashboards and reports for management to track the details of their sprint activity, and that they must participate in multiple meetings every week outside of their regular team activities. This breaks the concept of “self-organizing” teams. You don’t trust your Agile teams to organize and manage themselves and their work to accomplish a goal.
Budgeting – Instead of funding Agile teams, you organize your
entire budgeting process around projects. Say for the next year you have 30
possible projects. You’ll probably fund about 5-6 of them, but you require the
IT organization to submit sizing and budget estimates for all of them so that
you can evaluate them. This means that your Agile teams will have to drop their
planned sprint work for several sprints while they analyze, document, and size
the proposed projects. Later, when you evaluate the performance of your Agile
teams, you notice that their velocity has slipped significantly, so you institute
more controls and standardization to track and measure their performance. If
you want your Agile teams to be productive, you need to change your corporate
governance processes to align with Agile principles. Agile that is confined to
IT will never truly succeed.
Starving IT – You think of software developers and IT as a
cost center to be minimized as much as possible. You pay on the lowest end of
the scale and utilize offshoring and contractors as much as possible. Slinging
code isn’t a skill set you consider core to your company. Sure, turnover is
pretty high, but you have standards and processes in place to ensure the less
experienced folks don’t get too far off the rails. For Agile teams to be
productive and maintain consistent velocity, they need to be able to gain
expertise in the business and technical domain they work in, as well as to
develop strong working relationships and trust within the team. This is
impossible to do if the team is constantly churning and your most experienced
people are leaving for better pay elsewhere.
Too Much Complexity – You’re a big company, and over the
years you’ve added many off-the-shelf and bespoke software applications, with
layers of services to connect them all. Because you engaged in rampant
customization, any change to your ecosystem causes reverberations across multiple
domains and applications. Any project you undertake impacts so many domains
that 10+ Agile teams are involved in weeks if not months of development and
testing. And regression testing? Well that’s a whole other story. If product
teams spend a significant amount of their time supporting projects from other domains
that have significant impact on them but do not provide noticeable benefit to
their user groups, they won’t have the time to actually address their own
backlogs. They spend all their time dog-paddling, and eventually, frustrated
because they can’t build anything of quality and impact, they leave.
So, is there a lesson in all of this? I don’t know. Maybe that you can’t start transformation at the bottom. Maybe that American business culture is its own worst enemy. Or maybe that I just got too cynical to keep on pretending that with the right training and the right coach, miracles can happen. Folks tell me that Agile works pretty well at small tech companies with collaborative, forward-thinking leadership. I don’t know. Those aren't the ones who call in consultants to fix their shit.
