Incremental Agile
automated builds, test driven development, code reviews, scrum, software development
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.
Ed Gibbs @ May 13, 2006
I think one nugget of valuable information in the book “Death March” is that death march projects are *never* truly important projects. (The participants may be told it’s important, but really Important projects are given more of what they need to succeed.) Thus death march projects are more likely to be cancelled, even if someone turns around the development/technical side of things.
I’d like to hear more about why the enterprise rules engine proved to be difficult to unit test. The large fat-client application that I currently work on has a very extensive suite of unit tests. There are currently efforts underway to “webify” that application and a key part of the processing will depend upon an enterprise rules engine. What was it about the rules engine that proved challenging to test?
OK, for the enterprise rules engine there were a number of problems. One was that it had a visual workflow style tool wrapped up with it which the team had taken full advantage of. That is to say a message went in and a ton of transformations happened to it. My belief is that we probably missed the whole point with the rules engine there and used it to do something it wasn’t really good at.
We also used an embedded persistence engine it came with, which we had to later pull out into iBATIS DAOs when we found out they didn’t expect people to use them.
It had it’s own sort of hacked natural language and Java like syntax that wasn’t that well documented and used nowhere else.
The essential problem was the way we architected it was to pass an event message in and have it fire off everything behind the scenes and then check the return and the database at the end. It just didn’t work.
If we had it to do all overall we may have abandoned the rules engine concept for it altogether, used a more open rules engine like Drools, or used the enterprise system in a much nimbler fashion to merely check individual business rules, leaving much of the workflow to plain old POJOs.
And remember to take all of this advice with a grain of salt. I haven’t worked with the rules engine for 9 months and I never felt comfortable enough with it to know where we went wrong for sure.
On the concept of death march projects never being truly important, I’d have to agree. I felt like the project was doomed after about 4-5 months on it when it seemed the product owners didn’t really seem involved.
Regarding the order of introducing Agile practices, and particularly the placement and method of code reviews, it’s hard for me to see why you say that you can “vouch for most of this advice.”
You yourself say that choosing “informal code reviews” led to “After two years we’re just now implementing code reviews, and I can see why we should have done it so much sooner.” And even now you’ve still got a “mashup” of code reviews.
Why not point the finger back at “this advice” and say, at least regarding code reviews, that late, and informal, is just not the way to go with code reviews.
I think if I were introducing Agile practices, and restricted to that list, I’d pick a very different order. Something like this:
* Add version control
* Start regular, formal code reviews
* Add build automation
* Add unit testing
* Bring architects into the fold
* Setup standup meetings
* Introduce Agile ideas
On the code reviews, I think I should have insisted and actually enforced them. I didn’t and we really didn’t do them and it hurt us. I’m just passing on my particular experience.
On the order, I don’t think any of it’s absolutely critical, but I can comment a bit on my feelings around your suggested order:
* Add version control
(OK, you can start here if needed)
* Start regular, formal code reviews
(This is going to feel a bit authoritarian and scary as a large change. I’d wait a bit on this to get some wins with other practices first.)
* Add build automation
(Again a good early thing to get in place.)
* Add unit testing
( Good idea to get started, but with a large legacy codebase this is going to take some time to see the benefits and get used to the idea, and this isn’t necessarily TDD at this point.)
* Bring architects into the fold
(I don’t have much experience dealing with this to say when it makes sense to do this. I promoted the only architect we have from my team. He was already aware and pushing many of these practices even if he was generally overwhelmed with coding assignments.)
* Setup standup meetings
(I think you do this first. It’s so easy to start and easy to sell. You get a better idea of what’s going on. You don’t even have to have source control to hold a standup.)
* Introduce Agile ideas
(I like putting this toward the end. The principals don’t really matter until you get how the practices are starting to help you. I kind of avoided discussing this much at first even though I knew I wanted to do Scrum, so I guess I really introduced them later than my post would suggest.)