Recently, I came across an interesting case study by Scrum.org, in which an organization re-thought their Scrum transformation after a dissatisfactory one, and has achieved significantly better results in their 2nd attempt. The difference between the two was: for the first time, they approached it from the methodology side, while for the second time, they did it exactly the other way around, building from the agile values. In enterprise agile transformations, like the ones we participate nowadays, this topic plays a significant part in our everyday thinking.
If I had as many dollar bills as many times someone has called agile a “methodology” (sic!), I would no longer be in the need to work as an agile coach. This is despite the fact that every trainer on every agile basics training, the Scrum Guide, the SAFe, books on the topic, all start with saying: agile is a mindset, an approach, a movement. Even calling it a religion would better describe agile than calling it a methodology. Yet everyone, from top-managers, through POs, till squad members, is asking us, agile coaches: how should they do this or that according to the agile “methodology”, or what is the standard answer for their question.
One would gladly answer these questions with “there are no standard answers in agile, self-organize yourselves and figure out the ideal solution”, or “focus on the core values of agile and act accordingly”. Standard answers won’t make us agile. Just because we have daily standups, and we call the line manager chapter lead, we are not ahead at all. As Quimby, one of the most famous Hungarian bands sang: “without love all houses are empty,
All cities are deserted.
Every genius is clumsy,
just a cowardly rabbit in a hat.”
(I tried to rewrite the song like, “without agile values all standups are empty” and “every agile coach is a clumsy rabbit in a hat”. Unfortunately rhymes didn’t add up. - the author)
So why is it a problem if we call agile a methodology? Because we create the feeling this is something readily available, invented by smart people somewhere, and we only need to apply it. Probably this is the greatest concern of most of the “religious” agile coaches with SAFe methodology. Despite it emphasizes that the pillars of agile are the values and principles, SAFe provides so complex and thought out methodology that it becomes a struggle to convince colleagues, who are just getting to know agile, to rather follow the mindset than the rules of the methodology. Nonetheless, just because we sit into a Formula-1 car, we won’t become Schumachers.
Let’s look at Intralink’s case, the one I referred to in the introduction, more closely. First round: implementing Scrum. Everyone got a thorough training, the organization changed, Product Owners were appointed, and everyone was informed about Scrum values as well (see diagram below). Yet, something wasn’t working. Despite the good will and hard work, after a few small initial success stories, the transformation got stuck. So what was missing?
📷
At Intralink, they concluded that values and principles are good and nice, they just can’t tell us what to do in my daily work. The methodology is useful, but only when the values are there too. The logical conclusion is: let’s make the connection between the two! So we reinvented the category of principles, which is hands-on enough to answer our everyday questions, yet abstract enough to reflect the core values of agile. Agile approach also provides us with ammunition. Along with the Agile Manifesto there are the 12 principles. However, they are worthless until they are ingrained into the organizations’ declared and/or lived principles.
What can we do, as a leader, to transform our organizations’ principles? The solution is simple yet complicated at the same time. Demonstrate these principles, say them out loud and frequently, and keep your integrity by acting accordingly (at least most of the time). For example, when a Tribe Lead himself verbalized during a quarterly planning event that he wanted teams to deliver customer value (actual, working solution) instead of concepts and plans, as early as the first sprint, it had an enormous positive impact.
What can we agile coaches do for all this to happen? Keep our eyes open and act on every opportunity we see. Our role alone is inadequate to achieve this degree of change. Before the Tribe Lead’s words, during our 2-hours long discussion with the Product Owner, I wasn’t able to convince him to deliver smaller yet ready MVPs. Later, however, I had a much easier job, I only had to keep watering the planted seed and reminding him about the Tribe Lead’s words. Let’s have discussions with leaders about such topics, nourish the planted good ideas (and get rid of the less good ones), and above all, be patient, a large scale agile transformation is not a short process!
Written by Tamás Nagy, CFO&Agile Coach at edUcate, former startup CFO, venture capitalist and KPMG business advisor