“I want to run an agile project”

Prologue
As the value of Agile practices becomes more understood, brave project managers are beginning to challenge the normal practices of the organisation and request the opportunity to take a more Agile approach.
In our animated movie “I want to run an agile project” (by Carson Holmes and I), we follow the experiences of one such brave project manager, Luke, and his many different encounters throughout the enterprise, as he works to establish and deliver his Agile project.
After watching his sadly-entertaining journey, in this article we explain what is really going on, and start to highlight the reasons behind his troubles, and how an organisation can work to overcome them.

Scene 1 – The Stakeholder
Establishing that there is a need for the business to invest in a project is just the start of working with the stakeholder. They may think they know what they need, they probably think they know what the solution looks like, but whatever they think they know, they have to work with the project team to make the project a success.
This is where so many projects come unstuck. They assume they can define and clearly communicate their needs to the project team via a document of their perceived notions of what the system shall do: “a bucket of shalls”! This rarely succeeds.
However establishing a Vision and a close working relationship with the stakeholder and their business users will allow the project to start quickly, collaborate with the stakeholders to identify critical needs, and work to quickly deliver a rapid return on investment for the business.
Without this collaboration, wants will quickly turn to assumptions, spec’s into speculations, and a high probability that any invested effort will not deliver what the stakeholder really needed.

Scene 2 – Procurement
Establishing a business need and having stakeholders willing to commit to the project is a good start, but this typically leads to the need to complete funding procedures, whether they be external procurement teams, on internal programme offices.
Those teams want to know what it is they are funding and what they will get for their money. Unfortunately, they typically operate to simplistic assumptions that the business knows the details of what they really need up-front, and that business needs will not change during the life of the project.
Changing their mindset to one of committing only small investments and observing ROI prior to investing further sounds easy. But, when organisations have never had prior opportunity for early ROI before, they expect every project to be protracted and deliver disappointing results late.
The procurement people need to be brave and ask some tough questions of the delivery projects: What if we have to cut funding half-way through the project? Can we look to establish early business revenue help fund the remainder of the project? Can we incrementally fund your project based upon demonstrated results?
Our Agile project manager would be happy to answer these questions.

Scene 3 – Governance and compliance
There are good reasons why organisations set up these governance and compliance teams. Industry regulatory compliance rules need to be adhered to and organisations have been “burnt” so many times by failing, typically waterfall, projects that safety nets were required to protect the business from rogue and dangerous delivery projects.
However, these governance rules can also prevent successful project practices from being used and enforce some of the practices that the governance rules are trying to avoid!
Incremental improvements in delivery success can be achieved by enforcing draconian measures on projects, but to make distinct step-changes in delivery success requires a more significant change: incremental and agile delivery.
Don’t get us wrong, there is nothing wrong with asking a project questions such as: “Can you prove you understand our needs?”, “Can you demonstrate you have a sound solution that will meet those needs?”, “Do you understand the risks involved, and can you demonstrate how you will overcome them?”, “Can you demonstrate that your solution meets the expectations of the stakeholders?”, etc.
However, most typically the governance team have asked for documentation to support the answers to these questions as opposed to concrete evidence that the team is actively delivering results.
Getting back to the objective of any “control point” will typically allow an agile team to establish what measures of valuable progress they are looking for, and provide better measures of real progress than the typical documentary evidence has ever provided.

Scene 4 – Enterprise Architecture
There is a lot of value that any project can gain from working with Enterprise Architecture (EA): understanding the strategic technologies of the organisation; establishing the non-functional and technical requirements of the project; aligning to the other systems of the enterprise; providing feedback on the technical vision of the project; to name just a few.
However, EA should not be looking to define the detail of the solution that the team needs to determine and deliver. They should be like the stakeholder; helping to define needs, validating business value, and collaborating regularly with the team.
In this way, they provide a valuable source of strategic technical governance and alignment to business strategy.
Delivering a big design up-front only leads to speculation and proof by documentation that a technical solution will work. It’s much better to demonstrate an executable architecture, and the EA teams will agree when they start to realise that it’s possible to work that way.

Scene 5 – Development team
Not everything on the project will be technically easy. Many of the things asked of the project team will be new to them. The developers will have different experiences, and the best way to overcome the challenges for the team will be to encourage them to collaborate.
Unfortunately many members of development teams have had careers where they have been encouraged to act as heroes. They have been measured by their individual performance and not by the success of their project team.
When the regular delivery of demonstrable success becomes important, the team needs to recognise this and whenever technical challenges arise, work collaboratively to find a solution. This will be both more efficient and help build a sense of team.
Pairing is one approach to achieving this, but it’s not required all the time, only when anyone on the team finds a challenge and asks for help. Then a member of the team will volunteer their help, for as long as the challenge still remains.

Scene 6 – Deployment
It’s no wonder that deployment teams view development teams with caution. So often they have been on the receiving end of executable solutions that have been rushed into deployment, poorly tested, and not designed to support a production environment effectively. However, if treated as another stakeholder of the project, their needs can easily be catered for, and their fears allayed.
They are also expected to protect the business, and when projects have rarely delivered to expectations, they are very wary of new solutions that are regularly delivered and expect regular deployment.
Engaging the deployment team regularly in the project, allowing them to see successful pre-deployment testing, and demonstrating a successful deployment plan, will help the team to gain the confidence to schedule the Agile team’s regular deployments.

Scene 7 – Stakeholder Acceptance
By the time the Agile project team is ready to deploy a solution that adds value to the business, there should be no surprises for the business about what it is going to get. Their continued involvement as members of the project team or through attending regular demonstrations, should provide them with ample opportunity to ensure that the project is delivering what they need, even if their need change, or they were unsure what they wanted until they saw it for the first time.
However, even in the worst-case scenario of the stakeholders only seeing the solution at thei first point where a basic solution could be deployed, they are still able to change the course of the project far earlier than would be possible in a more traditional lifecycle.

Epilogue
Our brave Project Manager, Luke, did manage to force his Agile project through the organisation, but whilst it was a tough journey, it was worth it. The customer did receive early value and Luke established precedents with many of the other organisational functions.
Over time he will find that the rest of the organisation starts to recognise the value of the Agile delivery approach and barriers will removed or refined to accommodate the delivery of early value.
However, this process will take time, and it will take more than just Luke’s endeavours to make that change.