Take all rituals with a grain of salt.
I’ve being learning and teaching Martial Arts for many years as a hobby, and there are similarities between doing this and leading Products and Projects.
Martial arts teaching in most disciplines, contains drills that enhance your flexibility (agility) as well as routines that are rehearsed multiple times to enhance your ability to react to different stimulations. In traditional martial arts those are called Forms or Katas.
Yet, in “Real Life” martial situations, you rarely see those routines played by the book. The reason is that those forms are just learning aids, not tools to use in actual fights.
Same with Agile and Scrum – Those are not to be practiced as religions with real-life Product teams.
One has to understand that Agile manifesto was published in 2001 as guidelines for good software development, however it’s describing the principles, and not the how-to. Scrum on the other hand was developed in 1986 in Harvard and in 2002 the Scrum Alliance defined the roles and workflows of what is now called Scrum as an implementation of Agile principles.
Scrum, when taught, have multiple rituals that are taking place per sprint – Sprint definition, Planning, Daily Scrum or Standup, Post Scrum lessons learned and Backlog Pruning. Defined to provide the beating drum of an iterative process lead from bottom up.
New roles were defined to reduce hierarchy and brake dependency on traditional roles – Produc Owner replaced the Product manager role focusing on representing the customer voice while prioritizing task in the backlog, Team members are all other developers and testers on the team, democratizing the development activities, and Scrum Master at the high priest to guide the team in the intensities of the methodology, replacing the customary Project Manager role, and further flattening the hierarchy.
However, following Scrum rituals blindly is like putting a Aikido master in an MMA ring, you’re bound to be punched in the face. It’s comforting to have fixed habits and guidelines to follow instead of succumbing to the chaotic uncertainty of software development but there are some drawbacks to that:
Do you really want to engage the whole team in sprint planning? Time cost money and not all people contribute to such a discussion. So, they listen passively and hopefully, work on code in parallel. Pick wisely who’s time to use and syn all later.
Same for daily scrum, is it relevant to review all tasks that are on the table, daily? Some tasks takes longer and some are not important to waste other people’s time listening to. Is the DBA really interested in the tasks of the UX designer? I’m all for setting the beat of the process but select the right Bongo.
Lessons learned and post sprint review and pruning are not to be neglected, yet isn’t it better for a leader to have the team point to improvement and problems on their own initiative? I feel that structuring this feedback loop is just not natural.
Then there is my feeling that democratization of the decision process makes the decisions more tactical in nature, remember the Software Architect is just a member of the team (if there is one) the Product Owner is just interested in business priorities and the Project Manager was replaced by the Scrum Master preacher, as for the Team Leader? Not in the methodology, now try to push that through the middle management of an organization.
Lastly, there is logic in trying to isolate the development team from customer’s demands, you don’t want any Jack and Jill pestering your programmers with problems, but in some cases you want them to feel responsible for their code and putting bugs and change requests in the backlog solly under the responsibility of the Product Owner is not the right thing to do. Some problems should be addressed directly on urgent SLA to the team to solve.
In short, adopt Agile principles wisely and obey the Scrum rituals in a way that is adaptive to the people in the team, the tasks and the customers – Don’t be a Zealot!
