Agile Cards: a Fun and Flexible Way to Industrialise and Standardise, 1/3

This is part one of a three-part article. The next instalment will come on March 31.

Imagine Luxembourg airport at 6 a.m. on a frigid Thursday, in a pre-pandemic January, full of solemn-looking, suited-up guys. As Scrum Masters at Pictet Technologies, we were well used to getting up at this ungodly hour. Working at the scrappy new company whose mission was to turbocharge the Pictet Group’s software development, visiting our mothership in Geneva was part of the deal.

This time, the meeting ahead did not sound like a lot of fun, though: we were going to meet our sister group of Lean and Agile Coaches to decide which Core Agile Practices to standardise on. As a practicing Agilist, dear reader, you will easily detect the tension, and indeed, the paradox of what we were trying to do: shouldn’t Agile obviate the discussion of concepts such as processes and standardisation? Shouldn’t we respond to change rather than implement a rigid set of practices? And yet, we felt an urgent need to converge on something. Our mission was not just to transform an IT organisation of several hundred to work in an Agile manner. It was to take responsibility for the effects of this transformation, to consolidate and drive performance of each of our teams separately, and of the resulting “one-team” effect for which Pictet is famous. Each of the people we worked with was an accomplished professional in their field. How could we help them get there? How did we even know what ‘there’ meant?

The Call to a Standard

To get our Agile teams off the ground, we had done all the obvious things first. We gave everyone an Agile Core training. We hired the Scrum Masters and Agile Coaches. Each of them brought his or her distinct personality and years of experience, which was a great strength. They started working with their assigned teams, but then something unexpected happened: our customers and collaborators were getting increasingly confused about what exactly they should be doing: they were getting different answers depending on whom they asked. While having a rigid process, enforced by tools and bureaucracy was the last thing on our mind, we started to suspect that there would be benefits in standardising on a core set of practices. If we wanted to know whether whatever we were doing worked, it would be hard to tell by performing a slightly different “n=1” experiment with each person and team.

Having a shared set of mandatory practices was important: that was a belief shared at the Group level, not just our own Agilist faith. It would enable us to know which parts of the organisation were more advanced in their transformation, and which required more help. Team members would be able to change teams without completely re-learning the way they worked. And as Scrum Masters and Agile Coaches, we wanted to be able to set our own roadmap.

So many goals! We came to the realisation that only a common set of practices could solve them all. We had to practice what we preached: we had to self-organise, so we got on a plane, and we got together.

The False Dawn

If you expected drama, shouting and fists banged on the table while we advocated for conflicting positions, you’re in for a disappointment. The meeting finished amicably, and we flew back home with a set of 11 practices we wanted to roll out, organisation-wide, in the coming year. The anti-climax came later: as it turned out, the devil was in the details. In the workshops and discussions that followed, we couldn’t agree ourselves on what it was exactly that each practice meant. Story splitting is a great idea, for example, but should we instruct our Product Owners to split the stories into sub-tasks, or to create small enough stories instead? Is “given-when-then” a valid format for a user story, or is it more suited for a test? If you code in a pair-programming session, do you still need a code review later? While we forged the compromises, the documentation and descriptions of the practices grew, full of nuances and exceptions… until it dawned on us: nobody was going to read this wall of text. It was the dreaded comprehensive documentation.

The Drive

We needed a way to get the practices across to people in a way that would be both comprehensible and fun.

Oh, and did we mention that we had another important goal in mind as the junior spin-off firm of Pictet Technologies? It was to establish our reputation. The Pictet Group is a storied brand, and it’s not easy to leave a mark on a firm established in 1805, a Rolls-Royce among private banks. Advertising ourselves to experts and engineers as experienced Agilists, we couldn’t just settle on an old boring set of Wiki pages saying, “you have to do that” and hope to change anyone’s behaviour. Working with teams full of rock stars, we needed to be what the famed rock producer George Martin was to the Beatles, and not the accountant nagging them about taxes.

Could we impress rather than oppress? Our company’s mission, our raison d’être was to innovate. Could we innovate our own way out of this?

We considered the various metro maps of Agile practices, produced by Agile Alliance, Deloitte, and just about anybody else wanting to stake a claim to leadership in the Agile world. Nice to look at, and perhaps interesting at the meta-level; but there were so many versions already that producing another one just for Pictet would just add to the noise. They gave the impression of complexity, too, which is precisely the opposite of what we wanted. If we struggled to understand them ourselves, as experienced Agilists, was that really a good way to guide our teams through the maze? Lastly, let’s not forget the famous remark by Korzybski, “the map is not the territory”. Knowing what to do first is not the same as knowing how to actually do it.

… to be continued in part two, check back on March 31st!