Smart Metrics Slides
A Peek at Personas

Starting an Agile Project within a Traditional Framework

Starting Agile Project Agile methods typically don’t cover the early stages of projects very well. They often assume you are ready to start gathering requirements as user stories, or that you even have some candidate features or stories magically ready to go. This is shown by the scope coverage diagram below.

Yet for all but the smallest, most process-light organizations, there are stages of envisioning, feasibility, and setup that happen before we are ready to jump into requirements gathering. This is where many companies come unstuck with agile. Either they jump straight to stories and miss out the early project stuff and suffer disoriented stakeholders and disengaged project offices. Or they go too heavy with the upfront chartering and scope definition, create brittle plans and lose some of the advantages of adaptation and iterative development.

The following diagram is a good place to consider starting from. It combines some of the bare necessities from a traditional approach that will satisfy the project office. Yet it does not go too far into Big Design Up Front (BDUF) to create problems or consume too much time that could be better spent working directly with the business to determine their requirements via collaborative development.

Start Up Activities

The overall duration is short, just 15% of the likely (guestimated) project duration, but yields lightweight versions of the key deliverables familiar to the PMI process police. We get stakeholders informed and engaged, the project office placated, and the bulk of the project duration dedicated to iterative development. 

Instead of a Work Breakdown Structure (WBS) I would recommend a candidate prioritised Feature List or prioritised Story list.

Agile Early Process

Kick-Off meetings using the Design The Product Box exercise, or Shape the Poduct Tree are a great way to start identifying candidate features and then follow them up with Feature Discovery Workshops. The length and number of feature workshops will vary depending on the size and complexity of your project. A three month web project with a team of three people might be scoped in a day or two. Yet a three year project with 30 people will take longer to drive out all the candidate features.

I am actually quite a fan of the early project deliverables like Project Charters since they explain important W5+ (What, Why, When, Who, Where + How) elements of a project, but believe these documents don’t have to be verbose or costly to create.

Instead cover the basics, get people onside and the whole endeavour will go quicker than if you try to start without these things and have to catch people up later.



We were having a debate in the office the other day, my colleague was arguing that waterfall project management style is totally redundant now and nobody uses it, whereas i think it still has its merits with certain projects that its suited to, wondered what your opinion on it was?

Mike Griffiths

That’s an interesting question. I find my knowledge of waterfall project management very useful in conversations about justifying agile approaches. You have to speak people’s language and know where they are coming from to address their concerns, but in terms of simply using the techniques?

For non-volatile, non-negotiable projects or parts of projects I think a waterfall approach is still be valid. A project at my last company involved arranging training for 400 users. This training portion of the project was fairly static, we had two trainers with classes of 20 people scheduled for 3 months. The plan was pretty waterfall, but that was just the training part, the development part of the project was agile. Likewise, maybe HW purchasing, rolling out Office to 5,000 people, perhaps these have less uncertainty and with some review and adapt points could be waterfall-ish, but the projects I see most suit an agile approach more often than not.

Thanks for writing, best regards

The comments to this entry are closed.