Agile Transformation is about Implementing Changes in Mindset

Many companies undergo the so-called Agile transformation to introduce process frameworks such as Scrum or Lean and realize they are not enjoying many improvements in the company's top line and bottom line after the awhile. So things go back to normal.

I believe this is due to the intention of the transformation has been misunderstood. It is not about just another CMMI or ISO implementation. Agile transformation means the shift of the company culture, i.e the people's mindset from strong Taylorism, to believe in individual and continuous improvement. The use of "best practices" must be abandoned and deploy people to work on things that they are motivated and passionate about. In most cases, it would result in major re-organization. The end result is mostly people who felt pressure to leave their comfort zone to choose to leave the organization and people who subscribe to that idea stay longer and be more motivated.

"In an organizational context, a process of profound and radical change that orients an organization in a new direction and takes it to an entirely different level of effectiveness. Unlike 'turnaround' (which implies incremental progress on the same plane) transformation implies a basic change of character and little or no resemblance to the past configuration or structure."

Read more: http://www.businessdictionary.com/definition/transformation.html

Organizational transformation starts from the very top of the organization. It often required the shift of mindset from the board, the Chief executives so that the new company culture could be formed. Agile transformation is definitely different from CMMI or ISO implementation, where the later just document the existing processes and force the entire organization to comply, any changes are strongly resisted. Where else Agile actually encourage the organization to embrace changes and seek constant improvement. You do not create more red tape to encourage changes, it is against human's nature.  

How to avoid pseudo Scrum adoption?

I have recently come across a company who claimed they had adopted Scrum for several years, from the conversation I had with one of their Scrum Master, he revealed to me how his company started the Agile journey.

He has been with the company for more than 13 years, started his career as a developer and work all the way up his career ladder to be their Project Manager. After the company decided to adopt Scrum, he has changed his title to Scrum Master.

He shared with me that he is now "managing" 3 Scrum Team, each team has a team size of around 6 to 7 people. The team is aiming at delivering "working software" to their BA, which is also their Product Owner. The have a sprint of 1 month length, so they name the sprint according to the year and month, for example FY1701 for the January Sprint in year 2017. Every day, the team will conduct a daily stand-up which will take around 30 mins. The development team is formed with staff from other functional departments, such as designers, testers and developers who reports to their own line manager respectively. They are working part time for 1 project, a team member might be an active member in other Scrum Team.

For those of you who have learn Scrum, I am sure you could immediately spot several problem with the setup mentioned here. Except for the terminology, I could not see anything in the Scrum's guide the company has been adhered to.

From the discussion, he explained that the company has decided to modify the Scrum process framework in order to better suit their environment. While in principle there is nothing wrong with this decision, however I do not recommend any company try to do this from day one.

Instead, I will recommend any company who wish to adopt Scrum follow the ShuHaRi concept, when come to tailoring the Scrum process framework for their company.

The ShuHaRi concept is an idea that a person passes through three stages of gaining knowledge:

Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.

Ha: At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.

Ri: Now the student isn't learning from other people, but from his own practice. He creates his own approaches and adapts what he's learned to his own particular circumstances.

For a company who wish to adopt Scrum and Agile practices, in the beginning (Shu), the company should just adopt the process framework as it is, and follow the guide to every detail. They should start with just one small team to avoid major change to their organization structure and process. This will allow the organization to have the chance to experience and understand the process framework, and the business reason behind every suggestion in the guide.

Once the company has experienced and completed at least 2 projects with the same team, then they should expand and form more Scrum team. Still, at this stage they should resist any temptation to making changes to the process framework and suggestion in the guide.

After some time (some company actually take one or two years) to gather experience running their project using this new process framework, they should gather enough knowledge to reach the stage (Ha) where they could slowly making necessary adjustment to the process framework carefully. They need a good business justification on every adjustment make.

Till date, there are only a handful of company who had reached the (Ri) stage to create their own approach.

Following this ShuHaRi approach, hopefully the company could avoid making adjustment to the process framework and practices prematurely and end up with Pseudo Scrum adoption.

Fake vs Real Agile Transformation

Under the market pressure, many company choose to undergo the transformation to adopt Agile practices. Or in another word, Agile Transformation.

However, many company have choose the wrong path to perform the transformation. As there are two type of "Agile" Transformation available. One is just to adopt the processes and tools, while keeping the company "waterfall" mindset intact, the other is to over haul the company culture and adopt the Agile mindset.

The formal is one is the easiest route to perform these so-called transformation and is widely popular. It is also the easiest to sell for most of the consulting company who are selling consulting service to those company who want to perform the transformation. They are widely regarded as the safest way to perform the transformation, simply because there required no change in the mindset or the culture. While the later required a strong political will from the company's management to perform the transformation, stepping out from their comfort zone.

To adopt the proper transformation method and enjoy the true benefit Agile can bring, the organization's top management's understanding on Agile is essential. Most organization's top management treated Agile transformation as another process re-engineering exercise, they will either leave it to the external consultant to perform the task, or simply hired a "certified" Agile professional to run the transformation office. The result? They will simply choose the easiest route, even if they had hired someone qualified, they would not be able to render proper support.

Hence, before an organization decided to embark on the transformation journey, I would strongly recommend the organization's top management i.e the CEO to attend proper training. Talk to as many practitioner as possible, attending Agile meet up. So he/she truly understand what benefit the transformation could bring, and what is needed to make is a success.