Agile beyond it’s “sweet spot”
When are agile practices are useful and when should we avoid them? Discussions like this often revolve around aspects like project size, team distribution, lack of management support, etc. All of these aspects seem to have an impact on the success of agile development practices. In his paper “Contextualizing agile software development” Philippe Kruchten (2013) presents a contextual model for software development to guide the adoption and adaptation of agile software development practices.
Kruchten’s definition of agile builds on “the purpose or function of being agile for a business, rather than defining agility by a labeled set of practices”. He points out that many projects “do agile” without actually being agile. As a result projects regularly fail when applying agile practices “out of the box”, without contextualising the approach, i.e. adapting a set of practices to the specific project circumstances.
From his point of view, the contextual factors that have the greatest risks of “derailing agile projects” are:
- Large systems with a lack of architectural focus
- Software development not driven by customer demand
- Lack of support from surrounding stakeholders, traditional governance
- Novice team
- Very high constraint on some quality attribute (safety-critical system, real-time constraints)
“It is very unfortunate that too many advocates of agile development practice are preaching good practices but completely removed from the context in which they were proven to be successful” (Kruchten, 2013).
In an attempt to address this problem, Kruchten proposes contextualisation along two levels: “Factors that apply at the level of whole organization/company and factors that apply at the level of the project”.
The organisational factors (i.e. business domain, culture, maturity of the organization) heavily influence the project level factors (i.e. size, team distribution, age of system, rate of change). The impacts and constraints derived from the first set make “some agile practices suitable or not and will influence the amount and type of documentation or the level of ceremony required by a given project”.
Kruchten confirms that “the ‘agile sweet spot‘ tends to be for collocated team, of less than 15 people, doing greenfield development for non-safety-critical system, in rather volatile environment; the system architecture is defined and stable, and the governance rules straightforward”. In contrast hereto he describes several real world projects that “have tried to embrace agile software development methods but have run into difficulties”.
All of these projects however, have found a “way forward, defined by the following pattern” (Kruchten, 2013):
- Develop a clearer understanding of the contextual factors, using our model, for example, allowed the project(s) to focus on what was specific to their project,
- and specify the areas needing improvement from a software process perspective,
- and finally, select carefully the agile practices that would solve the issues they actually were facing, rather than blind application of a labeled agile methods in its totality, all practices lumped together, for example, all XP practices.
Kruchten concludes his paper with an exemplary mapping of agile practices to project context attributes. He recommends to “build a kind of recommending system: a tool to which we would provide values for the 5+ 8 factors that would give an indication of which practices are usable, which are not, which would require adaptation or special consideration, as the starting point ” for organisations that need to adopt their agile software development processes to their own specific circumstances.
Unfortunately Kruchten only leaves us with a schematic model and some ideas for further research. But I think his ideas are worthwhile and I will investigate this further in a future article.
- Kruchten, P. (2013). Contextualizing agile software development. Journal of Software: Evolution and Process, 25(4), 351–361.