In Practices of an Agile Developer, Venkat Subramaniam and Andy Hunt layout how a technical manager might incrementally introduce Agile practices. There suggested list is:

• Introduce Agile ideas
• Setup standup meetings
• Bring architects into the fold
• Start informal code reviews
• Add version control
• Add unit testing
• Add build automation

I can vouch for most of this advice, because before Practices of an Agile Developer existed this is pretty much how I started introducing practices on my team two years ago.

I inherited a large project in which all 10 of my developers were working at the time. The project was a classic big design up front train wreck kind of project and most of the developers were burned and demoralized.

I came into the organization determined to finally implement something like Scrum. At my previous professional services firm, I had to work within accepted fixed bid contracts with conservative customers and very little leeway. This environment was a chance to really implement a better way through Agile (OK, I can be a bit idealistic).

I setup a standup meeting with all the developers a few weeks after I started. I had to get ahold of where the project was on a daily basis and it forced the developers to share information on the different modules they were working on. A bit of grumbling intially, but they came to see the value in it after a little while and we had a much better idea where we stood. I was excited I had snuck in a Scrum practice, but I didn’t go around calling it that yet because I was still fairly new.

I didn’t have architects on the project, but I did have only 2 of 10 developers writing the back-end code where 80% of the work was. After some prodding I got them to understand that we were going to have to mentor up more developers if we ever hoped to get the project done. By the end of the project everyone was able to work on the back-end code.

Next suggestion would be informal code reviews. We talked about this, sort of buddy type reviews, but we really never implemented them. After two years we’re just now implementing code reviews, and I can see why we should have done it so much sooner.

Luckily we had version control, unit testing, and an automated build in place. There were big issues with out unit tests though. They were largely integration tests and they were brittle. One of the developers had Cruisecontrol up and running so we had that covered, but since the integration tests were often failing we’d have broken builds for weeks at time.

These were some of the hardest areas to really implement, with unit testing being the most difficult. Due to some architectural decisions in using a enterprise level rules engine writing unit tests was next to impossible. At least at the time I felt that way, had I been around for the beginning of the project, I probably would have avoided the enterprise rules engine in favor of a simpler solution that was testable. It’s turned out that implementing true TDD and code reviews have taken longer than I hoped, more like 2 years.

As a sidenote the large project I inherited was killed off by the customer after we delivered to the final specification. Adopting Agile practices is no guarantee you can save any project.

Some days the plans come together. I’ve been pushing hard to implement TDD, code reviews, and continuous integration for at least a year now. Today I helped one of my developers setup Clover to exclude the one package of generated code that didn’t have or need many tests. This is a pretty small code base, that just performs about 30 business rules and returns the results via a web service. A quick run of the tests and:

Total: 98.2%

The remaining 2% were a few exceptions that weren’t thrown and captured in the tests. The caveat is because of time pressure and figuring out how Websphere handles web services the developer wrote the tests after sending off the code to QA. Still it’s definitely a great sign of progress.

Cote, now of Redmonk, has a recent post describing what I call Clickety Click Coding and he refers to as Right-Click Coding:

I’ve never been one for model, tool, or drag-and-drop based development. Oracle development, at least as presented to us and as illustrated in the hands-on-lab (where we actually coded up EJBs and Web Services) is all three of those to the extreme. I call it ‘Right-click Coding,’ because you’re always right clicking on things to configure different wizards and properties instead of writing the code.

Unfortunately Right-Click coding does make great demos, though things like Rails are making in-roads there with command line driven demos. I despise these demos since they’re typically shown by sales engineers who never have to maintain these quick demo solutions. There’s a lot of hand waving about how you have this fully implemented domain model that allows you to just hook together all these loosely coupled services even though you’d actually have to write all those nice services in the real world.

The worst part is that they’ve invited a few business folks, who now thing all the coding is the easy part. Luckily a lot of sales engineers push inane ideas to the hilt and say the magic words, “Oh, with tool X you can just have your business analysts draw out the process.” I do a bit of cheering at this point, because those same business analysts have heard this line before. They’ve tried to use these right-click modeling tools before and they just don’t behave like Excel or Visio. Usability appears to be a very low concern for these tools which often assume you’re a developer who’s spent years in various difficult IDEs. And that’s the point business analysts get completely, “Heh, this stuff is for programmers.”

And then then there’s the other down side of relying on a tool to just generate everything:

Of course, I’m not sure how well things will go when you start having to debug and track down problems. I’m not sure there was a right-click option for ‘Fix all broken things.’

My favorite question to ask the vendor at this point is a pretty simple one,

So how do I test this?

Oh, well you can load test it for performance with something like Mercury’s LoadRunner product.

No, how do I unit test the code?

Well, your QA department can will fully test the code with a set of test cases.

But, how would I write a unit test for this?

Hmm, well the web service we just created has a client code and a simple HTML test page that you can use to test the web service.

OK, but that’s a manual integration test that tests the whole service at once, how would I just write an automated unit test.

Well, let me get back to you on that I know there’s a feature we have to cover that I just haven’t used it.

I attended the SACJUG meeting tonight. They sometimes have a rough time rounding up speakers, and tonight was no exception. They had a talk lined up on AJAX, but their presenter bailed for a consulting job in LA. So we had a roundtable discussion for several hours.

As Ted Neward is still loosely associated with SACJUG and Chris Scheuble mentioned that:

Ted Neward is predicting Microsoft will move all their apps publicly to .NET according to Chris.

I guess that would be a lot of rewriting. Anyway I will probably buck up and agree to do a presentation on Fitnesse, both to force myself to spend more time with Fitnesse and to expose it to a few more people.

I’ve been getting by with just Excel and a large cork board for tracking the one Scrum project I use. Still as a tool junkie and a hater of Excel in general I finally got around to trying out ScrumWorks.

So so far:

• Download and install cycle is pretty short and it just worked including the WebStart client. I’m running it on my work laptop, and since I don’t like to weigh a team down updating tasks, I’m maintaining the Sprint backlog and tasks.
• Entry of tasks and backlog items is fairly easy, though you have to right click a lot for add new. Much better than XPlanner’s multiple click interface.
• The ability to move backlog items in and out of a Sprint and to drag and drop the order of items is really nice.
• It calculates everything on real time which is a pain. Since I was entering data on a Sprint that was 8 days in, I have to wait until tomorrow to even get a data point since you can’t effectively go back in time. I guess they assume you’ll start the project with the tool, not try it out midway.
• If its going to replace Excel I probably need some better looking export reports, or I’m going to have to try screen captures.

I’ll give it to at least the end of the current Sprint as a test.