Many people ask, what is the distinction between an Agile adoption and an Agile transformation? The former being the adoption of an Agile method and tools, and the latter encompassing those plus the people, culture and mindset shift that must accompany the adoption for an organization to fully realize the benefit.
The real difference between adoption and transformation is that adoption fails and transformation sticks. You don’t really choose one over the other – people that fail to see the difference often do the adoption because they don’t realize that culture is what makes it really stick. Most organizations start with the adoption of a method at the team level within IT. Some will also covey the message to ‘do Agile’ from the top. However, this type of adoption rarely sticks. Middle management is lost in the shuffle, often just waiting out the change and expecting it to fail. The focus is on processes and tools – not people and interactions. The mindset of transparency, adaption and continuous improvement is misplaced in favor of mechanics and metrics.
A true transformation requires the organization to think and ‘be Agile’. It requires the organization to look at their people, organization and culture, as well as their process and tools. An organization will move through stages improving and absorbing changes in these areas. Typically, an organization will begin with a pilot with one or more teams. This allows the organization to best see how Agile will affect the current process and roles, and help to uncover gaps and potential areas of conflict, such as, central versus decentralized control.
It takes time to move through all the stages that are mapped out for the process, and much depends on the attitude and behaviors of leadership. Does leadership model the behavior they seek in others? Do they look to break down barriers to value delivery? Do they reward the team and system success rather than individual or functional success? Another important factor is that the organization knows what it is driving towards. This vision and accompanying goals are what will drive the pilot and future transformation activities. This alignment is the first step. As CC Pace continues to work with companies through this process we see the positive effects gained throughout each organization.
If you are interested in learning more about Agile Transformations, join us on Tuesday, June 13, for a free webinar on the topic! Click here to register.
Have you heard that not all Agile Transformations are successful? Have you wondered what makes some transformations more successful than others? Are you wondering if your organization can be successful?
Here is a little analogy to think about. I recently lost 40 pounds on an eating transformation plan, or more simply a diet. I don’t like to call it a diet, because if I ever go back to my old way of eating I’ll likely gain my weight back. Also if I don’t follow the basic guidelines of the diet, I may not lose weight at all. So what does this have to do with being successful at Agile?
When organizations pick and choose what principles to follow in Agile, it’s like low carb dieters choosing to still eat potatoes, or white bread on their diet. While they may see some improvements, overall they are not setting themselves up for success on this plan. The diet gets blamed rather than how the dieter chose to implement the diet.
When preparing for a transformation, the first step is to get the foundational pieces right. Learn about the plan. Prepare your house by cleaning out your cupboards and fridge, and shop for the good stuff to replace the bad stuff. Learn what the rules of your plan are, and set a date to begin. Note, a new eating plan works better if everyone in the house is on the same plan! Then measure the results, and make corrections as needed.
In an Agile transformation, the steps are much the same. Identify what method you want to follow within the Agile framework. Get everyone onboard by helping them learn about the methodology. Prepare your “house” by looking at the organizational structure and identifying what will work within the transformation and what won’t. Make a decision to replace the practices that don’t fit in the transformation with practices that will support a successful transformation. Inspect and Adapt to keep improving and making course corrections along the way.
So what if your organization doesn’t want to follow the plan to the letter? It’s OKAY… BUT the organization needs to know the impact of alterations in the plan. If I can’t give up my potatoes what does that mean? Will I see the same success rate? How can I compensate for keeping my potatoes?
Some Agile principles are more easily adapted than others. I can counteract teams not being co-located for “face-to-face” interactions, by providing great tools for them. I can bring those team members together for planning sessions, or other occasions to help build the team rapport, and offset the lack of co-location. Other principles aren’t so easily adapted. A poor company culture where trust and empowerment are lacking, may prove to be too much to overcome, leaving the organization with unmotivated and un-empowered teams.
If your transformation has hit a plateau, or doesn’t seem to be working. It may be time to take a look at how you are following the new plan, and where your potato-eating cheats are causing you bloat, and derailing your success. It may not be the method, but rather how you are following it.
As discussed in the first post in this series Agile in the Federal Government – Going, Going, Gone Beyond Scrum, the history of Agile adoption in industry took the path of usage of Extreme Programming (XP) followed by the combination of Scrum and XP. In the government, the adoption of Scrum alone has become the de facto method of Agile adoption with the use of the term Agile and Scrum even becoming synonymous in some agencies. In our latest white paper we discuss why we believe the use of Agile Engineering Practices such as XP is crucial to the success of Scrum projects for the Federal government and that the government can again benefit by combining Scrum with XP as is already in use by industry. We believe this is because Agile Engineering Practices enhance the empirical process control (Inspection, Adaptation, and Transparency) of Scrum.
According to the latest State of Agile Survey by VersionOne, the top three XP techniques in practice are Continuous Integration, Test-First Programming, and Shared Code. What XP practices are you using at your agency? Is the use of them improving quality?