Back in December, Iain Levein, Managing Director at Merkle|Comet, wrote a blog post about Agile, starting with the fundamental question: “What is Agile?” This naturally transitioned into “why” Merkle|Comet chooses to work in an Agile way and how it allows closer and more continuous contact with our clients. In this article I’d like to focus on Agile project delivery, building on Iain’s “why Agile” by exploring the “how to be Agile” before going a bit further and looking at the potential pitfalls which trip up organisations, and how best to avoid them.
Firstly, let’s agree on one thing; Agile BAU (Business as Usual) should be considered a different working environment to an Agile project. A project has a clear start and an end point (usually defined by products) while BAU is the point at which the project team are no longer required for operational use. I can relate to this myself, and maybe you can too - I have every interest in creating a self-service platform on which BAU activity can be performed, whilst recognising that I am less enthusiastic to maintain and use the platform on a day-to-day basis. This leads me to the first observation of Agile project delivery: understand early on who should be in the project team verses who you will depend on to operate the platform. Getting a balance between the two is key in ensuring that the users of any platform were contributors to the project delivery, whilst those who drove the platform implementation can roll off. In order for an Agile implementation to be a success, we must have a mix of suppliers and users (customers) engaged throughout the project.
Secondly, we have an agreed planning horizon. It is a myth that an Agile project does not require planning. Agile projects require a similar planning horizon to that of the Waterfall methodology, with the key differentiator being that we will not plan any tasks in detail beyond, for example, 3 months - the rationale being to prevent the use of time and resource planning for activities which will not reflect reality when we come across all the product design and functionality changes. Each project should be following a product roadmap – a sequence of deliverables completed in a specific order to deliver optimal value to the business. This is positioned well by Atlassian, the enterprise software company which has given us JIRA – “The key to long-term agile planning is keeping your project details and task estimates in sync with your roadmap.” In terms of what this might look like for your organisation we first agree what we will deliver in each three-month window, at high level, and have planning sessions every three months which more accurately define the deliverables of the next product milestone.
Having covered people and planning, we can now understand how we will organise ourselves. An Agile project team will not be objective and product-driven without the time pressures and clear visibility of pre-arranged sprint meetings with a repetitive cadence. Sprint planning, daily stand-ups, end of sprint demos and retrospectives on set days throughout the working week over the course of your sprint is key both in setting expectations and also for the team being able to manage their time effectively. This in turn will maintain box product development time without interruption and assist with accurate product sizing (effort estimating).
And now to come to the contentious point of this article, which differs from the views of Prince2 Agile project management. I think flexing scope within a timeboxed sprint/milestone can still deliver value, however, flexing scope can very quickly become detrimental to the quality of the system. For example, to deliver value to the business, it might be rational to cut a corner on the solution design in the short term which requires a manual workaround in order for this Alpha system to produce something useful. Great, we’ve delivered the value, but now the project sponsors are asking for the next bit of value and not the product as per the architectural design. In this instance, if the backlog is not managed effectively and prioritised accordingly we will no longer be producing to the architectural design and our manual workaround will be here to stay. This will have negative repercussions on subsequent sprints and be distracting for the team as we are no longer delivering value in the leanest way, i.e. by automating processes to assist with transition into BAU. Combatting this can be summarised simply; where scope is flexed to deliver value in the current sprint, the value should be flexed in the following sprint in order to keep in line with the architectural design.
There are many other observations and recommendations that I have around Agile project delivery and maybe you have some of your own. If you would like to understand what an Agile project delivery might look like for your organisation, please do not hesitate to get in touch.
Project Manager at Merkle|Comet
Andrew is a Consultant within the Strategy and Insights practice at Comet. Inspired by an ambition to make operational activities slick by working smarter, he has been delivering new touchpoint capabilities at pace. Andrew arrived at Comet with a First Class Honours Degree in Logistics and a further 3 years of experience within Oil and Gas where he proactively managed global suppliers; driving streamlined internal and external operations through the promotion of intelligent use of Material Resource Planning systems. Now he’s taking on both consultative and project management roles within clients to compliment their marketing objectives.