Agile Apathy

When I started programming, no one was talking about Agile, and BigDesignUpfront ruled the day. In college, we were taught to pseudocode our homework before coding it. Our assignments included OOP diagrams, UML, flowcharts, function prototypes and other design documentation. When I started my first job, I was handed a 4 page spec and told “This has all the answers, get to work.”

My boss sat in the office across from my cubicle, had weekly one-on-one meetings with me, did performance evaluations, held team meetings, and (of course) tried to spend as much time coding as she could. Like any good Team Lead, she coded at least 50% of the time (per company policy.)

Things were pretty good to be honest. Oh, I quickly learned the specs weren’t perfect (or complete, or even very useful) and interviewing users became an important part of my job. The small team of 8 programmers figured out a way to build software that kept both users AND management happy (no small task!) without too much stress.

Company growth = painful change

As the team grew from 8 to 18 to 28 to 60, the process changed (for the worse.) The pressure from management increased, we had less interactions with actual users, because a new role (the Business Systems Analyst) was created to insulate the programmers from those pesky users. The specs got bigger (100+ page specs were very common), the meetings got longer, and the programming team was expected to stay “heads down coding” 90% of the time. Needless to say, this wasn’t much fun for anyone in the Software Department (yup, now we were an official “department” with 8 “teams”.)

One day someone brought a new book to the office, Extreme Programming by Kent Beck. It got passed around the software team with some excitement, as people were desperate for stories of empowered, respected programmers working on successful projects. More agile books appeared, and those were circulated. Management thought it was kinda crazy, and the BSAs didn’t care about it, but the programmers were infected. For years after that the internal developer meetings discussed how can we “go agile” and “try scrum”.

Finally management agreed that developers could try being “agile”, probably for fear of a developer mutiny. The team was thrilled, and we scheduled our initial project stand-ups, following agile’s advice to invite everyone from the BSAs, Project Managers, to Users, to Team Leads and all the programmers. Everyone showed up for the first few meetings, but quickly the the BSAs, PMs and Users stopped attending. Disappointed, the developers carried on the practice (if for no other reason than it’s what our agile manual told us to do).

“Yes, we use agile”

During this process I was promoted to Team Lead, and eventually to Assistant Manager of the department. One of my key responsibilities was hiring, and I can still remember the first time a candidate asked me, “Do you use an agile process?” Internally I thought, “Ha! No, not really.” but before I could answer my boss said, “Yes, we use agile.” I remember thinking, “Wait, really?” I realized in that moment that management wanted us to be perceived as agile, even though we weren’t actually using (or benefiting) from agile. Subtly I wondered if this was to placate the developers, or hire candidates who were passionate about agile, or so the CIO could tell his golf buddies they had adopted this new trend.

Going back to my office, I pondered this. Agile had become more than a process, more than a buzzword. It had become an banner management could raise to say: we have a quality software process that respects developers. But nothing could be farther from the truth.

In addition, I found that management expected developers to be happier now that we were working in an agile way. When developers complained we weren’t doing agile “right”, management pointed to the many variations of agile and defended the one we used. Sometimes managers would become Certified ScrumMasters, thus giving them more credibility (and power?) to affirm that we were doing agile “the right way.”

Numb is easier than Mad

Like most middle managers, I kept my mouth shut and soldiered on, living with the dissonance. When my developers complained, I pointed out that at least we weren’t still using waterfall (like in the “old days”, when I was a programmer.) When upper management complained, I pointed out that agile kept the developer happy, and that we were continuing to improve on it. In hindsight, it was duplicitous and disingenuous and I’m not proud of it.

I wish I could say that I had a “Network” (the 1976 movie) moment, where I proclaimed “I’m mad as hell and I’m not going to take it anymore!” But I didn’t.

Instead, I got numb. Jaded. Seared and scabbed. This turned to hopelessness and apathy. I needed the job, I loved the people, so I found solace in the thought that I could provide my team with a manager who cared about them.

So, I filled a seat, punched the clock, and disconnected my brain.

The Lesson isn’t about Agile

It would be easy to think that the big company is the villain of the story, but you’d be wrong.

If it’s not the company, then maybe it was the CIO, or my immediate boss, or the BSA’s who refused to participate in the agile process. Wrong again.

I am the villain of this story, fully responsible for my unwillingness to act. Willing to become a disengaged, unmotivated manager. Willing to be duplicitous for the sake of a paycheck.

So, if this sounds familiar to where you are right now, I hope you are braver than I was. That you can find a way to care again, to re-engage and fight for what’s right.

Or, if this looks like someone who works for you, maybe you can talk to them in a new way. A way that invites them to get mad, to express themselves, and to care again.

Life’s too short to coast in neutral. Too short to fill a seat, play buzzword bingo, or become numb to the stupidity around you.

Take a chance, use your words, and fight for change.

And watch Network, just once. ;)