There comes a time in every developer’s life when they are asked to code less and focus more on the intangible elements of software development. In some cases, this is a welcome request; more time spent on these elements often results in additional money, prestige, and power. Other times, this request is met with resistance, often because the developer feels like they’re losing their identity. Coding is what they enjoy doing, and it’s what’s gotten them praise and promotion in the past.

Up until very recently, I fell into that second camp. To me, my code was my worth, and I treated any attempt to reduce my time spent coding as a personal attack. In my early days as a developer at a large bank, my code was the one thing I could use to compare myself to the contractors and consultants surrounding me that made the big bucks. I churned out code like my life depended on it. I was the king of commits. Then, one day, we received the mandate that we were going Agile.

At first, this was exciting news. Agile was shiny and new, even though it was almost fifteen years old at the time. It had to be better than the waterfall model we’d used for our last behemoth of a project. As the training began, I entered with a smile, eager to learn and embrace this new methodology. What happened over the following weeks, however, was the exact opposite.

First, our schedules were inundated with rituals. Standups, planning, refinement, retrospectives, reviews. Next, they presented us with the Agile manifesto, forever linking Agile with Communism in my mind. What was being presented could work in theory, but not in practice. Shortly after, new members of our team showed up, their roles dedicated to facilitating and encouraging the Scrum process. These team members, who had no insight into the culture or norms of the workplace, were supposed to be our leaders. They began to take notes, enforce rules, and even report employees who weren’t totally buying into the scrum practice like Soviet police. With all the pomp and circumstance, when was a developer supposed to get stuff done?

The answer, it seemed, was in the disjointed hours between meetings and more meetings. After giving Agile the college try for a few months, I ended up leaving the banking sector and joined a startup on the referral of an old colleague. Their development team was run for developers, by developers — a sight for sore eyes after years of dealing with overbearing business requirements. Beyond daily stand-ups, there was little that could disrupt my work, or more importantly, my coding.

After a small amount of time, however, cracks in this methodology began showing. Deadlines and release dates were arbitrary. Requirements were lacking, and often filled in by developers — an approach that began to sour with me over time. Teams lacked cohesion. It was clear I wasn’t the only one seeing this. How did our leaders expect to solve all these problems? By adopting Agile, of course!

The ghost from my past had found me, and there was nothing I could do about it. Realizing Agile would follow me to my grave on the behest of Jira tickets, I realized my only choice was to surrender. It wouldn’t be so bad. We had the talent and gusto to make it work. And thus, the training began anew.
Except it didn’t — at least not right away. This time, our scrum masters would be members of our development team who would receive training, then return to us tasked with spreading the word of Agile. As my second stint began unfolding, I started to question myself. Was it Agile I really hated, or just the transition into it?

Around this time, I decided that after years of longing for long hair, I was finally going to do it. The only problem was that my hair liked to grow out instead of down. I knew I was in for a year of awkward in-between, but I bit the bullet for some luscious locks. Agile was beginning to feel the same way — the problems we had before were beginning to dry up, but my underlying issue remained the same. I was a developer, but I didn’t have time to be a developer!

As the years passed, this issue lessened. As my hair grew, our teams became more comfortable in their process, and slowly but surely the awkwardness subsided. Things still weren’t perfect, obviously — every so often I had a bad hair day, and needed to duck Agile for a day or two. But overall, things were okay.

With our Agile process speeding forward full bore, so too was our product roadmap, and new teams were formed to address our ever changing product needs. Placed on one of these teams, I was thrilled for the opportunity to contribute to these new features — mainly because new features meant new code. Riding this high, I set out to take care of all the preliminary team needs, only to come to a stark realization. We needed a scrum master, and it was going to have to be me.

I didn’t take this news very well. I hadn’t asked to be a scrum master, and was now expected to be a champion for a methodology I was at best indifferent to. Not only this, but I was given a set of new responsibilities I felt I wasn’t suited for. The only kind of documentation I liked to provide were code comments and READMEs. Capacity planning? Screw it, we could handle all the work.

Of course, this attitude didn’t sit well with me. After my initial vitriol wore off, I knew I’d have to take the reins and be the best scrum master I could be. After all, I’ve always believed people (and especially developers!) can excel at anything they put their mind to, and this seemed like a challenge worth the effort. My mind kept returning to the question I’d asked all those years ago — With all the pomp and circumstance of Agile, when was a developer supposed to get stuff done? As a scrum master, I finally seemed poised to answer it.

The MVP is the MVP

The first step was a hard pill to swallow — in order to code, we actually needed stories to complete. A vague idea of features, a few PoCs, and mountains of tech debt were a start, but we needed actionable stories, and fast. I was craving code, but I needed to code something meaningful. As a first time scrum master, I was more than happy to let my product manager take the lead on this one and come up with our stories, requirements, and goals.
This was a problem. Up until now, our product managers had either risen through the ranks internally or had been brought in from a single other SaaS company. That is, all except our product manager.

On my previous teams, I’d become used to our way of doing things, which was essentially having the product manager act as the one person story show. They’d deliver their stories, requirements, and design mocks to developers, only to have parts of them rejected by developers, and the cycle would begin anew.

Our product manager, on the other hand, actually wanted input on stories before they reached design, and even asked for mocks made by developers! To me, this seemed absurd — I was paid to code, not draw. But the more I thought about it, the more it made sense. The stories I had received previously could have used vetting by developers. We could break the cycle that had plagued our releases simply by sacrificing some of our coding time for discussion.
This was more easily said than done, however. At this point, our amount of development work had dwindled down to a pitiful backlog and we needed some fast. This is where a compromise had to be reached — we needed to define an MVP (Minimum Viable Product).

In my mind, the MVP is the first goal that should be completed when designing a new feature. A feature should never be fully designed, then scoped back to an MVP. Beginning with an MVP has two main advantages: It gives the ability to under promise and over deliver, and allows developers to begin as soon as possible. If the developers are competent enough, they will be able to make their code extendable enough to adapt to any future changes.
With this compromise in hand, we harnessed the power of our design team, and finally arrived at base requirements and mocks. Now, it was time to groom. And to do that, we had to schedule some meetings.

A detour into Kanban

For the first couple months of our team’s existence, we tried out Kanban to see if it would solve a few of the problems we found with scrum (like having too many meetings). It didn’t. It only gave our team little to no purpose with lack of sprint goals and organization. And that’s all I have to say about that.

I don’t hate meetings, I only hate meetings when nothing happens

Meetings and developers are natural enemies, like developers and product managers, or developers and QA, or developers and other developers. Damn developers, they ruined my code base! The natural place to start as a scrum master would be meetings. Not only were they my biggest apprehension surrounding Agile, but it was now my duty to plan, run and manage them.

A few months prior to my appointment, our department had implemented “No Meeting Tuesdays” as a way to curb these feelings, as obviously I wasn’t the only one complaining. While the spirit of this day was nice, after some long days of coding, I realized I actually enjoyed a quick afternoon meeting during “No Meeting Tuesday” — it broke up my day, and helped remove the spots from my vision. This got me thinking. Maybe meetings weren’t so bad; maybe it was just some of the meetings I’d been in that needed improving.

Identifying certain issues was easy. In the context of a meeting, any discussion that seemed off or irrelevant to the task at hand needed to be stopped or sidebarred. This is the responsibility of whoever runs the meeting, be it the scrum master or product manager. I am of the opinion that it doesn’t matter who runs any meeting, so long as that person can facilitate the meeting towards its defined purpose.

If other tangents arose during the course of a meeting, we would consider scheduling a new meeting with a new purpose — for example, we broke our backlog refinement meeting in two, one run by the scrum master and one by the product manager. The meeting run by the scrum master would focus on immediate refinement, whereas the meeting run by the product manager would focus on preparing stories for design and discussion. Two meetings with purpose will always be better than one without, even for someone who dislikes meetings. Those who are not absolutely needed at a meeting should always be optional. And if an impromptu gathering will do, why even book a room?

Always the groomsman, never the groom

With distractions down to a minimum and meetings running smoothly, why not throw something else into the equation? Something that should be on the mind of scrum masters and product managers constantly, and if neglected could cause the whole team to come crashing down? Some people say backlogs are living, organic entities, constantly changing with the demands of the product. If that’s the case, they are definitely toddlers — too young to be independent, but old enough to cause some damage.

We’d already seen what could happen with a sparse backlog, and we weren’t about to let that happen again. In addition to our backlog refinement meetings, our product manager set aside her mornings for ad hoc backlog grooming, and a precedent was set that this could happen at any time. Waiting for a code review? Groom. Need a break from staring at an IDE? Groom. Go to grab another ticket? Groom.

And what exactly do I mean by grooming? Make new tickets if you observe bugs or missing requirements. Get rid of old, irrelevant stories. If multiple team members are available, size stories and make sure all estimates are still accurate. Split stories up and refine them into sub-tasks manageable by a single developer.

Thinking of these actions as a constant battle will end poorly. Instead, think of grooming as something akin to technical debt. If you don’t fix it, eventually things will start to go wrong and development work will grind to a halt. Someone will have to fix it, and it won’t be fun. A little bit of grooming here and there mixed with some focused refinement meetings will eventually lead to a backlog full of actionable, relevant tickets, which in turn leads to satisfying work for developers.

We’re all in this together

By now, we were meeting, grooming, and even designing as a team. The last thing to do was code as a team, but for me, that would be a little tougher. I’d always embraced teamwork, but only if I was able to shine brightly myself. Sure, I reviewed code, answered questions, pair programmed when the need arose, but ever since Agile had been introduced into my life, story points had been the first thing on my mind. For a long time, tickets were nothing more than something to conquer. Jira was like a leader board listing out the top performers of the past two weeks, and if I wasn’t at the top, I’d stay late to ensure I was.

When playing this game, even filling out tickets was a waste of time — if I already knew what had to be done, why did I have to fill in the details? Fill in the story points and go. Years at the company had given me enough domain knowledge to figure most things out, and if I couldn’t, it was easy enough to ask someone. The problem was that now I was making tickets for people other than myself. This attitude was in direct conflict with one of Agile’s main principles: Any developer should be able to pick up any ticket.
While my new appreciation for grooming had solved this problem, my ego still remained. Despite the fact that I’d become mellower over the years and my preference for quality over quantity had grown, I still relished seeing my name atop the leader board. And with some younger developers on the team, I recognized the same spark in them I’d seen in myself: the need to code, and code a lot.

Looking at the Jira board, I tried to come up with a solution. My first thought was to abolish story points entirely, but that wouldn’t gel well with our release planning, or really planning in general. Maybe there was a way to get points simply off our board?

For the past few sprints, we’d been experimenting with exactly how to display sprint work on our board. We’d settled on something that seemed to work — we’d break user stories down into sub tasks that were more technical and could be worked on by a developer. For example, if a story had both front-end and back-end components, it would require at least 2 sub tasks, then each of those components could be broken down further. The front-end piece could be separated into aesthetics and functionality, for example. To size these stories, we’d size each of its sub-tasks, then sum up the total and assign it to the story as a whole.

This approach made it easier to collaborate, as multiple developers could work on a single user story at one time. The only issue was that the points still remained — a point hungry developer could still run rampant. Looking at our board, I noticed that the stories themselves didn’t actually appear on our board, only the sub tasks. If the stories encapsulated all the necessary information, why have the sub tasks display points at all?

Today, our board is points free, save from bug injections and other small exceptions. Sometimes it is slightly more difficult to parse the board and find a story that fits exactly what you’re looking for, but with complete tickets and competent developers, this shouldn’t be an issue. If all else fails, have an impromptu meeting to discuss and groom!

Everything is okay

Overall, being a scrum master isn’t so bad. While it does cause me to code less, I’ve tried to make the most of the opportunities given to me to make the code my team produces more meaningful. As I grow as both a developer and a person, I realize more and more that purpose and meaning is essential to being a developer. Writing lots of code and talking algorithms is fun, but if they lack context they’re meaningless. Working on a product driven by Agile development helps solve that problem.

While I don’t think I’ll ever embrace Agile one hundred percent, I have grown to accept it. Done right, or at least partially right, it definitely beats out my waterfall experience. Cheers to Agile. May it reign long, or at least until something better comes along.

• Category: Vena Engineering
• Tag: agile, scrum, scrum master