Is your Organisation Ready for Agile?
“Agile” software development has been around for several decades and there are a number of well-known agile methods, some of which you may already be familiar with such as DevOps, Scrum, Kanban, Lean and XP. DSDM Agile Project Management and more recently Prince2 Agile have been developed specifically to wrap around essential project management disciplines, such as the creation of the business justification and risk and issues management.
The diagram below illustrates how Prince 2, DSDM Agile and MSP support each other.
As I completed an agile project management course a colleague made the following comment:
“While agile project delivery is good in theory we can’t see it working here as our organisation isn’t agile; our current project governance arrangements do not support quick decision making, the business wants to specify all its requirements in detail, up-front (although it often can’t articulate what it wants at the beginning of the project), managers are not comfortable with empowering their staff to make decisions and the business hasn’t got time to provide input into the iterative development and deployment cycle, required by an agile delivery approach. ”
These were some of the challenges raised by my colleague about their organisation, however many organisations will be faced with these and other challenges when adopting agile methods; the business has to be resourced so that it can continue running its current systems and processes whilst simultaneously supporting ongoing, iterative development and deployment of new and evolving solutions. Additionally, when the project closes how do you ensure that the solution, transferred into Business as Usual (BAU), is designed, developed and documented in such a way that it is maintainable and supportable?
In my experience, a certain level of “organisational readiness” is required to ensure successful agile delivery. It is important that there is a consistent view of the project so that everyone involved works in an agile way, not just the IT part of the project. Below are few of the fundamental building blocks which need to be put in place to negotiate the above challenges.
Can the traditional Governance models be used?
Agile delivery requires agile governance. I have worked with Projects Boards which met monthly or even quarterly while the project was delivering a new release of the solution every 2-3 weeks and key decisions therefore had to be made outside of the board meetings. Strong governance is required for successful agile delivery as the project will be dealing with continuous change and uncertainty as requirements and technical constraints and opportunities emerge; however the governance structure needs to support quick decision making. Careful thought is required to ensure sufficient governance exists whilst ensuring rapid decision making. Some organisations have delegated governance to the service owner how this presents other difficulties as this approach can result in wasteful scope inclusions and failure to deliver alternative stakeholder and customer requirements.
How do you manage evolving requirements?
Agile delivery is predicated on the idea that detailed requirements cannot be defined at the beginning of the project and will change and evolve as users see initial releases of the solution and as technical constraints emerge. If you commit to a fixed price, scope and duration for a project, there is effectively no room for agile.If you work in an organisational culture where the business wants fixed price, scope and duration or the requirements are fixed but the price and/or duration are flexible then project delivery may be better achieved using traditional waterfall delivery methods.
The benefits of collaborative and iterative development, through co-working of business representatives and developers are clearly articulated elsewhere. However it is crucial that senior business representatives take active “ownership” of the high level capabilities required and that these are prioritised to enable delivery of benefits to meet the business drivers. I have found that the MoSCoW prioritisation tool is easily understood by stakeholders and have used it many times to agree the Prioritised Requirements List or Minimum Viable Subset (PRL/MVS) of requirements.
What is the role of a Project Manager in a self-directing team?
The application of agile methods can be a challenging experience for any experienced project manager! Project Managers using traditional waterfall methods will be used to creating and managing a detailed plan with clearly defined deliverables and milestones and minimising changes to the requirements, agreed at the beginning to the project, to ensure delivery of the requirements within a set timescale and budget. Agile projects cannot be constrained by detailed plans, with all the requirements specified up front. The role of the agile Project Manager is to support the solution development team by setting the overall direction for the delivery of agreed capabilities, managing associated risks and resolving issues as they arise so that the development team can continue working productively.
I would recommend, as a minimum agile project managers should understand the fundamental principles of agile delivery and even better wear the scars from managing an agile project.
How do you ensure the project hands over a maintainable and supportable solution?
The Agile manifesto places an emphasis on working software over comprehensive documentation. Whenever there is squeeze on project time, documentation is usually the first casualty. This may produce working software at the time but it may also significantly increase the full life cost of the solution. Those maintaining and supporting the solution, whether it be your support team, the client’s IT team, or a third party will need to spend time understanding the new solution before the solution transitions into BAU.
The role of the Business Analyst on an agile project will differ from a traditional waterfall project. In my experience while it’s essential to include business representatives within the Solution Development Team, it’s a mistake to assume that they have the necessary skills to elicit and articulate the detailed requirements and document what is delivered when the solution handed over to BAU. You might consider using an experienced BA to work with the team to ensure that the solution is documented to a level where it is clear what functionality was finally delivered.
Agile methods are not a panacea and organisations need understand, at the outset whether an agile method is suitable for delivery of their projects. DSDM Agile Project Management has a useful Project Approach Questionnaire which you can use to assess your organisation’s “readiness” to undertake an Agile project and can provide insight into interventions to ensure that the organisation is prepared for agile delivery.