The 1980’s TV show The A-team was brilliant. Four ex-commandos with special skills who help the oppressed. Throw in some over-the-top violence where no-one gets hurt, together with some tech wizardry where the team magically create weapons out of old spare parts. Add a catchy theme tune – and voila – classic viewing.
In many ways agile software development teams want the autonomy portrayed by the A-team. And why not? Let’s bring together small teams of bad-ass code junkies. Provide them with enough open source software to build, integrate and deploy virtually anything. While we’re at it, give them the power to smash all the evil villains’ conspiring to prevent the rapid release of software for the oppressed business – like out-of-touch operations, process-crazy service management, or security and compliance police.
So on the face of it our A-Team looks like an IT winner. They save the day and no-one gets injured, right? Well not exactly.
When Agile Autonomy meets an Immovable Object
Autonomy is both a blessing and a curse. On the one hand, letting teams self-organize and self-manage without outside interference seems like a productivity no-brainer. However, when team autonomy descends into selfish technology-centric rants over rational program level thinking, all hell can break loose. Suddenly every team has access to a plethora of super open source tools — need a document style database for your new Python coded microservice? No problem, click here to download, quickly brush up by reading some appdeveloper articles, and hey presto you’re off and running. Rinse and repeat for different programming languages, build tools, code versioning, configuration management and your teams are all swimming in a fast river of technical goodness where considerations about resilience, performance and security can be easily lost.
The only problem is that the river flows down to where it eventually meets guess who – all those out-of-touch operations folks, process crazies, and security guards. Not surprisingly, they view this last minute technical deluge with a more cautionary eye. And since they’re compensated and rewarded on preventing problems, security issues and compliance exposures, they’re not going let any software pass freely into production – well, not without a fight anyway.
And herein lies the problem with the autonomous A-Team. The “A” suddenly becomes more associated with adversarial engagement than anything remotely agile. So cue delays and the business being ticked off yet again with IT.
Lessons from the Art World – Rembrandt and Stradivarius
DevOps with its focus on team collaboration aims to channel the healthy tension existing between Dev and Ops into business goodness. This starts by understanding how and where to engage all that natural team angst.
There’s a classic old sketch from the late British comedian, Tommy Cooper — who walks on stage with a painting and violin, proclaiming – “I bought a Rembrandt and a Stradivarius – the only problem is Rembrandt made lousy violins and Stradivarius couldn’t paint”. He then smashes the violin into the painting – hilarious.
In development we have our own Stradivarius’ who write great code, but have little appreciation on what makes a “complete” system. They can add all functional bells and whistles, but when it comes to compliance, resilience and supportability, forget it – they’re like the maestro violin maker with a paintbrush – pretty crap. Worse still, the only time they get to learn is when they’re forced to slug it out during a gated security review or regulatory compliance session – this usually doesn’t end well.
These issues may be resolved when development, operations and other stakeholders engage much earlier in the software development lifecycle. Here as requirements are established and code begins to take shape, stakeholders can work with development; guiding them on what’s needed for the software to become more secure, perform optimally and be a breeze to support. For starters, this has to include IT Operations sharing years of expertise – like how to exploit monitoring tools in pre-production to equip developers with an early warning system on performance issues as they code, or explaining what’s needed to support new distributed architectures at scale.
Engage Early and Broadly for Success at Scale
Beyond operations, there are many other IT and non-IT stakeholders who should be drafted into the A-Team.
When working on a new web to back-end system integration for example, security could advise development on end-to-end transaction tracing and static-code analysis techniques to help detect code or SQL vulnerabilities. In an API project, threat teams should engage early to model and mitigate against many new attack vectors that hackers can exploit, providing advice on strong, API-specific infrastructure and management. Naturally, if your team is doing anything with mobile payments you better hunker down early with the security and PCI compliance team – or if the agile team has devised some neat sensor, software and cloud technologies to capture and analyze customer-centric data ala the Internet of Things, then early involvement with the legal department on privacy gotchas is a must.
Large scale success from agile teams can be realized when those teams become less feral about their own individual needs and more focused on supporting business objectives at a program level. To this end, and whatever the makeup of individual teams, it’s vital to establish DevOps style collaboration early in the lifecycle; engaging all business and IT stakeholders in order to establish resilience, quality, security and even supportability into the fabric of software as its developed.
Do this and you’ll deliver great software without ever having to compromise speed. Fail, and your agile efforts may just stutter and fail – of course you’ll still have an A-Team, but the “A” now stands for something far less complementary!