Critical Path in agile project

Question

I am doing a fairly large project ( by my standards) and I have opted to take a agile approach to this; in that I will be doing the project in sprints.

There is no team, just me and my client, though some 3rd partys are involved in a small way. The development project ( a web shop ) arose from a large discovery project that I did for the client; and as such I have a lot of discovery information which is not necessarily organised as a development plan.

I need to get moving on this project and I don't want to plan the entire project from start to finish ( it may change mid stream anyway ) so what I did was to take the parts of the discovery that I need for the first iteration and plan those out ( and am currently working on that first iteration). I then will do the same for further iterations until the project is complete.

My problem is that doing it this way I will not have a critical path worked out because I am never planning the project as a whole, just each iteration. I know this may mean a delay in the project ( as I may be working on iteration 3 and end up at iteration 4 and find that there was something there that I should have started weeks ago eg get the client to add the products to the web shop or something ) but my question is that other than this is there any disadvantage to doign it this way and is there any better way of doing it ( given that my goal is to avoid planning the project as a whole at the start )

In short I think I am having difficulty understanding how critical path works out for an agile project or do with have multiple critical paths ( ie one for each sprint )

Answer 1

First off, if I can recommend, call them interations. Sprint is a specific branded name for a Scrum iteration. Iteration is a more generic term used in agile and other lifecycles. You're doing your release in a series of short iterations and then reviewing the plan after each iteration. Working in short iterations (I would suggest two weeks) is a good idea. The client will like being able to see measurable progress and reviewing it with you.

Critical Path is not as critical in agile planning, for the sheer dint that you're constantly reviewing the plan and adjusting as needed. In Big Development Up Front projects (waterfall) knowing your critical path is more important since you won't be adjusting the plan as often.

You do have two "critical paths" in agile, the iteration path and the project path. Mike Cohn (respected agile coach and author) writes about this on his blog at http://www.mountaingoatsoftware.com/blog/the-critical-path-on-agile-projects.

In short: - Don't worry about the iteration critical path. It will be obvious in a short iteration and will be reviewed as part of the daily check points (even as a one man team, you should hold an individual "stand up" each day to review your progress). - For the project critical path he recommends the rolling wave planning. At each iteration planning spend a few minutes looking ahead to the next 3 sprints and see what dependencies or issues you can discover. Address them in planning and get them in the backlog.

Having a solid dependency map or document will also help you. Make sure your client is aware of what you need from them, with solid dates for when it is needed. Report on this as part of your regular reporting to the client.

Answer 2

Try to plan a few iterations up front, so you can reduce delays that are caused by not finding out / addressing points in time. As a general rule,

• You must see all the tasks that will be necessary after you finish your current iteration (so when working on i3, you have a backlog that fully covers i4).
• You must have total understanding of tasks for the current iteration (so when working on i3, you must also detail i4 stories so all questions will be clear)
• And of course, you must work on channeling in new requirements into the backlog as they surface

Based on this, you can assume that even if there will be delays from an expected ideal course of project, they will either caused by gaining a better understading of a given topic, or by changing priorities (reordering of the backlog). Both of this are natural conclusions of having an iterative approach.