What is agile, part 1

Today in class, one of my students asked the seemingly straightforward question, “what is agile?”.  This got me thinking – what is the most fundamental aspect of agile? My unorthodox view is that agile is simply the name given to the bundle of values and principles that result in more successful outcomes in software development.  Agile is the better approach, by definition.

The agile concept has become muddied by implementations driven by misinterpretation.  For example, many managers are sold on agile by the promise of getting more work out of their staff in less time.  They end up building scenarios that focus on wringing as much work out of the dev team as possible, burning them out in the process.

With that in mind, let’s take a step back.  What are some of the practical indicators of a team practicing real agile?

• Small projects, where it is easy to fully comprehend all parts.
• Team members genuinely caring about the project.  They have a connection to the work and to the customer.
• Team members working in physical proximity to each other.
• Automating as much rote work as possible, resulting in very little manual rote work.  Most activities are novel and creative.
• Having plenty of time to do the work, with extra time left over for trying innovative techniques, reorganizing, refactoring, and reflection.
• Professional pessimism is common – there is always a better way to do things.
• Having total autonomy and trust from management to change the team’s process and tools.
• Keeping things as simple, lightweight, and easy as possible
• Possible to completely describe the depth and breadth of the work to be done in an iteration.

This is not the whole list.  However, these patterns are some of the most uniquely agile.

In contrast, here are the characteristics that are typically seen by companies following “agile in name only”

• Teams driven to get more done in less time.
• Old roles with new names – for example, “project manager” becomes “scrum master”.
• Too many meetings
• Feeling disconnected from the customer, and rarely or never coming into contact with them.
• Not caring about or understanding the value of the product.
• A general sense of irony or hypocrisy.  For example:
  • Mission statements extolling the benefits of continuous improvement while scrum masters tell their team that the requested improvements cannot occur because “we have to learn to live with what we have”
  • Directives that imply autonomy while simultaneously enforcing the traditional command-and-control corporate hierarchy.

This is not the whole list, but there are some of the patterns most unique to companies trying to follow “agile in name only”

Given this reality, it occurred to me that a company is able to make progress towards agile by adding the good parts in piecemeal fashion.  How hard would it be to get your dev team in contact with real customers? Could you have more people co-located? Perhaps trying for a real MVP – minimum viable product – as an exercise.  (In particular, crafting an MVP is a great opportunity to see how wildly different agile pacing is, and needs to include an experienced practitioner). Perhaps an upcoming big feature could be an opportunity to create as its own separate project, having its own build pipeline and release schedule.