Thursday, July 3, 2014

Agile Rigor & Autonomy

Value delivery is a skill and the value of knowledge workers is their innovative creativity, passion for their craft and ability to take on large and complex challenges without needing oversight or traditional “Frederick Taylor” type management to deliver.  In other words, knowledge workers can be trusted to deliver but that trust is certainly violated when agile teams start making excuses for failing to keep their promises.

Like something straight out of a Dilbert comic, agile seems to have acquired some convenient excuses for undisciplined delivery.  “We don’t do documentation”, or “We can just push what we don’t get done to the next release” being just a few examples of the memes of undisciplined delivery creeping into a team room. Worse than just perpetuating the IT tradition of failing to meet business expectations*, undisciplined delivery erodes trust and arrests any forward momentum a team has produced toward gaining more autonomy in their determination of team practices.  Less trust, over time produces more oversight, or at least the perception of the need for management oversight.

* Forrester research shows that 66% of IT projects fail to meet business expectations

Traditional product delivery, like for a car or other assembly line product is vastly different than delivery of a knowledge product like software.  On an assembly line, “working hard” is a virtue and overtime is paid “extra” and appropriately so.  Even with software, business commitments need to be made, and sometimes, that means overtime.  However, with knowledge workers, when overtime becomes the norm, innovation and creativity diminishes, and lower quality and burnout are nasty and sometimes unrecognized side-effects. Like a long distance bicycle race, the team needs to maintain a sustainable pace.   

Knowledge workers need autonomy, but not every agile team is ready to take ownership of the P&L and start collaborating with customers directly.  In the tradition of crawl→walk→run, some teams need to work their way toward higher levels of delivery maturity.  Organizational structures and team structures vary:
Organizational Structure
Team Structure
Level 5 - Innovating
Team has ownership of P&L
Team initiates craft improvement practices

No need for Delivery Lead or PM
Self-Referential Teams
Team self-identifies for value and looks to team members for craftsmanship and skill improvement.
Team may demonstrate open defiance of bureaucracy and the status-quo in acts of solidarity that force the organization to confront archaic policies if not change them
Level 4 - Quantified
Fully Cross-Functional Team permeates into all business roles

Product Owner in the Team Room

Less need for Delivery Lead or PM
Self-Deterministic Teams
Teams take ownership of commitments to the business through team ownership of the backlog.
Team will self manage multiple simultaneous projects and how much if not also the priority of what is committed to.
Project Managers or Delivery Leads are no longer required.
Level 3 - Adaptive
Take the work to the team (Teams perpetuate though projects come and go)

Delivery Lead or Project Manager in the Team Room
Self-Organizing Teams
Teams still have managers/delivery leads organizing the backlog, coordinating with a product owner and facilitating reporting, however, the team has ownership of how it will self organize to get the work done. This is necessary first step toward team autonomy
Level 2 Operating
Co-Located Team space established
Teams are still formed for every new project

Still need a Delivery Lead or PM
Managed Teams
Teams understand agile practices, are fully cross-functional and co-located but are still learning, particularly organizationally, how to take autonomous ownership of execution of multiple simultaneous projects as a team
Level 1 - Beginning

People are not co-located
Organized around projects and functional areas
Sequential or inconsistent processes

Reliance on managers
Hierarchy or Command and Control
Clearly separate roles and separation of responsibilities
Task/responsibility rather than team oriented
Traditional project execution with managers determining what needs to be done, by when, by whom, and in what order

Violated trust is the key factor in not making progress toward higher levels of team autonomy, but also a factor in losing previously enjoyed high levels of autonomy.  How a team builds trust, maintains it and recovers trust whenever a breakdown occurs can be different for every team, but the intentional building of trust needs to be as much a part of a teams cadence as retrospectives.  An agile team that does not take delivery practices seriously, or does not perceive the need for higher rather than relaxed levels of rigor is putting itself at risk of becoming a liability rather than an asset for the business.  Agile does not mean do whatever you want and the business is just going to have to deal with it.  It means delivering, building trust and deserving the level of autonomy and latitude the modern business is giving its knowledge workers.