Too big for Agile? Is there a middle ground? (AgilePM 1)
Having recently lectured MSc students on project management, I’ve been pondering the issue of being too big for Agile.
Like everything that comes into fashion, there is an inevitable backlash once the hype passes. What Gartner would call the “Trough of Disillusionment“.
As I work with Data & Analytics teams who are seeking to embed Agile working, it’s clear one size does not fit all. Many business leaders have been trained in Scrum, Kanban or Design Sprints. But they can also face large or complex projects that struggle with this approach.
Perhaps this is especially true in highly regulated markets, like Financial Services. After all the Agile Manifesto values working software over documentation & responding to change over following a plan. That can make it difficult to provide the audit trail a regulator may require.
The limitations of Agile Light methodologies
First, let me state clearly that I believe there is a lot to commend agile ways of working. From the visual accountability of Kanban boards to the faster pace and collaboration of Scrum Daily Standups. All such methods can inject some much-needed flexibility & urgency into tired businesses with too much bureaucracy.
But these are too often taught as all there is to Agile. As if running a Google Design Sprint’s style 1 week Hackathon is the answer to everything. Or for those being sold software, the belief that using Jira automatically causes clarity and a working pipeline of user stories.
Because many have been inspired by the success of Big Tech firms, it is perhaps not surprising that these methods have become so popular. However, it sometimes feels like leaders don’t know that these are at the ‘light’ end of the spectrum when it comes to Agile methodologies.
The risk of this is that any projects/changes viewed as too large/complex or critical for Scrum/Kanban/Sprints are assumed to need to follow traditional methods. All those with experience in managing Waterfall Method projects will know that is a recipe for slower & more documentation-heavy programmes.
If only there was a middle ground, eh?
Enter a third way? The AgilePM methodology
Despite the DSDM Consortium being represented at the ski lodge in Utah where the Agile Manifesto was originally created, they are less well known. Far more is communicated about the methods mentioned above & their famous adherents.
That is a shame, not just for software developers (including Data Scientists) but also for business leaders responsible for complex changes.
I say that because I view AgilePM as akin to a middle-ground of ‘third way‘ in the world of project management. Like Waterfall, it has sufficient structure, controls and time for planning to accommodate more complex needs. In its programme management form, it has also been designed to interface with wider Prince 2 style programme design (the read-across makes sense).
Like Scrum, Kanban and others, it is guided by Agile principles, including a focus on roles not processes, just enough design and iterative development.
So, to encourage it’s wider adoption (or at least consideration rather than full Waterfall method), let me share a short overview to whet your appetite to look into it further.
AgilePM the key elements
The AgilePM methodology has been developed by APMG International, on the foundation of the DSDM Agile Project Framework.
Akin to the high-level Gantt chart of phases used to explain the Waterfall model of project management, Agile PM has a visual summary. This is in the form of a Grecian temple with the following elements
The overarching roof is made up of alignment with the Agile Manifesto philosophy and 8 core principles. These help provide more detail on how delivery is protected whilst still valuing interaction & prototyping.
The 8 Principles are:
- Focus on the Business Need (the real & evolving priorities)
- Deliver on Time (timebox work, flex scope to always deliver)
- Collaborate (joint working of mixed roles & empowerment)
- Never compromise Quality (agree upfront, test early & ongoing)
- Build incrementally from Firm Foundations (enough design upfront, deliver building blocks, reassess after each increment)
- Develop iteratively (detail emerges later, feedback, embrace change)
- Communicate continuously & clearly (how you use new meetings)
- Demonstrate control (transparency, accountability & clear roles)
Thinking of the application of these to Data, Analytics & Insight leaders, I am struck how these accord with points made previously on this blog. Enda Ridge’s book, “Guerrilla Analytics” echos the need for greater collaboration, delivery and quality. Harry Powell’s solution to the Productivity Puzzle, stresses the need for a clear focus on changing priorities, timeboxing & communication.
The Grecian columns of this model then cover 4 elements that I will expand upon in the next posts in this series:
- Process – although there is less of this in AgilePM than traditional
- People – a much greater emphasis on roles & the people needed
- Products – the flexible but essential documents during delivery
- Practices – workshops, modelling and other tools that help
Finally the foundation matters as well. Following all elements of AgilePM slavishly for each project could be as onerous as Waterfall PM. So, many elements including Process & Products are recommended as a framework to be tailored. Pick & choose what serves you well for that project.
It is this customisation within a clear framework that accentuates the Agile nature of this methodology. But I hope to also show in the following posts how many elements of AgilePM will be familiar to those who have experienced Scrum, Kanban or Design Sprints.
What is your experience with Agile?
I hope this build upon my earlier posts (covering culture & tips for Agile Working) is helpful for Data, Analytics & Insight leaders.
What is your experience with Agile? Are you a Scrum Master with plenty to teach others, or a neophyte to all this flexible?
It would be especially interesting to know if the gap I perceive is seen by others. Do you lack a third-way, between the slow behemoths of traditional IT projects and Agile Lite methods that don’t work for larger/complex needs? If so, I’d like to hear from you.
In part 2, I will share more detail on those pillars & reflect on their application to Data, Analytics & Insight teams.