agile, top down

In Agile, Top Down Ron Jeffries has written a compelling article describing how he would introduce agile methods into an organisation, starting from the top.

“There’s a recent thread on the Scrum list about how an executive or highly-placed manager could get Agile going. I’ve been one of those guys, and I know a bit about Agile, and here’s how I’d proceed. First, focus management attention on cyclic delivery of running tested software. Second, provide the resources to learn how to do that.”

Ron’s advice centres on measuring the development department by running tested software – that is, by measuring throughput. I very much like Ron’s advice and approach. But I do see some hurdles…

First, if you’re in a position to dictate that the only measure is throughput, that’s great. But if you’re not, the experience of the TOC and Lean guys is that you’re going to have a really hard time convincing the bean counters – and other senior management, for that matter – that throughput is the right measure. Common sense notwithstanding, this is a cost-accounting world. The only saving grace here is that most software development organisations are too chaotic to count anything, so they likely won’t be already counting the wrong things. (An obvious exception being those departments that are or have been in the grip of Accenture-like consulting practices. But then we’re not likely to try introducing agile top down in one of those places, I guess.)

And second, I would expect that the department’s throughput of software will initially (first three to four months) dip until the running and tested parts of the equation are working effectively. Because testing everything, and fixing all of the defects before they go out the door, costs. The investment will eventually be repaid many times over in terms of predictability, trust and speed, but it is an investment nonetheless.

I still think Ron has it right – just don’t expect an easy time of it for the first few months.

Update, 1 aug 05
Discussion with Jason (in the comments on this post) leads me to understand that the choice of metric is critical. In the article, Ron was explicitly and implicitly referring to his own metric, running tested features.

Design for testability

I just found Michael Feathersrant about designing for testability. I couldn’t agree more with his sentiment!

A couple of years ago I worked with a team that had exactly the problem Michael describes. Many of the classes were nearly impossible to instantiate in a test harness, and many of their methods couldn’t be tested without dire consequences for the development environment. Refactoring in the subsystems that contained these classes was also impossible, because of the unpredictable side-effects incurred by doing almost any method call. In the end, after months of frustration, we decided to very carefully and incrementally throw away those classes and replace them with something testable. In fact, that large-scale refactoring was never finished (due to circumstances outside the team’s control), but the improving code definitely “felt” better.
Continue reading

refactoring is hard

I had an experience a few months ago that yet again raised the question of what kind of skills are required to make XP work. I was trying to get a team to adopt TDD, and was having very little success. The reason, it turned out, was that the existing code hadn’t been written TDD. Anyone trying to add a new feature incurred a huge time penalty from trying to get to the point of being able to write simple unit tests.

So I stepped back from TDD and tried to get the team to only produce well-factored code from now on. Another failure, and this time the legacy code was only partly to blame. It turned out that only two of the fifteen people on the team really understood what well-designed object-oriented code looks like. The rest wrote working algorithmic code, and were completely blind to the duplications and strong couplings they had created. For lots of reasons, including timezone differences in some cases, it was impractical to pair with everyone to help them towards an understanding of ‘simple’ code. So I did a few public worked examples via NetMeeting, and still had almost no impact on the code being produced. I guess that refactoring is a design skill, and that it has to be taught, because most programmers don’t learn to appreciate ‘good’ code in university.
Continue reading