Agile Abstinence: Forbearance in Leadership

Posted on 7/07/2010 by Rajeev Singh

"When should we avoid Agile?" At my last client the President of the company asked me, "When does Agile not work?" It seems that a blog post is on the topic may be useful. Given that Agile is a continuum of an effort to foster communication (technical and social), increase collaboration, drive efficiencies and increase quality, I understand and translate these question as, "What are some of the significant challenges and barrier to Agile adoptions and sustainability?" I want to call out those leaders who understand and acknowledge these challenges, set right expectations with their sponsors, and take a cautious approach forward. And hats off to those who decide not to do go down the route until they get the right technical, social, and political infrastructure in place. Back to the question; factors that pose significant challenges to agile adoption are:

  • Dedicated teams(s): Agile teams thrive in communication rich environments. As communication suffers chaos starts to creep in. A lack of affiliation to a team or perceived split to many teams makes it worse. Team members do not bond well with each other and commitments remain shallow that result in poor quality of outputs. Though many factors contribute, this drop in quality is, in most cases, correlated to lack of communication. Agile adoption becomes an uphill battle and ultimately becomes counterproductive. Utilization metrics are a political heavyweight and sway many decisions in favor or "resource" split between different teams. Poor communication follows not long after.
  • Big Opaque Software Frameworks: In context of teams that produce software, ownership, access and control over the code being written is vital. If developers can't modify this code base to suite their needs and hook various tools into it they can't really do much. Basic practices that contribute to stability and quality of software like Unit Testing are hampered. Extensive upfront design becomes mandatory in rigid software platforms. Big ERP and CRM applications fall into this category.
  • Systematize Agile: Systematization of Agile adoption within an organization are laden with a high risk of being detrimental to its success. It curbs the "inspect and adapt" nature of Agile. Agile adoption will become painful and disappointing if it's template-ized along the lines of some prevalent industry certification models, specially the ones that have over emphasized/specified processes and documents.
  • Untamed Team Distribution: Lack of interaction between development team and business stakeholders adversely impacts the feedback cycle and affects quality of the product. Development velocity takes a hit and ultimately feedback cycles lengthen to a point where either rework increases or a team's progress is adversely impacted. Agile leaders in the industry have figured out approaches to make Agile work in distributed environments but only when a team's distribution is purposefully designed, i.e. they have the luxury to choose the people on the teams, their physical location or have a say on the rotation schedule of people between locations and teams. The persuasion to form teams with individuals that are dispersed between multiple locations and "staffed" to be available might backfire and lead to woefully suboptimal value.
  • Right sponsors: Agile practitioners who typically focus on consulting in Agile enablements or organization transformations often debate about a strategy to spread agility within the organization. Top-down and bottom-up camps exist. I think, regardless of the approach, the common denominator has to be the change of the traditional value models. Adherence to best practices and business processes is still rewarded. Agile enablements are usually not served well by these practices and processes and call for a change. If the leadership of an organization is not yet personally ready to sponsor that risk taking the outcome is fairly straightforward to guess; bad news and a bad aftertaste.
  • Right people: Some of my previous posts talk about the people side of Agile adoptions. It's the people that matter; more so in Agile than any other transformation that I have seen or read about. Agile practices are extremely people focused. The orientation of systems and decision making is designed to make it an extremely fast paced learning environment that is heavy on communication and busy with collaboration. It almost warrants frontier individualism of teams.
It is likely that this post may cast a doubt about Agile and its fit for certain kinds and sizes of organizations. That's not my intent. It is merely to highlight that pioneers of Agile are now starting to experiment on the above stated fronts. Some leaders in the industry are aware of this trend and choose to wait and let the Agile community learn valuable lessons before they adopt it. They don't fear being cast as late majority or even laggards. I have quite a bit of admiration for such hardheaded and matter-of-fact decisions. Image taken from: http://wizard.webquests.ch/pics/upload/98/frontier_400.jpg

No Response to "Agile Abstinence: Forbearance in Leadership"