How much up-front design or architecture to do in an agile project is always a contentious issue. Having the job title with "Architect" in it makes me personally biased; Having a background as a developer and product manager in successful agile XP gives me a huge respect for agile development practices and somewhat balances my development approach. This posting tries to define my current view on how to balance good up-front architectural planning (minimal, but where it counts) and how to assess whether more or less architectural oversight needs to be applied during a project through intervention.

Many agile scenarios promote that a project be split in a set of features; These features prioritized into milestones by the "Customer" and then these features be worked in in almost a serialized fashion. The focus is on completing the current feature, whilst promoting that refactoring be the tool of choice when a later feature adds or alters a previously signed-off complete and closed item.

I can see some issues with this when followed blindly. My definition of "Refactoring" centers on improving currently functional code with lessons that emerge throughout a project. What I see in many projects is that "Refactoring" is the title given to an almost rewriting of a previously closed feature because the number and scope of changes to keep it operating in the face of the new feature. This is bad, and it is seriously affecting development velocity.

Here is my proposed compromise, that allows features to be built in (semi)-ignorance of future features, whilst still allowing for intervention if a pattern of serious re-writing (or refactoring if you want to water the terminology  down) begins to affect velocity -

• Up-front architecture that should always be carried out as iteration 0 of any project includes anything that WILL BE NEEDED for EVERY feature (or requirements that will cause a registration of almost every feature that has already been completed). This includes technology choices, communication and integration patterns, operational requirements like logging, deployment strategy and localization requirements can be used as a starting list.
• At regular intervals (e.g. 1/4, 1/3, 1/2, 2/3, 3/4) of the way through features in a project analyze the task breakdowns of the latter features to determine if there is a class of task that might be eliminated by an architectural building block or by more holistic design/planning

It is the second bullet point I want to discuss further in this posting.

My boss David Anderson run a pretty tight Lean Software software development department. A lot of the lean principles are facilitated by using a Kanban tracking system (and its electronic counterpart being the data captured in Microsoft TFS). The data captured is very thorough and used as a management tool in determining progress, bottlenecks and general project health. My goal is to use the feature and tasks completed so far to assist in determining where architectural intervention or more up-front planning could avoid that class of task being necessary in future work.

Lets look at an example - In a current project that is very integration heavy with a large ERP/CRM system, that our lack of solid planning for the interface specifications (which weren't ready when we started, but are available now) is cause way too much rework as we move through the features in a linear fashion. It way pay dividends in team velocity to introduce a feature right now that looks at the spectrum of interface specifications we now have and strawman the entire message / web service interfaces. If this reduces the number of tasks in future feature that would have revisited completed interfaces and added that extra field, or changed that database schema - improved velocity is inevitable.

But there is a balance - striving for perfection in this planning intervention would also be catastrophic to feature completion velocity. Going overboard with architecture is just as evil as sticking ones head in the sand and simply working longer hours or hiring more developers to close the backlog gap.

Be interested if other teams have analyzed task types to look for patterns or work that might be eliminated by a targeted architectural focus.

Troy.