Software People Inspiring

Start Development As One Team

In his spiffy book Agile Modeling, Scott Ambler suggests teams can establish a basic roadmap for architecture by undertaking a preliminary iteration ("Iteration Zero") where they cherry-pick some interesting user stories and collaborate as a team on designing a basic skeleton for their design before they go off and tackle stories by themselves.

I wholeheartedly endorse that approach. When it's been up to me, I've started development on new teams by taking everyone into a room with a laptop and a projector and tackling some key user stories as a team.

This might seem wasteful, but I assure you - if done right - it can actually save a lot of time and heartache further along.

What can happen with Agile teams is that they go off into their own little corners and solve design problems in isolation. Misunderstandings and disagreements abound, and are only discovered as code is integrated. And even we're integrating early and often - nay, continuously - this is still shutting the stable door after the horse has bolted. Integration is an expensive and ineffective way to establish a common approach.

Let me give you a couple of practical examples:

On a project for a client in the energy industry, a team of Extreme Programmers picked up their user stories and went off in pairs, each pair doing their own thing. About 4 weeks in we noticed that we'd somehow ended up with 3 versions of "Customer" - 3 customer tables in the database and 3 customer domain objects in our code. Being so fundamental to the model, unpicking this mess was going to take a lot of time. So, naturally, we didn't bother and just lived with the mess. Which turned out to be a costly mistake. (One of many, in fact.)

A little closer to home, teams undertaking the Codemanship Agile Design workshop have sometimes failed to spot that the user stories "Borrow a video" and "Return a video" were connected. On a couple of occasions, we've ended up with one pair building their own version of "Borrow" or "Return" so they could acceptance tests their user story, without either versions connecting in the code. A schoolboy error, you may think. But you'd be surprised how easily even very experienced teams make mistakes like this when they fail to collaborate closely on design.

So, I've seen many boo-boos over the years caused by teams failing to establish a shared vocabulary and a shared approach to design. Typically, you find inconsistencies in architecture (Exhibit A: the web app with some .aspx pages using Web Forms and some done using ASP.NET MVC), duplication of concepts that show up in multiple user stories (e.g., the 3 Customers), failures to "join the dots" on key workflows, and all manner of other gotchas.

It can be good business sense to invest some time early in development to aligning your team and getting everybody roughly on the same page as regards what the application is about and how we're going to approach building it. I've always found that the most meaningful way to address these issues is to address them practically, with real user stories, real acceptance tests, real design sketches and - most importantly - real code.

After maybe 1-2 iterations, you will have laid the foundations on which the team can now build.

I highly recommend trying it.

---