How Scrum Saved My Software Engineering Job

When developers first hear the business has decided to bring in Agile/Scrum, there is a feeling of dread. Agile methodologies are not usually brought in because the “powers-that-be” feel they are getting productive development from their coders. However, if you are an earnest developer you should welcome Agile/Scrum with open arms.

Scrum really provides metrics that measure developer output. If you are working hard and doing your job why should you fear this? You should welcome the fact that objective metrics are now going to be collected on developer output. I know this for a fact as an earnest and hard-working developer myself. I know this because Scrum saved me from being terminated.

I had been working at a company for a couple of years as a developer. Those first couple of years had been productive and I thought I was in good standing. I was wrong though. I felt my “stock” at the company falling mysteriously. I sensed that my opinion no longer mattered, but I was unsure why.

I had a family and I was coaching a youth soccer team around this time as well. That meant I had already left when the CTO would walk around the building at 7:00 pm to see who was still there. This was how the CTO measured whether a developer was good or bad.

Were they there when he decided to survey the room, hours after alleged “quitting” time. I had left at 4:00 pm usually to work with my son’s soccer team. Of course, I had gotten there at 6:30 am while the CTO was still snoring but that did not matter.

I hung around for a couple of late nights. I saw what was going on and understood why my developer stock had fallen. The CTO would wander in and stop at the desks of developers that were still there. The laughing and joking was loud and obvious as he stopped by the desks of competing developers, but skipped by mine. Interesting I thought.

Several of the developers that now appeared to have the CTO’s ear were also developers that took excessively long lunches and were often on the telephone working their side gigs.

Those things were not observed by the CTO. However, to those that were actually working, their absence was obvious. The CTO was only interested in developers who were staying late, because he was incapable of measuring productivity.

As is often the case, the new software methodology was brought in because “the business” felt we were not making good progress on our overall technology road map. This was not entirely our fault though as the CTO was a bit of a “hound dog” when it came to leadership. Any time he was trying to lead, give us some insight or communicate his vision, a squirrel might run by and distract him.

At any one meeting, the retiring of legacy applications may dominate the discussion, but within hours that focus might change. In fact, it might be mere minutes before leadership had already changed a long term goal…due to a squirrel.

Obviously, I did not hold the CTO in high regard and apparently the feeling was mutual. This is not the way one gets ahead as developer, but I continued to work hard. I looked at Scrum with an open mind figuring that anything measuring developer output ought to be positive for me. I continued to not stay late for impromptu bull sessions in the cube farm, which meant I was being discriminated against with the current yardstick. Any NEW developer yardstick had the potential to be positive for me.

My optimism was not misplaced, fortunately. I managed to squeeze out another two years of high paid employment from the company. This while still not being held in high regard by the “hound dog” CTO. To survive and even thrive while this is true is not an easy thing to do. The existence of an objective yardstick to measure developer output made it possible.

This is why I can say with confidence that if you are a hard-working developer, then you need not fear Scrum. Your output will be quantified. If you are earnest in the sprint meetings and do some work each day, then the daily stand-ups are easy. Despite not being held in high regard and being on the verge of being fired, I survived for years. Developer metrics were a godsend and saved me.

I even heard that in one meeting the CTO was complaining about me and another attendee defended me. A vice-president cited the metrics and pointed out that I had outstanding “velocity”. The vice president even went so far as to call me a “superstar”.

Admittedly, this is just what I heard, so I cannot be sure as I was not invited to such meetings of important people. However, I did manage to survive for quite a long time when I had felt I was on the cusp of termination, so...

Scrum and other Agile methodologies bring metrics to the software development process. Most of the time, the reason that development productivity has been lagging is about leadership. That is why the concept of “servant leadership” is SO important to success in these efforts. The idea that leadership needs to “serve the workers” is difficult for some, but it is a truth.

Another thing that can be very useful is the concept of Return on Investment. Sprint meetings will be much more productive if ROI is a topic of conversation. When working through competing priorities, the ROI of any given project is a powerful measure and useful tool for prioritization. If there is no good answer to, “What is the ROI on that squirrel?” it does not make the cut.

Sprint meetings are about deciding what will be worked on and ROI is the most obvious measure. Using ROI, projects are selected for the sprint to move forward goals that are measured by ROI. This will require goals to be written down and agreed to before the sprint. At the end of the sprint, those very same goals will be on the table for discussion on how the project is moving forward a given goal.

If it turns out that every sprint is about chasing squirrels, well at least the “squirrel goals” were written down. Now, there is a record of each squirrel the team was required to chase. Over time, ROI becomes an effective weapon against the squirrels that might run across leadership’s desk at any time. Scrum provides metrics to measure your output and gives you a club in the form of ROI to fight back against chaos and confusion.

An earnest developer has nothing to fear from any honest software development methodology, like Scrum and Agile. Embrace it! You will be glad you did.