Howard Dierking

9 Months In - Reflections on Teams and Agile

I’ve been a dev manager now for about 9 months and I have to say that I’m really enjoying this role. It’s not a job without frustrations, and I haven’t escaped the all of the frustrations that I had as a PM - particularly that of trying to balance writing code with “other duties as assigned.” However, when it’s all summed, I think that I’m a much better fit for operating on the engineering side of the house than I am at the business side.

Which brings me to something that’s been on my mind for a little while: process; and more specifically, agile.

In a relatively recent talk, Erik Meijer [in]famously said, “Agile is a cancer that we have to eliminate from the industry.” And while I don’t agree with every detailed point in the talk, I think that Meijer gets it right in saying that we spend too much time talking about writing code and not enough time writing code.

As a data point, the week before I started, the entire engineering org spent 3 days - 3 ENTIRE DAYS in an agile training course. Let me underscore that one more time: there were 3 days where no actual engineering work was getting done because the engineers were learning - not how to do engineering better - but how to talk about the engineering work that they weren’t doing. All of the usual topics were covered: Scrum, planning poker, etc. And perhaps unsurprisingly, the larger body of folks came out of that training with just as much disagreement (or more?) as they came into it with. In fact to this day, there is still not consensus as to what a story point means.

Now, all that said, I realize that the above may have been a bit overly dramatic, but can we agree that it’s a hard sell to brand anything requiring 3 days of training as “agile”? Even the creators of the agile manifesto are coming out saying that we’ve taken a good thing and made it into something horribly unrecognizable. I’m going out on a limb here, but I would guess that such a thing was the result of the usual 2 suspects:

So enough of the negative. I’m happy to say that while my team doesn’t have a constant velocity (because, you know, sometimes we slow down to learn new stuff), we tend to move pretty quick. So here’s how we do it -

We don’t do “Agile”.

We do “agile”.

By that, I mean to say that we have a small set of principles that we go by, and then we leave it up to the team to figure out what tactics, ceremonies, etc. it wants to put in place. We are accountable to a business organization, so we do have some constraints that we need to operate within, but it’s up to the team (which includes our PMs) to determine the best way to meet those constraints.

So first, the principles:

That’s it. From there, different strategies and tactics can fall out and change over time. In fact, as people come and go in the teams, I expect that each unique group will interpret the principles in ways that work best for them. For now, here are some of the things that the teams are doing.

A couple other observations as I reflect on my time thus far and the team that we’ve put together:

So where does this approach start getting challenging? Glad you asked, because that’s where I find myself at the moment. A lot of our initial success was, IMO, the result of the fact that we started out as a small team. And as is often the case, the reward for success is that the team and the engineering challenges get bigger. And ironically, those 2 have a multiplier effect towards the overall challenge. So while I wanted to share in this post some of the things that have worked for us, I also don’t want to be disingenuous (like all those “Agile” consultants) and give you the impression that we’ve found the formula for repeated success. In fact, if you’ve got some tips on what worked for you, I would love to hear them.

However, with a handful of good principles (which I think we have) and a continued focus on hiring great people, I’m confident that we’ll sort it out.

By the way, we’re hiring :)

comments powered by Disqus