Agile Cards: a Fun and Flexible Way to Industrialise and Standardise, 2/3
This is part two of a three-part article. The next instalment will come on April 14th.
The Inspiration
Remember how in Karate Kid, the young Daniel LaRusso was first told by Master Miyagi to wax the car and sand the wood, only to discover that he was in fact learning blocking movements? Shu-Ha-Ri is a way the Japanese think about learning martial arts: first you learn by memorization and rote repetition, without thinking too much about theory: just listen to your teacher (the Shu level). Later you get to know the theory and learn from how other practitioners do it (the Ha level), to widen your horizons. Finally, you analyse your own practice to tailor it to your needs and strengths (the Ri level). In terms of the Shu-Ha-Ri ladder of Agile competences, most of our constituency in the teams struggled to get on the Shu level. The Agile universe offers a wealth of literature, theories, polemics, and high-minded concepts. But what is Agile’s “wax-on, wax-off” instruction with which Master Miyagi built young Daniel’s muscle memory?
You want to tell rock star bankers and engineers to follow a blind, disciplined practice of the basics, you better make it fun. Looking for inspiration, we shuffled the documents for practices that we came up with before. When somebody printed them up 2x smaller to fit more on paper, then it hit us: each of these could be a card. And when you have many cards, you can make it a game! Even better, a game that you don’t have to play on a screen in a world already suffering from screen overload. What if we put into the hands of every member of our organisation a beautiful object, a deck of cards for a game that could be played with his or her teammates — and while playing, they would soak up the practices and ideas we wanted them to absorb?
With early cards, we tried out some rather high-level concepts such as “Test-First Development” or “Configuration Management” only to run into the same wall: there were too many possible interpretations. How to determine whether a team is doing “Micro-increments” properly? What does “Courage” even mean? The next critical insight was that we needed to focus on the behaviours rather than principles. Who cares what our principles are, if we don’t exhibit them, day in and day out, in specific actions on the ground? Thus, the basic design of the card was born: the practice or principle’s name stated on the front, whereas on the back we put the specifics, the details, signs, and evidence on how exactly to tell if the practice is working or not. (Incidentally, it’s also reminiscent of the classic 3x5 card design for a user story.)
It was quite a fun and stimulating exercise for everyone involved to determine these basic behavioural building blocks of our principles. We had to accommodate development and support teams, teams running Kanban, Scrum, and everything in between, teams with wildly differing release calendars, workflows and Definitions of Done; then extract the common elements of Agile mindset and put it down to something that be observed on the ground.
One more creative spark
How to make it more fun? One lucky strike for us was that we had the inimitable Benoît, a T-shaped developer you might say… for whom one of the T’s arms were drawing skills.
His quirky illustrations for each practice were not only a perfect complement to the short, to-the-point descriptions of the behaviours we wanted. In fact, the quality of Benoît’s work pushed us to get the rest of the card’s design succinct and fun to match.
What is Core?
All this design fun couldn’t absolve us from deciding which practices to include and which to skip. Put a dozen Scrum Masters and Agile Coaches in the room and you will easily get literally hundreds of possible practices from all the world of Agility and all its odd relatives. To settle for only a few dozen (the total number of cards is 55) we had to make trade-offs. In the end, as in any self-growth exercise, it was not really about creativity; the creativity was in the form, but not in the contents. It was about productively hurting ourselves to stimulate growth. To pick the appropriate stimulus, we had to look deep into our own beliefs as Scrum Masters and reconcile them with what the management’s goals for the organisation were.
There was the nagging doubt hounding the project from its inception: are we just translating the Scrum Guide into the form of cards? And not only that, aren’t we setting ourselves up for the charge of “Scrum-But”, the anti-pattern often decried in Agile literature, where a team or organisation cherry-picks only the elements they want to keep and jettisons others?
In fact, this is not how we thought about it at all. We did not deny the value of any of the Scrum Guide’s elements, instead, we made a conscious choice as to which of them — and maybe others, from other Agile traditions — we needed for the Shu level of mastery. For ambitious team members and Scrum Masters, there will be plenty of time to reach the Ha and Ri levels, to discover the ideas we did not explicitly include in the cards. For the vines to reach for the sun, someone must prop up the vines with stakes first, and this is what we aimed to achieve with our cards.
Besides, as we admitted amongst ourselves as Scrum Masters with decades of experience between us, there is no such thing as “perfect” Scrum or Scrum implemented by the book. Everybody picks and chooses, and if we are to have a good Scrum-But rather than a perfect Scrum-Bad… so be it.
Does the stake curb the vine’s freedom to grow? Did we curb our teams’ freedom to learn as they pleased and in the direction they wanted? Yes, but that’s sort of the point: we can’t have a productive vineyard unless the vines orient toward the sun. In the end, it’s a learning process, and the cards propose one way that we decided to go for. Nothing prevents teams from trying other ways, as long as they are aligned with the organisation’s goals.
… to be continued in the final part three, check back on April 7th!
