Sunday, December 4, 2011

Eat your Own Dog Food - Critical to Successful Agile Transition

I really like “eating my own dog food.”   Before you gross out, I am referring to the expression  the suggests a company should use the product it makes.  There are many benefits, including becoming better attuned to what customers are experiencing and creating tacit knowledge throughout the organization about the product.  I also believe it encourages innovation, increases quality, and builds pride within a company.  

When rolling out agile practices, the equivalent of “eating our own dog food,” is running your transformation effort like an agile project.  Doing so allows you to:
  • demonstrate the practices you are asking teams to follow
  • inspect and adapt to the specific needs of your organization
  • gain support of executives and stakeholders with transparency and demonstration of incremental progress
To exemplify how you can run a transformation effort like an agile project, I share recent experiences in rolling out the Scrum framework to 15 teams within a waterfall organization.  For clarity, I take some editorial liberties in simplifying the sequence of events at this company.  Transformations are often complex and messy, but I do not want to confuse the reader with superfluous details. 

Identifying Key Stakeholders and Defining Success
Before I assemble a team or create a backlog, I approach an agile transformation in a similar way to how I would start any project--trying to understand what the objectives are and what success will look like.  I meet with key stakeholders to understand problems we need to address and/or the opportunities we want to exploit by going through the agile transition.  I seek out multiple stakeholders at different levels within the company (and customers if possible) with different perspectives, as this provides me with a better understanding of the organization, it is culture, and the various players involved.  While some patterns of an agile transformation maybe similar, dynamics in one organization will be very different from another organization, which is why an adaptive approach to any transformation works best.  

I was fortunate to have executive level support in the example organization.  I met with the CEO, CTO, Chief Administrative Officer (CAO), Division Presidents, VP of Development, Project Sponsors, Tech Leads, Developers, Project Managers, Business Analysts, QA Leads, Customer Service reps (as a proxy for external customers), and internal users that the technology group served.  I asked open ended questions to understand what the interviewee wanted from the transformation and to identify what was and was NOT working in the current process.  I learned that there was very little trust between the technology teams and business partners.  On the business partner side, there was very little faith that technology would deliver.  On the technology side, there was a feeling that business partners provided inconsistent direction and had unreal expectations about what could be accomplished with the resources and timeframe provided.  Despite everyone caring about the company and wanting to do a good job, there was a real “us vs. them” mentality.

Building a Roadmap
I became the “product owner” of the agile transformation because I was accountable to the success of the effort.  I drafted a vision statement and success criteria of the agile transition based on what I learned from various stakeholders and got feedback from the sponsor of the transformation.  The vision statement, success criteria, and knowledge I had gained by talking to through the organization provided me with enough information to create a “roadmap” for the transformation. 

In this particular organization, I decided that the “Agile Transformation” would be broken up into 4 “releases”: 

  1. ‘Pilot Agile Practices’ with three distinctly different types of projects for two quarters.  The goal of this “release” was to prove the viability of agile practices within this organization.  
  2. ‘Stand up Dedicated Teams’ assembled teams of cross-disciplinary people dedicated to a specific business unit.  This was its own release because the developers, project managers, and quality assurance team members had been operating as a central pool of resources, often assigned to multiple and disparate projects at the same time.  I thought it was important to get people working together as teams.  Furthermore, the desire was to stand up all 15 teams at one time, as opposed to my initial recommendation of transforming a few teams at a time.
  3. ‘Implement Agile Management’ was next the next release.  The goal was to establish a baseline of the scrum framework across the 15 teams.
  4. ‘Introduce Agile Development, Build, and Quality Practices’ was separated from the introduction of Scrum because I did not have the bandwidth or resources available to implement these concurrently with the scrum framework.  
Having a high level roadmap, as simple as the one above, set targets and direction for those involved with the transition.

Creating a Backlog 
Now with a “roadmap” that suited the needs of this organization established, I was ready to create a backlog.  I decided to capture the requirements of this transformation in user story format.  Some examples of early stories include:
  • “As a trainer, I deliver an executive briefing so that senior leaders understand fundamental agile concepts and how this transformation will impact their org.”  
  • “As a recruiter, I have an updated Agile coach job description, so that I can find candidates that match the desired criteria.”
  • “As a team member transitioning to agile practices, I have participated in a kick-off meeting, so that I have an opportunity to raise questions about these changes.”
Each user story included acceptance criteria that detailed the conditions required to complete of this story.  This backlog was a living document.  I continuously added, updated, re-prioritized based on feedback from stakeholders and my own tacit knowledge about what would work within this organization. 

Establishing a Team
The transformation team, at the example company, consisted of me as product owner, two dedicated team members (one of whom had no prior agile experience), an external agile coach (who was consulting for a limited engagement), and part-time of several others. I am usually against fractional assignments for Agile Teams, but in the case of the agile transition I found the participation of these additional people to be extremely beneficial given their differing expertise and roles within the organization.

The dedicated team member, who had no prior agile experience, agreed to be the scrum master.  This was a great way to test training we has planned for future scrum masters and forced him up-to-speed quickly.  Partway through the transition, he was ready to coach and help teams that had never done Scrum before.

Sprinting the Transformation
Although this transformation team was not building software, we ran all the scrum ceremonies and baseline practices that the agile teams would do.  We did release planning, worked in two week sprints, estimated stories in points, held sprint reviews (aka sprint demos), and retrospectives.  The furniture was removed from an office in the technology area, so that we could post our task board,  tracked progress with a burndown chart, and hold our daily check-in.  We tried to live by the motto, that we were not going to ask teams to do something that we had not tried ourselves. It was visible to everyone that “we were eating our own dog food.”  I believe this not only helped us get buy into trying the practices we were prescribing,  but is the most effective way to run a transition.  

The transformation team was more in-sync about the baseline practices we wanted teams to follow, because we lived them.  The Sprint Reviews provided an opportunity for any stakeholder within the organization to see how the transformation was going and provide feedback.  Working iteratively and delivering value incrementally allowed us better respond to the needs of the organization.  By becoming self-governing, the transformation team was able to come up with better and more efficient solutions than if I was dictating how ever task should be done.  My transformation teammates were a source of many of the stories that we implemented (some of which I would not have thought to try without their suggestion).   

It is a pleasure running an large transformation effort like an agile project.  Did I mention, I like “eating my own dog food”?
Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.