IV. Agile Delivery, Robust Governance.

In 2001, the original Manifesto for Agile Software Development articulated a developer position against top-down software management.

The tenets of that manifesto are hard to argue with, and are also refreshingly simple. It boils down to getting software working as quickly as possible, working with the client as part of the team, and responding to change, rather than attempting to plan everything up-front, handing over, and waiting for it to go horribly wrong.

Fast forward to 2017 however, and ‘agile’ has increasingly become something that management want to impose on developers. It’s also acquired plenty of baggage along the way.

Like the pigs in Orwell’s Animal Farm, Scrum devotees begin to resemble the methodology-obsessed project management disciples that the original agile manifesto reacted against.

Scrum, a specific project management methodology, has become almost synonymous with the word Agile. As is typical with developer-driven cultures, it has picked up all manner of protocols, tactics and jargon, like a snowball rolling downhill. When Scrum doesn’t deliver on all of its presumed benefits, the usual reasoning is that you are not doing it right; Unless you have wholeheartedly embraced every element of Scrum, then you are doing ‘fake agile’ and your project is doomed to fail. It’s worth contrasting that view with the original Agile Manifesto. Like the pigs in Orwell’s Animal Farm, Scrum devotees begin to resemble the methodology-obsessed project management disciples that the original agile manifesto reacted against.

None of which is to say that Agile, or indeed Scrum are bad things. Getting working code at the earliest opportunity; demoing and iterating within regular, time-boxed cycles; incorporating the client into the team and using a feature backlog to manage change, these are all principles we follow at Made Media. But really, we’re talking about the software development cycle here. There are elements of website and app design, that are not strictly-speaking software development. Scrum doesn’t really have much place for design at the macro level. So we combine agile development processes with overall project pragmatism, doing just enough up-front design to avoid going down unproductive rabbit holes, and not delegating QA entirely to unit tests that see quality strictly through a lens of code.

This typically manifests itself when the project manager’s role evolves into asking the production team what’s happening, and updating their gantt chart to better reflect reality. The reality tail wagging the fictional dog.

Agile is usually contrasted with the Waterfall technique, where all tasks are pre-plotted on a giant gantt chart, which increasingly resembles a work of fiction as the real work gets underway. This typically manifests itself when the project manager’s role evolves into asking the production team what’s happening, and updating their gantt chart to better reflect reality. The reality tail wagging the fictional dog.

So yes, waterfall has its problems. But often, when pointing the finger at a methodology like PRINCE2, or certifications like PMP, agile proponents misconstrue the true purpose of those methodologies. PRINCE2, for example, actually has very little to say about project delivery. Its origins are in government procurement, where the delivery is most-likely done by an outsource partner (like us!) and is considered the outsource partner’s business. The true purpose of PRINCE2 is not to deliver the project, but to deliver enough C.Y.A. documentation to prove that it’s not the PM’s fault when the budget doubles, and the product is still nowhere to be seen.

Which is not to say that PRINCE2 is in itself bad. Its purpose is to try and control project governance, not project delivery. To ensure that a project is commissioned with a business case. To provide guidelines as to when people should raise the alarm that all is not going to plan. To anticipate and log risks. These checks and balances are important when you’re answerable to your budgets. It’s about the big picture success of the project.

Web projects are a risky business. Scope is so hard to define in words, that you’re never really sure what you’re getting, or even what you want, until you see it. It’s one of the reasons we prefer wireframes to requirements lists. But no-one’s going to give you a blank check for your web project, and you’re going to have to give your board, or your sponsor, some reassurances about what you’re getting for their money. So unavoidably, there’s going to need to be material commitment to features, budgets and deadlines up-front. This is something that developer-driven methodologies tend to duck. Guess why? Because developers are comfortable writing code, not making business promises.

At Made Media we’re conscious that project budgets have often taken years to win, and have been assigned with definite expectations about outcomes. Agile development methodologies cannot excuse us from our commitment to deliver on those expectations. Working to fixed budgets, we have to temper Scrum with some commercial realities. We estimate in hours, not pseudo-abstractions like story points. Even if sometimes that harshes a developer’s vibe.

So at Made Media, we use a methodology that borrows a lot from Scrum, and a bit from DSDM and Kanban. Clients are welcome to join the sprint planning meetings, or even daily stand-ups if they wish. But a weekly call and demo is the baseline. In relation to project commissioning, governance, reporting and accountability we run more along PRINCE2 lines. And there’s no contradiction in that.

Required Reading

• Peopleware Demarco and Lister demonstrate that the major issues of software development are human, not technical. 
• The Mythical Man-Month insight for anyone managing complex projects.
• Agile Manifesto uncovering better ways of developing
  software by doing it and helping others do it.
• Scrum an iterative and incremental agile software development framework for managing product development.
• DSDM Dynamic systems development method.
• Kanban a scheduling system for lean manufacturing.
• A criticism of Scrum illustrated with top-notch memes.

Next month: Innovation with a purpose