Atern Principle 5 – Build Incrementally from Firm Foundations

Have you started an agile project and realised part-way through that you had made a decision early on that now needed to be changed? Did you ever deliver on time and not meet the objectives of the stakeholders? Did you find out too late that an operational team is impacted by your project and you have not planned the transition for them?

I have heard and read stories of allegedly agile teams running into just such problems, and they are all symptomatic of poor planning. At the APLN session in Washington in 2009, Scott Ambler said “of course we need to do some up-front thinking!”

Agile methods generally do not consider the early stages of a project. I alluded to this in my last post on project management. Assuming we still view the delivery of a solution to a set of requirements as a project, we need to consider what happens before the first development iteration. And this is where Foundations comes in.

The Foundations stage of an Atern project comprises three basic areas (in parallel)

*) Business Foundations – compiling the business case and an initial prioritised requirements list (PRL)
*) Solution Foundations – obtaining an understanding of the high-level solution, considering system architecture, business area change and development approach and standards. Not in detail; just enough to start development without making big expensive mistakes
*) Management Foundations – the governance and organisational aspects of the project, how the project is to be managed, identifying who will fill each role, how key project management practices will be applied, and creating a high-level delivery plan.

How could you possibly start development without at least thinking about these aspects of a project?

How much work is undertaken during Foundations is, of course, dependent on the size and complexity of the project. How that work is documented is subject to the principle that we only work on that which is useful. If a formal document does not contribute to understanding, one need not be produced. But some things are well worth capturing in some written form. Here are some examples:

* Vision – capture on a single PowerPoint slide and put up on the wall of the Team area
* System Architecture Definition – diagram it and put that up on the wall too so everyone can refer to it throughout the project.
* Prioritised Requirements List – for audit and traceability reasons these should be captured in a suitable tool of some sort where everyone can find them.

Timebox this Foundations stage appropriately, plan the work that needs to be done and review what has been done with the team and stakeholders when you have finished. Consider the question -

Having done this Foundations work, is the project on a sound footing? Do we know enough to proceed with confidence?

Note that cancelling a project at this point should be viewed as a success.

About these ads

About aterny

Agile enthusiast and evangelist, DSDM practitioner, trainer and coach. Specialist in Agile project and programme management, governance and organisational transformation
This entry was posted in Agile and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s