Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
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. ;)
Agile Apathy was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.