Agile software development has been part of my life for a long time. You could say that has become a way of life for me, a practical approach to the management of the delivery of objectives, paralleled by the way I now go about things in general.

Early on, my teams and I dabbled in agile. We told ourselves that our propensity to change our minds frequently amounted to agility. I compared this to my traditional project management training, with its formality and comparative rigidity, and I almost had myself fooled. What I found though, was that without a commitment to the disciplines of one framework or another, I no longer managed projects. The teams I was involved with would merely work from a prioritised list, in which emergent work frequently took priority without debate or proper scrutiny.

Software development is complex. Unscripted. Certainly not capable of being accurately prescribed in terms of hourly activities. So, which framework?

For me, Scrum fits perfectly. It provides an easily understood set of boundaries that provide intelligent professionals the space they need to succeed. The ball’s in their court. Control and responsibility are all with the right people.

All stakeholders in the software development process have different “perfect worlds”. I like Scrum because it makes the appropriate concessions and compromises from all perspectives, understanding that ultimately successful delivery of useful software is in the best interests of everybody. The discipline is hard. Sticking to the agreements we all make to one another when we decide to use Scrum is hard. Time and again though, I’ve found that the closer I manage to stay true to it’s principles, the more Scrum gives me a greater chance of succeeding.

Developers hate costly processes that force them to record their every move. Quite right. At the same time, a business demands a certain level of transparency and the metering of progress. The daily stand-up and the visibility of the card wall provide this, allowing the team to devise the lightest weight documentation of its activities possible.

The product owner and customer have the control over the delivery of features in priority order. An organised PO will be able to throttle and manage the incremental delivery of usability for the customer, in a way that excites them and brings a minimum marketable specification to life at the earliest possible moment. They’ll also have a commitment to that MMS, and a very clear vision of what it entails (and no more!).

Lastly, the project manager …

Yes, the project manager! Scrum doesn’t include them, scrum doesn’t need them. So where did they go?

Just because we use an agile framework like scrum, doesn’t mean we have no projects! In project driven businesses, there is a need for somebody monitor the program, working with product teams and product owners to help the business believe in the roadmap, identifying milestones and deliverables along the way. The iteration can replace the Gantt chart, with the wonderful benefit of being fluid, right up until the moment it starts. Agility does not eliminate the basic business requirement of planning ahead, it just permits the business to change direction more quickly, if it decides to. Agility does not do away with considered direction setting.

Project managers can help with the long-term planning of software deliverables, using the iteration as checkpoints along the way. Even roughing epics into iterations is of great benefit in understanding delivery capability. There’s also a big need to integrate and co-ordinate development with other business areas, all pushing for a common goal.

If we absolutely need version 1 ready by September, let’s take some time, not too much, and sketch in the outline of what the months leading up to September look like. What large bites of functionality will need to be delivered, and when, if we even think we can make it? It’s not set in stone, but it can help bring an early dose of reality, especially if your product owner is in the right place – “creative ecstasy”!

For project tracking, I like the charting techniques of Alistair Cockburn, as they show not only the development activity, but also expose scope creep.

Now I know that strictly a product owner can, and should do this as a matter of course. Things will change based on feedback and emergent priorities, but the business deserves to know what the roadmap looks like, and whether it will deliver products when they are needed. How does this fit with Sales? Support? Marketing? To this end, a good project manager, especially when there are many teams working across a product or component suite, is an important part of the mix.

By blending the exciting and evolutionary aspects of agile, with the right amount of structured traditional business disciplines, agile software businesses give themselves the best chance of delivering the right software, right on time.