Access Restricted

Don’t Go Here!

The idea of hybridizing agile evokes all sorts of responses ranging from “do” to “don’t:” (usually with more vehemence). The reaction to the Simple Checklist for Assessing Hybridizing Agile Frameworks or Techniques was no different.  For example, Anthony Mersinso stated, “It has been my experience that the driver for hybridization is ignorance or resistance to change.” John Voris suggested in a comment that acknowledging the usefulness of hybridization fosters experimentation. What neither of these two gentlemen suggested was that the principles in the Agile Manifesto should be ignored and that teams should be transformed into robots locked into ineffective processes. The Simple Checklist spelled out a list of reasons that when all of them were satisfied (with perhaps one or two NAs), hybridization made sense. There are, however, a number of “no-go” scenarios that when recognized should immediately send coaches and practitioners running for the hills or at least for more advice!  The anti-hybridization simple checklist is:

__ Hybridization is required due to something else you have changed or haven’t implemented. Every framework is a set of interlocking steps with supporting techniques.  For example, Daily Scrum is a microplanning event that helps teams to adapt to dynamic environments.  Changing the Daily Scrum to a status meeting leads teams to adopt brittle top-down planning approaches.  

__ Processes are changed to avoid involvement. Agile is a team sport. Team members should interact with other team members, product owners, and stakeholders. Any change that reduces or replaces intimate communication should be resisted. For example, having each team member formally write what they did yesterday, what will do to today, and any blockers in an email or Slack is a pale reflection of the expected intimacy of a Daily Scrum (it will also increase the amount overhead, which will reduce the amount of value delivered to the organization).  

__ It worked in my last job. Just because something worked in one organization does not mean it will work now, contexts are always different.  The determination of whether anything works is subjective and does not necessarily mean the new practice is effective or efficient.  I recently heard a senior practitioner suggest that they are great luck with combining the team manager, technical leader, and Scrum Master roles into a single position in their previous organization (picture Evard Munch’s The Scream). The stars would have to align a truly galactic level for this to be a good idea — there are just too many conflicting goals.

  __ Changes are made to facilitate the assignment of work to individuals. The idea of teams and individuals pulling work from a backlog is foreign to many leaders. I recently observed a team in which a team lead (also playing the Scrum Master role) had modified the agile planning game so he could assign all of the work planned for the sprint team members. The Daily Scrum, therefore, became a status report to the team leader rather than a planning and work balancing conversation between team members. 

__ Don’t know what else to do.  Anthony’s reflection on hybridization generated by ignorance is all too common.  Whether ignorance is a reflection of a lack of training or poor training is immaterial. If you don’t know what to do to solve an agile problem, first try the by the book answer, then get other external points of view only then experiment with more exotic solutions.  

Hybridizing agile for the wrong reasons almost never ends well.  Answering yes to ANY of the statements in this checklist some trigger deep introspection and investigation before wandering away from canonical approaches.