Agile in the Trenches

I found myself in an email exchange with a friend recently who described his team’s efforts to implement some Agile practices. This post is a distillation of a much longer email thread between us, and my take on it is that he wasn’t trying to bring Agility to his team so much as he was simply trying to bring professionalism.

Never having been a manager before, he recently found himself an interim leadership position while his team was recruiting a replacement for the previous team manager. During his tenure, he tried to implement some positive changes. After reading his experience, I think it is one we can all learn from.

Here were his bullets.

10 Changes for the Team

1. We now integrated changes from Main to our feature branch every Friday at 3pm.  We may not be able to integrate back every other week but we can take the changes weekly so that we are  never months behind the curve (and paying a huge tax when we want to finally integrate back). 

   Pay small taxes instead of big ones.  Everyone shares this load, there isn’t a "integration monkey" who does it all.

2. We meet every morning at 10:30 for a dev team standup.  Normal Scrum rules apply.  Time limit for whole meeting was 7 minutes.  We don’t wait for people who are late.
3. We would do all planning/development in 2 week increments (I did not call them sprints to our team but it’s what they were in practice). It was amazing how many people could not decompose their work into two week increments at the beginning.
4. We would demo the new features at the end of every two week milestone (this was our postmortem meeting but I kept it demo focused).  Demos were key.  If people knew that they would be showcased they made sure they were being honest about what was done and what was still baking.
5. All devs had to have meaningful feature ownership instead of just being "random bug fixing guy". We had two people on a team of 8 without product work assigned to them.  They were just picking off bugs as they saw fit. That wasn’t good for the team or their careers.
6. All devs had to have unit tests with every check in (I later had to amend this to say "meaningful unit tests" and put coverage numbers on it because people were creating stub tests that just passed – I nearly blew my lid when I saw that).
7. All code had to be reviewed by someone not working on your feature (but on your team).  We had too many "wink and a nod" code reviews. I wanted code to be understandable/reviewable by people who weren’t working on the immediate feature.  UI guys shouldn’t be doing crazy things only they understand (do the crazy thing – just make it understandable).
8. Pair-programming was encouraged. Everyone got a second or third chair for their office.  Pair-debugging was nearly mandatory.  This uncovered the fact that nearly half the team had no idea how to effectively use the debugger. Nearly the entire team did not know how to debug managed or native code when you didn’t have access to the source.
9. All of the crap we normally did the weeks before integration ("quality gates" – coverage numbers, localization checks, etc) all had an owner. The owner didn’t have to do the work, but had to report on the progress and make sure it got done by the right people. And no more cramming it in at the end, instead we would manage it throughout the dev process.
10. No working weekends. Just don’t do it.

    If we can’t get our work done during the week then we will know within two weeks and communicate that up then.  Don’t hide poor estimates behind weekend grinds.

Results

The next 4 months went great.  We hit every milestone.  We communicated problems early and got the resources we needed to solve them while there was time.  We ended up coming in 8 days early with all our committed features and several stretch goals done.  Moral was high.  There was no grind session at the end and we nailed, for the first time in 3 years, all the quality gate work.

The Aftermath

But alas. When the new manager was found and I was relegated back to my post as an individual contributor, most of this was ended.

Immediately #1, #3, #4, #8, #9 and #10 were ended.

#5 took about 6 weeks to be killed.

#7 has become a joke.

Reviews are "mandatory" but they are neither enforced nor rewarded.  The only time anyone cares is when there is something obviously bad that got checked in they might ask who reviewed it.

The daily standup is the only thing that really remains in any form and even it is about to be killed.  What started as a dev-only 7 minute Scrum has turned into a 20 person daily bitch session that takes 10 minutes to get going and then last another 20 with nearly 0 value.  No surprise people are begging for it to be killed and I get negative reactions when I try and get it reverted to what it was.

And, His Professionalism

Now, I’m as "agile" as I can be.  I still personally follow the rules above (to the degree that I can). I can’t force people to take an integration, but I can bitch loudly when it’s been too long.

I plan in two week sprints (which annoys my new manager), I send out code review requests (and make sure they get done) to people who aren’t on my feature. I spend more than half my time writing unit tests (this seems to really bother some people – it’s very odd).

I don’t work weekends or nights (unless absolutely necessary to help with a larger issue. It’s happened once in the last 6 months). I think this annoys my teammates who do.  I have working demo-able code with every check in. This makes my tester very happy since he can always show his boss what he can test.

What I don’t have is bug debt and this is a big part of the reason I go home at night and weekends.  I still write bugs, sure. But, they are far less frequent in the checked in code, and much easier to fix (though it’s always where my tests missed … funny, that).  I have a manager who always knows if I’m ahead of the curve or behind the eight ball with respect to the schedule.

I guess my point of the whole thing, and how this all began, was that there are no absolutes.  Just because my team isn’t "Agile" doesn’t mean my team couldn’t do what we did.  And just because my team doesn’t do agile doesn’t mean I can’t.  And just because I can’t do all of it doesn’t mean I can’t do as much as possible as well as possible.

Cockburn wouldn’t call me agile.  I know that.  That’s OK. People are starting to catch on.  We’ll get there.