The Rocky Road to Agility

A few months ago, I wrote about the beginning of our journey on the path to agility. Since then, we’ve made some major strides and also had some serious set backs.

Our process was getting better, but we continued to struggle with the legacy code base. I was writing tests and refactoring the code base, but was still the only one doing so. The team was seeing the benefits I was getting out of it, but simply didn’t know how to do it themselves.

I needed to find a way to train the team, but I wasn’t sure how to teach it. I had learned how to test drive by simply doing it on the Rubberduck project. By trial and error, I had learned what to do and what not to do when writing tests. We couldn’t afford to have the team learn the hard way.

I needed help, so I did what any good programmer does when they need help, I turned to Google. After a bit of searching, I found a wonderful set of tutorial videos from JBrains. I can’t say I agree with everything he says and does in the videos, but they’re certainly good enough to get my team started.

At first I tried simply disseminating the tutorials to the team, but no one actually watched them. We discussed this at our retrospective and one of my team mates suggested that we all watch them together, so we set up a weekly hour long TDD Training meeting. They ate it up. I mean, they absolutely loved this. I don’t think any of us had ever worked in a place where management wasn’t just okay with the entire development team spending an hour every week simply learning about their craft, but actually encouraged it. 

We finished the tutorials in a few weeks time. The team was excited, but hadn’t actually written any tests yet. Next up, mob programming! We took the test list from the tutorial, and implemented it ourselves.  It was a struggle at first, but after a few sessions, the team was starting to get it. They were starting to get so good at it, that I actually bowed out and skipped a few of the training sessions so that I could focus on getting a particularly nasty project out the door.

In the meantime, I had test infected a large part of our actual code base. My team mates were learning to deal with maintaining existing tests. They were building the muscle memory needed for a good “code, run tests, code” cycle. (We’re still working on a good “red-green-refactor” cycle, but I digress.) Unfortunately, I had largely been pulled away to work on that “nasty project” that I mentioned. The project was started by our most senior developer (and my greatest Agile ally), but he abruptly left the company with the software only about half done.

This was a double edged sword. It pulled me off of the project I was working on and devoured my time, while also pulling me out of the office and onto the factory floor. On the bright side, it threw my team into a heavily tested code base. Suddenly, they weren’t just maintains and running tests, they were adding new ones! This was fantastic, but it quickly became clear just how much I playing the role of “scrum master”, unblocking the team and keeping us on task. Our productivity tanked and the team was in disarray from losing the two of us.

I wish I could say that we handled this gracefully, that we took some action that miraculously put us back on track, but I can’t. We’re struggling. I managed to get the project finished, and just as we were starting to get our feet back under us, we hired two new team members and we’re back to square one. We’re a brand new team who needs to figure out what works for us all over again.

One of our next hurdles is going to be our new lead developer. He’s a genuinely nice guy and competent developer, but he doesn’t understand Kanban. He’s only ever worked with “Scrum” and thinks that Agile is Scrum. I use quotes, because he has some odd ideas about how to implement it, in my not so humble opinion. There’s lot of talk about tracking hours and having someone from our department being the Product Owner.

First off, the Product Owner isn’t a person from IT. It’s a person from the business who’s able to make decisions about what needs done and what the priority of those items are. They also are the sole person responsible for signing off on a Story as being Done. I just can’t fathom how this function can be performed by anyone in IT. A business analyst may be able to help the PO enter items into the backlog and craft User Stories, but they’re not in a position to set priorities. You need someone from the business to do that. Thinking that someone from IT can perform the Product Owner function reeks of a corporation who started doing miniature waterfalls and called it Scrum.

There’s also this idea that tracking hours is the only way to accurately estimate. It’s not true. A quick search for “kanban estimation techniques” returns numerous academic articles showing that Little Law’s gives us a reliable way to give estimations without the added overhead of having developers track their time.

So, I made a deal with our new lead. I’m willing to time track, if he’s willing to compare my estimations to his. I’ll let you know how it goes, but it looks like I have an uphill struggle in front of me with someone who’s been “doing Agile” (note the big A), but hasn’t even bothered to read the manifesto, question why he’s using the process he’s using, what value he’s gotten from it, or if there are better ways.

I’ll let you know how it goes once it’s played out.

Until next time,

Semper Cogitet


, , , , ,

  1. Doing what’s best, even when it sucks | Christopher J. McClellan

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: