A lot gets debated around the pros and cons of agile, regarding when it's the right way of delivering a software project, and how to procure and price agile contracts. These are all important considerations, but because agile is significantly different from waterfall development, organisations also need to consider upfront how things will operate on a more granular, day-to-day basis.
Areas such as governance, team makeup, gaining ongoing feedback and scaling the project all need to be given due thought before the project starts.
- Also check out the best project management tools
Management and governance
A common misconception about agile is that it is less controlled because it is less formal. Indeed, 'textbook' agile does leave something of a gap where governance is concerned, which many have struggled to fill. However, like any kind of project, agile ones need to be governed if they're to be successful – it's how this is done that's different.
The key areas where governance needs to be established are communication and roles and responsibilities. Appropriate structures need to be put in place and understood across both the procuring organisation and its development partner before the project gets underway.
The importance of this should not be underestimated, because unlike waterfall projects, agile ones reach right across the procuring organisation from the start, and if someone doesn't understand and appreciate their role, or deliver what's expected, this can quickly derail the entire project.
While governance is vital, there's a fine line between too little and too much. Too little governance could see a project go out of control, but equally, too many layers of governance will strangle the project and stifle the very benefits that are wanted from agile.
This is why it's so important for the procuring organisation to provide an active and empowered individual in the Product Owner role, who can make the big decisions when required, and also carefully control which features (user stories) are considered for a given iteration.
In Scrum projects, each sprint has a defined scope, and everyone needs to understand what it is and that it must remain tightly defined. The danger with adding or removing user stories partway through a sprint is that it alters the scope, meaning the sprint may not deliver the required working software at its conclusion.
Team composition
Whereas traditional waterfall delivery teams are typically made up of a group of specialists who each carry out a designated role (such as designers, coders and testers), successful agile teams are composed of multi-skilled individuals, each of whom is able to carry out numerous roles. This gives the agile team the greatest level of control and flexibility over what can be delivered in a given iteration.
Also useful – though not essential – is that the team members know each other and have worked together before. Understanding each other's skills and how individuals work together is an enormous help when it comes to sprint planning, because the team will be able to provide more accurate estimates of how much effort a given feature will require, and how long things are likely to take.
Feedback
If an agile project is to deliver results that truly meet the underlying needs of the organisation, then ongoing, high-quality feedback to the development team is essential. This can be delivered via the review at the tail end of each iteration, but also at other times as required. Getting timely feedback from stakeholders should be part of the Product Owner's responsibilities.
The retrospective at the end of each iteration is another important feedback mechanism for the delivery team, enabling all those involved to provide suggestions on what could be changed to enable future iterations to be more effective.
Scaling agile
Agile has matured significantly over the past decade and proven itself to be a credible development methodology. However, much of its use has been on relatively small (albeit sometimes high-profile) projects. That isn't to say it can't scale to be effective in larger projects and programmes, where multiple agile teams deliver different elements.
To facilitate this, an organisation will need additional governance to coordinate the relationship between the different teams and ensure the work each one is doing will integrate correctly with all the other pieces of the jigsaw.
Conclusion
Agile projects are different from waterfall ones, and need to be run differently, from how they are governed and managed to the makeup of the delivery team. Getting these things right from the get-go is critical, and they require a deep understanding of agile from both the delivery team and the organisation that's procuring the work.
By having a full understanding of their roles and responsibilities, each side is more likely to deliver what's required, which gives the project the greatest possible chance of success.
Owen Philpott, Agile Consultant at IPL
