Financial services “scrums”—fail early, fail fast
Nov 4th, 2015 | By FCT
In our EXPERT/ease special feature this month, we’re taking a deep dive into the world of persuasion and failure and the completely improbable relationship between the two.
Failure isn’t something most people want in their working lives, but in one of the fastest growing industries (and most influential) on the planet, software design, increasingly there’s way of working call “agile”—and software is all about “iterating”: testing, failing and testing again.
What this means is that you and your team are fundamental: live as openly about the work you share as you humanly can be. Plus the whole focus of this way of working is not to be sequential or traditionally “linear” about how you’re solving problems.
Scary? Nope: you’ve done this already, especially if you’re a parent or you’ve taught anybody anything. You go with what you’re presented with, rather than imposing an external pattern: you self-organize.
Agile teams self-organize and respond fast because—as in life itself—software product requirements often change in the course of the project. Customers’ plans change, market conditions demand a new feature—what software developers dryly term “requirements churn.” The design itself, no matter how well thought out, is a moving target.
Sounds a bit like mortgage process flow, doesn’t it?
Highly specialized financial services team often work this way, especially in product development, where production cycles are growing shorter and planning itself is now often far more collaborative than top down. Everybody on agile teams watches everybody else’s back. Workloads are monitored to ensure that errors are identified pronto.
A rule of thumb worth bearing in mind is that no team member should have more than two simultaneous selected tasks, and that, on the other hand, not all team members should have two tasks simultaneously.
That co-operation focuses on business value versus development resources daily, because agile companies meet (usually standing up, to keep meetings focused and tight) at the top and end of every day, to monitor progress. At the heart of this way of working is the “scrum,” where the team, working as closely together in the same space as possible, literally goes nose-to-nose on a problem until it’s solved—and failure is a given.
No failure, no product improvement.
Scrum is a process that enables teams to achieve a level of continuous improvement. It revolves around operating in short cycles called “sprints” with built-in opportunities for teams to prioritize their workloads, hone in on and attack the few things that truly matter, identify what worked well and what could help them perform better, then rinse and repeat.
The nose-to-nose part’s important—”agile” doesn’t work for virtual companies in remote locations, apparently—but the life lesson for those of us who’ll never get anywhere near a software development scrum is this: if you want to get to good fast, fail fast.
This openness to fail-and-change workflow—the essence of the improvisation so essential to innovation—makes for far higher likelihood of desirable outcomes, patterns of swift fault discovery and fixing of faults. In fact, these patterns give agile scrum team members very short cycles to identify and repair poor initial outcomes. The more you fail, the faster you learn; the patterns of failure/discovery/learning/redesign are key to the business value of the software company.
It’s definitely worth a read. The Deloitte PDF shares a subtle point: scrum/agile plays well with orthodox oversight, such as requirements gathering, conceptual design, budget and critical path/schedule forecasting.
If you’ve a new financial services product with a tight deadline and lots of potential for variations, there’s a lot to recommend scrum.