Frameworks and Agile Development

Scott Bellware writes about architects in agile teams.

In his blog, Scott also mentions building frameworks:

An agile architect also provides technical frameworks that keep the team in the intended groove -- and yes, this can even mean building frameworks in the course of an agile project -- as long as there's a customer-approved card for it, and as long as it's built micro-incrementally.

Why does it always seem that people who only do Agile development think the current project is rooted in vacuum? (Also see one of my previous posts.) What if you are writing project #3 which is very similar to the project #1 you did for another customer? What if project #4 which is in the pipeline is also similar. Once you've worked on several similar projects you can identify common "things" you can automate or write only once.

I am not saying that you should sit and theorize on what will be needed in future projects (far from it), but if your are building several projects in a row and you see that certain things that are worth moving into a framework -- do that. You don't need a customer card for that. And no, customers shouldn't pay for that (fund it from your R&D budget -- and if you don't have one, get one) since this, indeed, won't bring them any business value. (However it will bring you business value on your next engagement. It will also bring business value for your next customer as you would be able to save time by using code which is already tested and proven.

If there's a place for a technical framework within a project, then follow Scott's suggestion and get customer approval for that. In these cases the payoff would happen within the project.

By the way, Scott's main theme involves the responsibilities of architects on agile projects. I agree with what he says -- to an extent. One thing I don't agree with is that it has to do with agile projects. I think it has to do with project size. On smaller projects (e.g. 10 developers or less), there is no room for full-time architects. If architects are dedicated to the team (as would be the case in most if not all, agile projects) then they will need to have additional responsibilities (i.e. code as part of the team), if they are in charge of multiple project's or the project is large enough (e.g. 100+ man/years ) then she would probably not have the time to code. The same thing happens with "traditional" team leaders/project manager. If you are the team leader of a couple of developers, you will code with them. If you manage 50 people, you would hardly have any time for that (the difference, of course, that the architect should remain technical even on larger projects).

(I've written my views on "should architect's code" in the following series round 1, round 2, round 3. Also back in 2005 I mapped my SPAMMED framework to agile projects)

Posted by Arnon Rotem-Gal-Oz at 03:32 AM  Permalink