A Personal Journey Into Agile, and Possibly Beyond
I. Agile in the Beginning: Roll the dice.
I can clearly remember my Agile penny drop moment.
It didn’t happen in my first Scrum project (as a ‘Manager’, no less). That was an awkward, shuffling endeavour with hesitant team members, a product we thought shouldn’t really be built, and a developer who didn’t believe in better ways of working.
No, my penny drop moment came a couple of years later during a training session. It happened during a variation of the Dice and Straws Game, made famous by Eli Goldratt in his seminal book, The Goal. The game was structured around two teams lined up on either side of a long table. Each team member had a station: one person represented analysis, the next person design, and so on. We each had to roll our dice and move our pile of cut straws down to the end of the queue, representing the movement of work in progress through ‘stations’ to ‘Done’.
The team on the other side of the table worked things out before my team did. They started off waterfalling, just as we did, but they soon realised that when each person was preoccupied with their own station (or skill, or function, or nest…) the flow stopped. There would be no product to ship.
They started collaborating, T-shaping. They were symbolically cross-functional and they didn’t even really understand it.
But what the game really represented was the absurdity of linear, predictive, product development in reasonably complex, unpredictable circumstances. The craziness of silos. The strangulation of flow. I looked down at my pile of straws, trapped in front of me. The people on either side of me did the same and we all started to laugh, kind of nervously. I had a weird moment where I truly felt something change and a decade of laboured-upon Business Requirements Documents, rushed testing and project death marches flashed before my eyes.
It was the start of something new.
II. Agile in the Middle: Becoming a zealot, then trying not to be.
Like millions of other people from all around the world, I became very interested in the adjective-that-has-become-a-noun… Agile. Capital ‘A’, Agile. Like almost everybody else, I hopped on board the ‘A’ train by focusing on Scrum. It’s almost inevitable, as Scrum’s immediacy has allowed it to completely and utterly dominate the Agile Industrial Complex. But that’s another post for another day.
The problem with falling for Scrum, is that the simplicity of the roles and practices hugely distract from the subtext and the broader picture. Complex Adaptive Systems, Emergence, the Toyota Production System… they’re not in the official Scrum Guide, right?
It’s tricky. The Scrum Guide is only 16 pages long, and consciously does not go into any real detail. There is simply no way to really ‘get’ Scrum from reading the guide. Even if your trainer goes into the deeper context and history, most attendees of a CSM course will remember the roles and practices. The what, some of the how, but not so much of the why. Continuous learning is really imperative, yet perhaps more the exception than the rule.
I was fortunate to experience a challenging inspect-and-adapt process before getting near the CSM course and exam. The trainer in our organisation forbade anyone from attempting the Certified ScrumMaster (CSM) course and exam until they’d completed his IC Agile-endorsed Fundamentals of Agile course. The Fundamentals course and exam were deliberately geared towards internalisation of the Agile Manifesto’s Values and Principles, well before entertaining any thought of servant leadership, or coaching, in Scrum. I really believe this helped me because it provided a solid context in which I could view Scrum when I eventually got to it. I think many CSMs start out on a bad footing, by simply attending the CSM course and completing the exam without some prior appreciation of the intent behind Agile.
Still, none of this stopped me from joining the Agile Police. Freshly accredited CSMs often run around like excited puppies, sniffing out the myriad opportunities to say “Ha! Gotcha. That’s not Agile!” It’s awful, but true - I know that I’ve been through this. It’s difficult to avoid but important to get over. Systems thinking, empathy, and a real interest in helping others are very important to making progress beyond this phase.
III. Agile in the Future: Acknowledging this never ends, and letting go.
It’s inappropriate and simplistic to suggest that there is a beginning, middle and end to an Agile journey. Perhaps Alistair Cockburn’s popularisation of the Shu Ha Ri metaphor derived from martial arts and Japanese theatre goes some way to dealing with this: In the ‘Shu’ learning phase, a student will follow their master’s teaching precisely. The why doesn’t matter so much.
During ‘Ha’, the student will adapt other techniques and begin to understand the underlying principles. The rules will be broken.
At the ‘Ri’ level of understanding, there is transcendence. The student becomes a practitioner, and a different level of consciousness is at play. Some might refer this as the internalisation of the Agile values and principles, which may well change your approach to living both inside and outside of a work setting.
I feel quite comfortable in acknowledging that this never ends. It can’t. Agile is a means to an end, not the end in itself. Remember - it was an adjective: agile software development. It only became a noun as it grew, became productised and commodified. It is not a thing, it is a way of thinking about things and doing things, hopefully for the better!
Need help with implementing Agile Methodology in your company? We're the guys to help you! Hit us up with an email today!
