Many companies begin their introduction to Agile by trying
it on a project or two. If they believe
they have ‘enough’ success with Agile, then typically more projects deploy
Agile. The challenge is that at some
point the company is unclear on what level of Agile deployment has occurred and
what type of Agile is really being adopted.
Senior Management may hear things like “we are Agile” and not really sure
what that means. Worse yet, because of the
inconsistency of understanding Agile, some teams will say things like, “we don’t
need to document anything because we are Agile”, other teams will say “we don’t
need any management support because we are self-organized”, while others will
say “we can’t tell you what we’re building until the end of the project because
we are using Agile”. Now what do you do?
This becomes even more challenging when the company begins
to realize the amount of effort they are haphazardly spending on Agile adoption. Sometimes the company learns that they are spending
twice for the same thing like training and/or tools and often overspending
because they are not leveraging the volume discount strength of the whole
company. This is particularly relevant
to medium and large companies.
Whether you realize it or not, when you have multiple teams heading in roughly the same Agile direction, you have already embarked on
an Agile transformation. So the
question is, do you want to let the change occur in an unorganized and ad hoc
manner or do you want to manage that change in an organized way and gleam the
most benefit from the effort.
I do not believe there should be a prescriptive way to deploy Agile. However, there needs to be some way to ensure the teams are working on the highest customer value work. An enterprise level approach can help. This ensures that the company reduces the muda (a.k.a., waste), leverages and reuses what it can, and ensures all teams are building the highest customer value work.
I do not believe there should be a prescriptive way to deploy Agile. However, there needs to be some way to ensure the teams are working on the highest customer value work. An enterprise level approach can help. This ensures that the company reduces the muda (a.k.a., waste), leverages and reuses what it can, and ensures all teams are building the highest customer value work.
When you find yourself in the situation where there are many
in your company wanting to adopt a certain tool, process, method, and/or
culture, or if it is already happening in an ad-hoc manner, it is highly
recommended to initiate an organized approach to the enterprise change. In Michael Spayd’s “Evolving Agile in the
Enterprise: Implementing XP on a Grand Scale”, he recommends that an “effective
Change team” is established. In my experience,
seasoned Agile Coaches and/or an Agile enterprise leadership team provides significant
leadership for the change effort. The
Agile Coaches/Agile leadership team (aka, change team) provides the framework
for the enterprise but still allows for adaptability and decision-points by
the teams so they feel ownership of their working process.
The Agile enterprise leadership team should include talent
that has experience in Agile enterprise change such as seasoned Agile Coaches and
those who have organizational level change experience. Some members can be matrix-ed in from internal
organizations. They should function as a
team and can be distributed according to the areas within the organization that
they will support. It is often best to bring in either full-time regular
talent or external long-term consultants to ensure that they don’t just make
recommendations, but live through the challenges of the change as they help product
teams, senior management, and others.
What are some of the benefits of Agile coaches and/or Agile enterprise leadership
team? This leadership can help you
establish and manage the following:
- Agile Vision - create a vision for where you can go. A strong Agile coach has been to where you want to go. Without this experience, a company may never get there. This may include a focus on the Customer to build the right thing and on the Employees to build the thing right" or similar. By having a central Agile leadership team to focus you, you can better gain buy-in or at least get folks to understand why you are going in this direction.
- Agile Transformation Roadmap - identify common activities to help a product team come up to speed with Agile. This includes establishing a set of “ready for deployment” materials to help teams get ready for the change to Agile. By having Agile Coaches help you, it will save time and effort from each product team having to figure out the adoption activities themselves
- Agile framework and practices - collaboratively establish an adaptable set of Agile methods and practices with the rest of the organization. By having central Agile leadership coordinate this, it will save time and effort from each product team having to establish Agile methods and practices, although they will need to tailor them for their specific team.
- Agile terminology – establish a common working language for Agile so that members from across the organization can communicate and interact effectively with each other. By having central Agile leadership establish this, this reduces the miscommunication issues that will arise across the organization regarding various and sundry definitions of Agile terminology.
- Agile training – establish a common set of Agile Training aimed at various levels of the organization (e.g., Scrum Team, Scrum Masters, Product Owner, Middle Mgt, Senior Mgt). By using a managed training deployment approach via the central Agile leadership team and education group, we will have consistent training and can get a better understanding of who has and hasn’t been trained. By providing an in-house training approach, this reduces the cost of utilizing multiple vendors. This increases common Agile understanding across the organization and product teams.
- Agile Communities – establish a common organizational Agile website with links to internal and external Agile communities. Having the central Agile leadership team establish and support this, ensure that there is a managed approached to sharing online Agile related information and resources (framework, practices, etc.) across the company site that is kept up-to-date.
- Agile Coaching - A key aspect of the leadership team is to provide Agile Coaching via the Agile leadership team to projects/product teams across the enterprise. They may start with a small core of dedicated Agile Coaches and then can leverage existing Agile talent across the enterprise in establishing an Agile Coaching Circle. Coaching significantly reduces the effort involved with “correctly” getting a team to adopt Agile and more importantly ensures they do not regress into their old traditional habits.
- Agile Adoption measures – establish a common and reasonable set of adoption measures to see what progress is being made in the Agile adoption within the company. By having the Agile leadership team manage this, we have common adoption measures to ensure that the leadership team and product teams are meeting the organization objectives for Agile adoption. Senior management can more readily get a pulse of the Agile status across the organization.
- Agile Challenges Point of Contact (PoC) – establish a central point to manage Agile related challenges and issues. This would include website, email PoC and the establishment of an Agile FAQ. The benefit to having a go-to centralized Agile leadership team to manage this is that they can both become aware of these issues and then resolve the issues and challenges before they cause an impact.
- Agile Vendor Liaison PoC – utilize the Agile leadership team to become the PoC for managing the company relationships with the various Agile vendors. By using a central Agile leadership team ensures that the organization or company is gaining the most leverage from the volume discounts and negotiations for Agile related materials and tools.
Finally, when employees within a company see that many are
going Agile, sometimes it is comforting to see that the organization is
providing support in the adoption effort. It is even more comforting when those
employees that haven’t yet gone Agile see that there is ready support for their
deployment. It is particularly problematic when the
employees are seeing wide variations of “agile” being deployed some of which is
not really Agile, and they wonder when the organization may provide some
guidance in this matter. Introducing Agile
really is a culture shift. If you are
thinking about adopting it or already are, then it can be a benefit to have Agile
Coaches and/or a centralized Agile leadership team to help you navigate to a
success adoption of Agile.
Good luck on your Agile adventure!
Note: this was originally written in 2008 with minor updates
in 2012.
