Archive for July 2010
As I spend more time with leadership at some of my client organizations a theme has started to emerge in our conversations. An aspect of that theme is the curiosity about the preconditions of Agile; "What is the sine qua non of Agile?". A variant is the line of questioning on what I look for in an Agile environment. My summary of Agile in three words: Creative Empirical Mindset. Here's what I mean:
- Creative: Regardless of the current stance, people leading agile adoptions are, usually, after a new approach to deliver business value. The only realistic and sensible path forward, quite convincingly to me, is to break the routine. This may include, for instance, suspending the division of labor while approaching problem solving within teams. In the interest of getting rid of the historical hangovers of the past, highlighting the unproductive and unfriendly practices, new ideas, and objective feedback are often the best place to start. Unfortunately, the pressure-cooker environment that has come to be in businesses, the approach to "manage" people, and the sophistication of services provided seem to hint at specialization in skills, maximizing their utilization, and staying focused on the "best practices". This has left little room for tolerance of mistakes, missteps, or adventures, which are expected byproducts of creativity. A valuable observation in creativity I have come to admire, watching a few good leaders in the field,is to stop being antagonistic to those who are.
- Empirical: This is one of the more subtle concepts to tackle in the Agile sphere. Agile or not Agile, empirical approach is utilized in a lot of environments. Agile empiricism is contextual to creativity and to the practices being followed by team(s) on a daily basis. Empiricism in an agile environment is the lever to direct and better utilize creative aspects of Agile and for the team to have its own self-awareness of sorts. Is the team able to, motivated by a desire to continuously improve, reach empirical conclusions?
- Mindset: In contrast to a process, which tends to codify a sequence of steps in order to reach an end goal, Agile teams are driven to confronting novelty and improvise. In effective Agile teams that craft software, I have not seen a propensity for processes. There almost seems to be no need for it. Often, as I have noticed, the people engaged in these teams don't need one. They are motivated to deliver a good product and seem to know what it takes to get one built and running. They abhor "process" because it restrains them and injects delays in their work. Most importantly, it takes the very soul out of work, because it leaves little space for the thoughtfulness to prosper.
"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.