With the number of books, blogs, and articles out there, one would assume that Agile transformations have become a science. It’s surprising to see the number of failures in Scrum adoption. A common reason is the unavailability of essential ingredients for success. It does no one any good to stick to the highest ideals when the ecosystem does not support it. Educated baby steps may be better.
Unclear goals result in loss of time and money
“Agile transformation” means different things to different people. Instead of better outcomes (quality, predictability, or lower costs), we could end up with Responsibility Assignment Matrices, and more processes and new silos while dollars continue to be spent. I have seen organizations go back and forth, struggle to define “where we are” and “where we want to be,” and abandon the effort.
Create a menu of transformation levels
There are varying needs, levels of suitability, and levels of willingness of organizations with regard to transformations. Expectations from Scrum and Agile are as varied as the organizations themselves. To bring order to this situation, I propose that we present a transformation menu
. Expectations, costs, and maturity levels are implicitly identified in the menu items. It helps the customers decide how Agile (or fragile) they want to be.
Each menu item comes with its cost and benefits. There is a common understanding of the goals and an excellent starting point to define success (KPIs).
Here are some examples of “menu items.”
Type: IT Scrum process
Team activities are highly visible and predictable; an incremental value delivery process is in place.
Coaching head count and dip in productivity during transformation (DevOps highly desirable).
Consistency of cadence, adherence to timebox, and feedback on artifact visibility from stakeholders.
In this simplest form, the IT teams would be trained to follow Scrum events and practices. Teams adopt the process part of the framework. They begin to learn Agile and Scrum concepts and start to wrestle with applying the principles and values while interacting with the larger organization. Collaboration within the team is encouraged as well as with the business. If DevOps and automation are available, the release and testing costs will be low, and the team itself will be able to perform consistently.
Type: Enterprise Scrum process
Stakeholders know how to collaborate and what to expect. Transparency is higher.
Coaching head count for non-IT and dip in productivity during transformation.
Feedback from IT ecosystem (business, PMO, governance) on artifact visibility and feedback from team on stability of velocity.
Building on the IT Scrum process, we now start to look at agility as an attribute of the larger organization. The ecosystem around IT is trained in the Scrum framework. Business and other related stakeholders attend Scrum events. There is more direct interaction and participation in events from all sides. However, this transformation level is still focused on the process aspects. Roles are well defined, and silos may not have been broken down.
Type: Portfolio Scrum process
Dependencies are managed well in delivery. Predictability is high.
Coaching on analysis, ideation, design thinking, and technical practices. Interdependent teams plan together in a Scrum of Scrums or similar structure. DevOps is a must.
In many instances, a team may not own all parts of a product. A product may deliver value based on partly deriving value from other services. Dependencies become increasingly important as the interconnections among services, products, and applications increase.
Planning and delivering together requires good end-to-end testing practices and design-and-analysis practices. We tighten up on coding standards and design practices. We adopt better modeling methods, more standardized vocabulary, and building blocks.
Type: Agile Scrum
Self-improving teams. Management can focus on strategy and direction.
Performance reviews based on team performance and 360 degree feedback. Reduce interpretations.
Velocity stability, dollars spent for the same amount of output, less overhead.
In a truly Agile manner, the Scrum teams are empowered. Since rewards are connected to Agile values and team performance, teams will begin to self-manage. The team understands the why
behind the metrics, tools, and their correct uses
. They can evaluate and change processes when needed.
Attention must be paid to the following:
- Hiring the right coaches and ScrumMasters (stay away from process mongers who can come up with a new process for every issue). The coach must be able to explain the why behind framework and process items and provide good options for program management.
- Organization must be able to let go of some control and learn to measure teams by outcomes.
Scaling Scrum and distributed teams
Once the organization is at the portfolio Scrum process, we can then start to think about scaling, building distributed teams, or offshoring. You cannot scale bad Scrum, and working with distributed teams or offshore Agile is easier said than done. Frequently, the only measure of whether to engage in distributed work is hourly rate. Although this results in an immediate cost reduction, it’s important to make sure that distributed teams work well so that the reduced cost does not come at a price of a reduced product.
You will notice that there are enabling factors built in the menu: Process learning by IT, process and collaboration of IT and its ecosystem, collaboration with dependent teams, and finally empowerment of the teams. I believe these are critical ingredients that enable teams to move along the maturity levels. It’s important that organizations know and buy into them up front, or that we try to change only items that the leadership has explicitly bought into.