If your digital project is late and its users are unhappy, it’s not agile. Well, it could be tagged as agile by some (it’s got sprints, t-shirt sizing & stand-ups) but this is really rather pointless box ticking. Today, resources need to be consumed purposefully and efficiently, and the drive for digital needs assured, “good enough” delivery.
I’m not suggesting that we throw out the agile baby with the tar-pit bath water here, most definitely not. What I am saying is that we must shape our projects so that they deliver to order and, for digital, this covers faster. Agile development is a valuable part of this faster, better delivery but there are some essential architectural underpinnings if we want success; fast, efficient, on time and on the money.
We (those tasked with facilitating change) need to understand what the enterprise wants to achieve and how. More customers, more sales, more revenue per customer… they’re all good, we just need to know. If there’s no documented strategy, objectives and KPIs can probably be found in the annual report but the “how” (critical success factors) may well not be expressed. If you can engage chiefs or senior managers and find out how they want to achieve their objectives (I want to drive up customer numbers on the freebie service and then convert them to premium) this is great for building valuable relationships and strengthening buy-in. I can imagine some of my agile colleagues developing hives at the thought of all the time wasted on this documentation but they’re wrong. No engagement, no buy-in, no delivery; it’s that simple. There’s a positive side to this too. The resulting motivation model can be used to define scope (it doesn’t deliver a CSF or KPI so drop it) and priority (without this, that KPI can’t be measured so it’s a “Should”) so we’re lean. It also helps to minimise change (we could change the user stories but it won’t improve support for that CSF) so we’re lean.
I’ve written before about the value of business object modelling (Things) to quality but it’s also great for speed & agility. Things are easy to understand so they’re quick to attract buy-in. Once we’ve defined them, we just need to build them. The actions defined for each Thing are first-cut functions, the characteristics are first cut screens. A lot of time is typically wasted during iterative projects trying to nail these two sets of decisions and the result is often lots of screens/forms/pages that are variations on a theme, hence more work to do and a more complicated and more confusing user experience. Definitely not lean.
The next tool in my cargo pants is a Capability model. I’m a bit of a latecomer to this one but I’m finding these models really useful and tight. We’re developing generic and sector capability models so we can provide a start for ten here. Capabilities are easy to document, the technique is model driven (and uncomplicated) and they’re readily consumable. Although process models are important downstream, the semantics and notations (even simplified BPMN) are an unnecessary complication at pre-project stage. Capabilities are excellent for getting to a shared view of operations and models can be heat-mapped to give different perspectives. Change is easily reflected and progress is rapid; so we’re agile.
The final tool in my small pocket is the Roadmap. It’s great being bold and running off down a path but you can spend an awful lot of time running round in circles if you don’t know where you’re going. Wasteful, not lean. Many of you will have been on a project with a big elephant called Technical Debt slumbering in the corner. You’ve made progress, there’s a beta to launch and everyone’s happy. Who cares that it will fall over frequently and cost a fortune to strengthen. It’s a beta, right? I get the need for speed and agree there’s a need to hold back costs until we know there’s demand. Roadmaps just mean that informed decisions can be made and the majority of technical debt avoided; so we’re lean.
Like “fail fast” and “good enough”, “slow start, fast finish” feels a little uncomfortable to begin with but it’s the right way to go. So keep your user stories, burn-down charts and scrums; just add in motivation, things, capability and road-mapping if you really want to go digital.