I can't really cook. I've been saying that for a while. When my wife tries to argue with that, listing all the delicious dishes I made, I disagree: following the recipe step by step is one thing, while understanding the flavors, the techniques, and the essence of cooking itself is the next level of art.
This distinction is crucial, not just in culinary arts but in the realm of management and execution of projects.
Imagine you're handed a diet plan or a workout routine. You follow it to the letter, counting every calorie, replicating every exercise, day in and day out. Sure, you might see results, but without grasping the 'why' and the 'how' behind each choice, you might end up wasting resources, whether that is time, money, energy or even health when done wrong. The diet becomes a list of restrictions, the workout - a series of motions. The understanding that transforms these actions into sustainable lifestyle change, remains unconquered. Moreover, without understanding the "why", the chance of dropping the routine is higher.
This brings us to the world of agile methodologies and frameworks. The best example is Scrum - a beacon for many in the waters of project management. Some teams might follow Scrum events, like sprints, stand-ups, and retrospectives, super strictly, doing everything by the Scrum Guide. But sometimes, what works for one team doesn't fit another perfectly.
It is ironical because the Scrum Guide itself states: "The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions. Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made."
Still, many teams prefer to treat it as a set of commandments rather than the flexible framework it's designed to be. It's a constant point of sarcastic (and even toxic) posts in the Scrum community: teams overdo it or are too loose, with no balance. Respect the balance in the recipe.
Let's say a team does daily stand-ups because the Scrum Guide says so, yet their discussions turn into lengthy debates, losing the essence of quick, focused updates. Or vice versa, the standup is just about "Did that yesterday, will do this today," which is more of a report for management, not a piece of information that other team members will consider when planning their day. Or think of a team that insists on two-week sprints because that's a common practice despite their project's unique rhythm demanding a different pace. These are the moments when following the letter of the guide misses the spirit entirely. It's like following a cake recipe without noticing that your oven heats differently. The result? A burnt cake.
The true power of Scrum, or any methodology, lies in understanding its core principles and adapting its practices to the team's and the project's specific needs. It's about knowing why a sprint is a sprint, why feedback loops are structured the way they are, and how these elements serve the larger goal of delivering value effectively.
In essence, understanding the rules is what makes them work. It's the difference between being me, who can only follow recipes, and a chef, who can create a masterpiece with the same ingredients.
Just to be crystal clear, the situations I'm talking about have two polar sides, which are equally problematic: following the guide/advice/recipe without understanding its core idea and discarding the instructions because you "know better" but later failing miserably and getting back to the starting point. I believe it is obvious where the problem lies in the latter case, so I'm focusing on the first one more in this article.
The methodologies should serve us rather than us serving them. But what can we do to educate ourselves and our teams not just on the 'what' but on the 'why' and the 'how'? There are many ways, but if I could pick three that worked for me, those would be Transparency in Communication, Regular Feedback, and Knowledge-sharing (yes, again).
Knowledge-sharing is about creating an environment where team members feel encouraged to share insights, experiences, and learnings related to the methodologies used. It is not limited to internal workshops but sometimes nurtured initiatives of sharing insightful resources or new tools. Learning the rules is about sharing the pattern in an understandable way. It's easier to follow the rules if you know why they have been set like that, isn't it?
Transparency in discussions means ensuring that every team member, from the newest intern to the most senior veteran, feels their opinions are valued and heard. When discussions about methodologies are open, with all perspectives welcomed, it encourages deeper engagement with the methodologies. Team members are the final users of the framework, they can help developing a shared understanding and spark some good ideas. Like in leadership, it's not about being the loudest voice in the room but about lifting others up and letting the best ideas shine. Steve Jobs said: "The team should be run by ideas, not by a hierarchy." As a team leader, your goal is not just to nail the project by blindly following the "recipe" but also to build a stronger, more creative team that will go out ready to tackle the next challenge.
Lastly, the feedback loops. Feedback should be an ongoing process integrated into the team's operations. Whether through formal retrospectives or informal check-ins, creating regular opportunities for feedback allows teams to reflect on what's working and what isn't. This continuous loop of feedback and adaptation not only ensures that the methodology remains relevant and effective but also reinforces the team's understanding of its principles and practices.
By embracing principles of transparency, continuous feedback, and shared knowledge, we empower our teams to tailor these methodologies to our unique project needs. Just as a master chef knows when to follow the recipe and when to innovate, so must managers learn to navigate the methodologies' principles, ensuring they enhance rather than constrain.
I try to approach my projects with the curiosity of a chef, without a silver bullet for all the needs, and I encourage you to try this approach at least.
P.S. If you prefer a messenger feed instead of email subscriptions, I have a Telegram channel now with (more or less) the same content ;)
