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:

Level	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.

MAE Presentation Agile Beyond the Team Room 6.23.2014 with Daniel Davis

Michigan Agile Enthusiasts Presentation:


Agile Beyond The Team Room

Presented by Daniel Davis & Tom Churchwell




--------

Agile Quality “Whole Team” Ownership

 

 

 

Agile Quality

 

“Whole Team” Ownership

 

By Tom Churchwell

 

Overview

Teams own quality….or not….

Many times, QA is an event that occurs after development is done; like a chef tasting cookies after they are baked.  The common problem with that is finding out we missed a key ingredient after all the mixing and baking and frosting is finished; the worst time to detect a flaw. Good bakers test along the way and maybe even call a spouse in from the living room to taste the cookie dough too!  Getting direct customer feedback during development helps ensure quality throughout the process.  Finding flaws early provides an ability to adjust, adapt or start over with time to recover.  Metaphorically, quality cannot be “tested in”; rather it must be “baked in”.

If your teams are doing a lot of manual testing, or if you have a “QA Testing/Tested” phase after development, then your teams are likely attempting to test rather than bake quality in. It is a common practice and, for most teams and organizations, it is intuitively the way development has always been done. Most traditional IT projects stink; based on Forrester research, more than 60% are unsatisfactory. The QA after development tradition stinks. It is a tradition that produces untold and commonly accepted suffering by the teams delivering solutions and the customers who want to use them.

Breaking this tradition can require some changes to both thinking and practices.  Hiring non-traditional and highly collaborative thinkers, blending and overlapping roles, including the customer when things are still in flux and building for the capacity to adapt rather than “nail things down” are just a few of the changes teams need to work toward. 

Tradition dictates that roles should be clearly articulated and separated. Things should be done in a particular order with specialists doing their particular part in a particular way and at a particular time. Plans and processes should be clear and followed.  Requirements should be captured up front and fastidiously tracked. Being able to predict exactly what will get delivered, by when and how much it will cost is of paramount importance.  Changes should go through a formal change request process. And everything should be captured in writing. Everything should be well thought out, maybe even well documented ahead of time and if anything changes, the implication is that it was likely a failure in planning or execution and someone must have done something wrong.

As good corporate citizens, teams try to work with these background assumptions, knowing all the time that things will change and the team will have to adjust. The teams delude themselves by thinking that with the right people, and just the right amount of heroics, the team will power through the challenges and make the fixed deadlines. In reality however, superior quality falls through the cracks and chasms of miscommunication that exist between even the most well specified roles.  Two people may own their roles and execute in them to a “T” and still miss something major.  Examples abound where the customer says “That’s not what I wanted” and the developer retorts “That's exactly what you asked for in the requirements”.  Deadlines loom and hard choices are forced on the team and in many cases, after a painful deadline death-march, the project goes to production with significant flaws. For teams steeped in traditional software development practices, their suffering is perceived as a “normal” part of doing business.  

Changing the way we own quality

The whole team concept is founded in part on the emphasis on individuals and interactions over process and tools.  In it is the premise that all aspects of quality can be held by the whole team. Teams vary, and the degree to which they are ready to take whole team ownership varies as well.  With an effective and experienced QA Guide, over time, the knowledge, expertise, and capacity to “bake quality in”, can and should be held by the whole team.

Test Driven practices have been gaining momentum and with them, changing the way quality is owned by a team. The “Definition of Done” for Value Stories and User Stories changes significantly.  Meeting quality standards becomes a part of the “Definition of Done” for development teams and like our baker testing for quality all along the way, testing every aspect of a story is now accomplished throughout development.

Definition of Done

Starting with a big picture view of what is ultimately needed for the project to be successful, teams can move quickly to planning the most effective and expedient way to produce it.  Team members can then collaborate to specify what success looks like at the functional level (“Definition of Done”) and how the team might go about producing it for every story from inception all the way through to production.

Specifying a shared definition of done is something the team does collaboratively at the beginning of the project.  It establishes and reinforces beliefs, norms and practices for the whole team throughout development.  It is a reflection of the collective values of the members and the standards to which the team aspires.  Some of the standards may be dictated to the team, like the level of required automated regression test code coverage or some other metrics, but most of the standards should be specific to that team or that particular project. 

Many of the fundamental concerns will be the same from project to project, but the nuance of each project requires that the team come together to ratify a definition of done that the whole team can live with and can agree to hold each other accountable for.  Quality standards should be included as part of that definition of done.  Once specified, a QA lead or any designated team member can track, manage and report quality metrics both to the team and to management.   As much as possible, Big Visible Charts should be used to keep quality metrics a highly publicized part of the ultimate solution.  Big Visible Charts are a straightforward way to help everyone quickly know where the project stands and to foster the culture of quality with the team.  

Inevitably...It comes down to team

Agile solution delivery is a team sport and QA is a contributing member from the start.  As with a traditional project, some events occur in sequence, but with agile, many once segregated responsibilities are now owned by the team and executed as a team.  The agile approach is evolving and so too, is how QA participates on an agile team.  Many QA concerns and tasks are still the sole responsibility of QA, however, depending on a teams “Definition of Done”, many concerns and tasks may be absorbed and owned by the whole team.  In order to become a contributing member of an agile team, QA skills may need to be expanded.  Deep technical and development skills make QA a more powerful team contributor and helps to socialize the role of QA into the team as a whole.  This socialization of QA relieves some bottlenecks that have existed on traditional teams and opens up the possibility for increased velocity for the team as a whole.  The role continues to evolve, and with it, the possibilities for how solutions will be delivered in the future.