Building an Agile Ship - A Taoistic Approach

Big challenges in building agile teams, in my recent experiences, have come not from lack of Agile knowledge on team's part. They have come from a lack of co-operation that the team members have demonstrated within the team. Seemingly unrelated frustrations like team member's tuning out of critical meetings, not being able to learn new concepts, and even bigotry can be attributed to lack of co-operation. Strategies that I have successfully utilized to increase cooperation, which comes at premium, are:
  1. Focus for Agile education and practices should be on all the roles including managers. By design, most focus of education and coaching should be on hubs that have the most nodes connecting to them. Those are typically managers in teams. In addition to setting the right precedent of leading by examples, managers then set the reciprocation cycle in motion.
  2. Select an Iteration Manager (IM) who sees the role as a challenge, views it as a progression, and is an early adopter of new concepts in general. This will keep the energy level high in the team, and catalysis will keep the team going.
  3. Choose a person that is closest to the team and is liked the most in the team as the IM. In cases where outsiders are the IM, the role should be transferred to one of the team members as soon as possible.
  4. Keep the team size as small as possible. Small teams are most likely to exhibit voluntary cooperation, which increases as communication increases.
  5. Consider a person's personal threshold to adopting a new mindset. It is usually difficult to enable a team of 15 people for Agility with one Agile coach. A few coaches interacting with the team as opposed to just one or two is likely to be compelling enough for potential adopters to give Agile a try. Teams should be seeded with enough critical mass of Agilists who can weigh in on Agile topics, demonstrate the benefits, and convince the skeptics.
  6. It is critical to recognize that learning is a co-operative activity. I have discussed the importance of Socratic methods to enable Agile teams in one of my previous posts. If there's not enough bandwidth of coaches, satisfying Agile adoption in a team is unlikely.
  7. Assemble a good team to start on the Agile journey and learn the right lessons; good or bad. It is extremely important to "design" the Agile team as opposed to starting with just any. This is in line with Maslow's "growing-tip statistics". Maslow asserted that it is the growing tip of the plant where the greatest genetic action takes place. He leaned towards studying and focusing on the best. I paraphrase:
"If we want to answer the question how tall can the human species grow, then obviously it is well to pick out the ones who are already tallest and study them. If we want to know how fast a human being can run, then it is no use to average out the speed of a "good sample" of the population; it is far better to collect Olympic gold medal winners and see how well they can do. If we want to know the possibilities for spiritual growth, value growth, or moral development in human beings, then I maintain that we can learn most by studying our most moral, ethical, or saintly people."
These strategies will solve a few key problems that we observe in environments starting to practice Agile. These are environments where the propensity for Squirrel Agile is high. Bad and selfish proclivities like wanting to be Agile without being Agile are common. Other such common regressive behaviors often include:
  • Free Riding - Some team members get by without participating or working to make teams agile
  • Lack of commitment - Dismissing Agile from the get go or losing faith too early
  • Lack of discipline - Teams cut corners and don't follow the agreed upon practices
  • Lack of initiative - No one steps forward to carry out tasks, e.g. daily standups not held because Iteration Manager was out
  • Contingent co-operation - I yield this much of my "comfort zone" to you, you cede some of your Agile practices to get my co-operation
Some design principles addressing the above issues that I have followed for Agile teams are:
  1. Define clear boundaries. On one of my projects at a large corporation we drew a virtual garden wall around the project teams. It was clear to every stakeholder which people were in an Agile project and which were not. The folks within were to a large extent insulated from the business-as-usual outside of the garden wall. Ideas still permeated through the wall and people from outside could peek over to see what the Agilists were doing. But it was evident to everyone the teams withing the garden were different and they were experiment with news approaches of operating.
  2. Rules should match the team's needs and conditions. Agile teams should be able to adapt the rules of the game to match their needs and organizational environment. On a project that had unsustainable meeting schedules, we reduced the frequency of some meetings, recommended increasing the details of some documents so that distributed teams can get more of their questions answered. The latter goes against the conventional wisdom of Agile, but it suited the needs of the team.
  3. Individuals affected should be able to change the rules. Agile teams should be able to form the rules for themselves. Changing rules should be a mutually co-operative endeavor; not a decree from senior managers or external consultants. External authorities should respect rights of the team members to devise their own operating principles.
  4. Leverage reputations. Reputations are often the most powerful tool to utilize. On one of the teams that I worked with, I went out of the way to find out who's respected and valued for what in the teams. The next obvious step was to connect their passions with project tasks that needed to be accomplished and had them sign-up for these task in the team's and stakeholder's presence. This practice was then transitioned to the retrospectives and sustained there for iteration level tasks.
The temptation of changing a team and radically altering how it works is too great for the Agile coaches to resist. It gets complex as the purview of a coach increases and the size of the organization gets bigger. There has to be a reason, almost always, why seemingly bureaucratic processes exist and are followed in client organizations. Often such elaborate "processes" are the communication mechanisms and the eyes and ears for the leadership into what's going on in the company. Such processes are central to governance. It is wise to acknowledge the fact and evaluate how it can be adapted (not rooted out) to accommodate Agile projects. An approach to introducing and experimenting on Agility with this mindset is better suited to generate co-operation from the traditionalists in large environments. Image taken from: