Hillel, agile and the importance of golden rules

Every Passover at my Seder table, we tell the story of Rabbi Hillel, who comes up for two reasons. First, he invented the sandwich, which we commemorate by eating bitter herbs with matzoh, and second, for teaching an early version of the golden rule, which, as the story goes he gave in response to a challenge to teach all of the Torah while standing on one leg. His response was “What is hateful to you do not unto others, the rest is explanation, now go and study”. 

In technology, we have a lot of methodologies and tools to learn, ways of focusing and aligning people and teams, expressing requirements, and systems for bringing all these things together.  New ones pop up all the time, and there’s alway someone who just read an article who wants to solve all the teams problems by applying this new magic solution. 

I have been one of those people for years. Always searching for the better way, looking for better ways of managing and aligning people on technology and product projects - searching for better tools and processes, and doing the hard work of cultural and technology transformation that is the only real path to making gains. 

Along the way, regardless of the methodology, toolset or approach that you are attempting to learn from and apply, there will always be people who will be ready to tell you you’re doing it wrong. Sometimes these are well meaning and well guided. Sometimes they are ill informed or come from a place of methodology purism that is unhelpful at best.  

In the Hillel story at Passover, the thought that I often have is about the relative importance of applying the principle that Hillel responds with, or his commandment to go and learn further.  Clearly the answer is that both are important, but if you are concerned with living a good life, Hillels first, clear response is more useful than his second. 

So it goes with technology methodologies. Far too often when I see programs to adopt lean, agile, ITIL, or any other framework for that matter, the focus is on the detail, bureaucracy and processes that are represented and not on the core issue that the methodology is attempting to solve. The result is often a hodgepodge of new processes and tools that are empty and effectively meaningless. As a Rabbi once said to me, following the Jewish dietary laws if they have no meaning to you is an empty action.

This is why, IMO, it is so important to distill complex methodologies to their essential golden rule or principle before getting into the myriad discussions you can have about roles, processes, ceremonies and tools.  If you’re not discussing focusing on outcomes and eliminating waste on day one of adopting lean, you are missing the point. Equally, if you are not talking about doing everything to maximize communications, break down barriers, empower teams, and move planning into shorter, iterative time horizons then you are not having the right conversations about agile.  

One of the things I applaud about Agile is that unlike many frameworks it didn’t start with a multi chapter framework designed to enrich consultants. It started with a manifesto written by practitioners who understood that software is built by people, and people operate through relationships within cultures. Agile started through the expression of golden rules in the agile manifesto.  

So, as you embark on a journey to agile, DevSecOps, Lean, domain driven design, or whatever the latest iteration of “the better way” happens to be - focus on the essence of its principles and how it may apply to the situation you are currently working and living in. Then go and study.