Techn@gerial

There is no doubt that agile development techniques (of which there are several, Scrum, XP, Lean etc.) are an excellent way to empower a development team and enable them to really engage in the process of delivering software.  I will focus, such that I need to, on scrum; my preference.  These techniques delegate responsibility (not accountability) to the technical team, led by a scrum master.   This enables them to decide what is done when and how these decisions are made relating to any given set or state of the requirements.  The daily scrum meeting assigns priorities for work and addresses issues arising.  It is a technical forum where the team frankly raise and discuss their issues and experiences.  Scrum is usually composed of a series of sprints where requirements/features/stories (use cases) are solved in design and code.  But how do you surface this kind of project within your business and how do you report on the unknown?

For projects where there is a high level of uncertainty, this technique and agile approaches in general are very effective.  As such they are very much suited to PoC work or development where validation of the solution design is required during development.  Also, if your product lends itself to barebones release with phased feature additions during the progression to completion, then agile is for you.

The iterative releases that this approach delivers also provide a mechanism for engaging quality processes early thus helping prove the end product earlier after code completion, the bulk of the regression will have been run several times by then.

When engaging this type of model it is imperative, especially within a business with traditional delivery expectations, that the process is communicated appropriately.  The outputs and, importantly the timing of them, will change somewhat from your standard software development process, coming to fruition at the end of each phase. 

The concept of certainty in software design and development is in my opinion an oxymoron.  As such an iterative approach can help build confidence in moving towards delivery and this is often attractive when faced with the often enervating reverse situation you get with waterfall type models.

But the key point here is in fact about managing the delivery.  If we decide certainty is not possible upfront, for whatever reason, then when it comes to planning an agile project and satisfying your senior management’s expectations for dates and milestones, the project manager at the helm of an agile project can experience a very real sense of the unknown.  Clearly this lack of certainty doesn’t sit well with the date driven, commercially focused, benefit demanding business world.  That is why agile methods have a heavy portion of customer participation, to bring them along on the journey and to share goals.  This is all very well if your customers or management can and want to work like that.  If they want dates there is no avoiding the pre-requisite planning (or at least a fair amount of it) you would expect to undertake on a traditional project.  So that tends to rule out agile projects in a date driven context.  At least if you speak to agile purists…

Using your existing project management methodology, specifically the reporting aspects, it is possible and effective to consume the agile component that relates to the delivery of the software product.  Clearly not all project activity is development related; sale materials, marketing campaigns, training, etc.  So the approach I have seen work is to use the agile method as a plug in for relevant project types.

Obviously with no design or at best a high level one, estimating and planning out the work is difficult at best.  So the idea is to build your scrum and poll them on each requirement and come to some consensus about how long each component and feature will take to develop and integrate.  This creates your project backlog and you then use your metronomic sprints to work your way through it with the estimates you have to hand.  Anything that is not able or necessarily needed to be resolved or designed is deferred to a later sprint and there is a recap between each sprint.  This sprint planning will yield a high level milestone plan, some of which may not be palatable for management reports but there will be aspects that are.  This schedule when combined with your wider reaching delivery plan will give you everything you need to report on progress. 

Plugging scrum into your PMM

If you want to set expectations up front that the milestones may move or swap position and appear unstable that will help, providing that overall you are burning down work to an expected level that shows progress and delivery focus.  Any material changes will obviously have to be raised through your standard change management process.  These changes will draw scorn and cast doubt on agile, but then they would probably have happened much later in the day using a traditional method and as such are harder to resolve and usually significantly more expensive.  Managing these messages will be demanding and require a level of tenacity, good developers having estimated will help.

Where agile methods fail is usually at the start and usually for the same reasons;  too much enthusiasm to get started and a lack of management and control.  Providing you explain and publish your approach, ensure your team know how it works and communicate your progress in a familiar format there is not reason at all for this kind of project to be considered differently to any other.  This means managing the project and not expecting it to manage itself.

Tweet This Post