The IT world is increasingly using Agile to deliver software. Naturally, we are seeing the various organizations that are developing their own versions of project management and implementation, many of them similar to or expansions of Agile. For example, there is the Oracle Application Implementation Methodology, the Siebel eRoadmap, and Project Management Professional. There are SAFe, LeSS, Spotify, and others.
We hear a lot about both Agile adoption and about transformation, because they are two are different processes. The distinction is philosophical in nature. It is best to explain the two with a few examples. When a child is adopted by parents, it takes time for everyone to see the child as part of the family. On day one of adoption, parents and kids have legally established a relationship, but they become a "family" (transform) through love over time.
Another example is when security checks were introduced at airports for the first time. We all have adapted to the new way of checking in at the airports. After over a decade, we all have transformed to accept the new way of moving through the airport.
The final example is that jumping into a swimming pool to learn to swim is like adoption, and becoming a "swimmer" is transformation.
Merriam-Webster Dictionary defines adopt
- Adopt: To accept formally and put into effect.
- Transform: To change in character or condition.
What is Agile adoption? When an organization has accepted the idea of changing the software delivery model and embarking on the journey, it is called "Agile adoption." During the adoption phase, the enterprise will redefine the roles, terms, and work toward the goal of delivering software. Adoption can happen instantly or on the day when there is talk about user stories. Or, we can say it is happening as soon as management puts the team, including themselves, through Agile training.
From adoption to transformation, it is always a journey. Adoption needs teachers and mentors, whereas transformation needs coaches.
Agile transformation is an ongoing journey because:
- Business and environments are not static.
- The organization is not static.
- Innovation is continuous.
- Human needs and expectations always change.
What tools are available to measure the transformation?
If transformation is a journey, how do we measure it, and what are the tools and yardsticks for measurement? Agile transformation must be measured with the objective of getting things done by the organization.
You can measure the transformation with answers to the following questions.
The human side of transformation
The software side of transformation
- What is the organizational structure? What are the types of changes taking place in the structure, and how stable is the structure?
- Are Scrum Teams truly empowered? Is there a mechanism to get regular feedback from the team?
- How are team members working together, and are they able to take up the work of other team members when needed at short notice or no notice at all?
- How much interest do team members have in attending the ceremonies?
- Are we delivering the working software in short intervals?
- How flexible are teams in accepting the changes?
- How is velocity changing over time?
- Are the opinions of customers captured at intervals?
- How small are user stories, and how well designed are they?
- How well established are the Definition of Done and acceptance criteria?
- What is the trend in the defects counts?
- Is the software scalable?
- What steps are implemented to follow the coding standards?
Trying to explain transformation is as difficult as trying to explain the purpose of life. Life is a journey rather than a destination — and so is transformation.