Search This Blog

Loading...

19 March 2008

Design/application architecture within Agile

As I said in my previous post, I have a couple of issues with Agile. In that article I spoke about measurement within Agile supporting EVM which I think is necessary for business decisions. The second issue, which I did not discuss, is design/architecture.

As some of you may know, I am a business analyst. However, I started out as a programmer and had the opportunity to work on several projects using Extreme Programming (XP) processes. I also worked as a developer/project manager for one of these XP projects.

Even when doing XP, we still felt it was best practice to go through a design phase that included a high level architecture of the product which we adhered to for the rest of the project.

When you are building something from scratch, you need to have an idea of the direction to go. Minimally you should have a general diagram outlining how the pieces of the product (e.g. key features) will fit together. So when our team was asked to implement an Agile development process where I work, I couldn’t help but ask the obvious question: "How will design fit into our process?" The scrum-master suggested that design was an outdated concept.

After doing a bit of research, I found that the community thinks that it is an iterative process where the project defines the size, formality, and timing of the design process. These processes all apply if you use the Agile Modeling Methodology (AMM).

I'm not sure how that relates to Scrum, but from my inexperienced vantage point it looks like Scrum is a way of managing development while AMM is a approach used to aid implementation. If any of you out there have some insight into their relationship, please post your thoughts and references in the comments.

Here's what I like about the AMM design/architecture concept: it is iterative and the overhead is only as much as makes sense. You do “just enough” up front to get moving on the project and then refine the architecture as you go. Thisarticle outlines a great general rule about when you need to do more or less design up front.

I love that the documentation of the design can be as simple as "a plain old whiteboard (POW) sketch" or a full fledged model, if necessary.

As I have learned more I have found that if someone tells you there is no design or architecture in Agile, you might want to question their motives for avoiding it. The true answer is, "There is only as much design up front as makes sense."

Agile is not an excuse to get out of doing the things that are needed for making business decisions like Earned Value Management (EVM). It is also not an excuse to get out of doing all of the up-front documentation. Cutting back is not cutting out.

For example, creating a more formal model that might help the Product Owner or external stakeholders understand the project better. Agile is a means to adjust the overhead of a project to be just what is needed and not more than that. In my book, that's the most sensible goal in the industry.