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. 

Misconception about Complete Product

One of the most common misconception for people who have spent too many years in the traditional project environment is, they believe they must have a complete product to Go-Live at the end of the project. This belief has been a big major stumbling block in practicing the "Customer Collaboration over Contract Negotiation" value in Manifesto for Agile Software Development.

Instead of discovering and deciding on minimum viable product, so they could release it early and receive early feedback from user, they are aiming on a big bang approach to have the "complete product" before they are willing to launch it.

I have spent countless hours trying to educate some people on the perception of complete product, a complete product, just like best practices, will require no more enhancement. Over the years, I have been fortunate enough to come across some of the complete products as below:

Yes. The above list are some products that are complete. i.e. There will no more enhancement whatsoever add to them anymore!

You get what I mean, as long as a product are still in use, there will be modification or enhancement make to them. Hence those products can never be regarded as completed. The only products that can be considered completed are those obsolete products. So, are you still looking to have a complete product before you are willing to release them?

PRINCE II Agile??

Just finish watching this interesting video about PRINCE II Agile

It is interesting to see how people react to the rising of Agile Software Development methodology. In this video, it explain why PRINCE II by itself is complied to Agile Manifesto, though it conveniently forget to mention the 12 principles. The host also try to justify (by cherry picking some example from Scrum process framework and etc) on why PRINCE II has been Agile all the while.

What they are missing is, Agile is not about the process, it is about the mindset. You can definitely be Agile while using PRINCE II process framework, it is just that some process framework are more efficient and some introduce more waste. To be Agile, we would like to be more efficient by eliminating the waste.

The host pointed out the difference between Agile planning and PRINCE II planning, i.e. empirical planning in Agile and rational planning in PRINCE II. The host missed the point that the reason why Agile using empirical planning, is because they embrace the fact that changes is the only constant in life. Hence, investing heavily on detail planning upfront is very likely going to introduce a lot of waste.

The host also making commend such as the time-box duration can be longer, he was quoting example of 1 year duration. Here he missed out the point of the reason why shorter length time-box is being encouraged, it is to have early feedback. This is aim to eliminate the waste by having early confirmation on what is developed.

As a conclusion, I still think that PMI's approach to the "Agile Problem" is better. They had went through the stage of introducing iterative project management approach, to finally realize the incompatibility and introduce PMI-ACP.

How to be Agile?

I have came across a very interesting question lately, i.e. how to be Agile?

Well, if you are just looking at the surface meaning of Agile, it just means being flexible. Business would enjoy great benefit if they could have an IT team that allow them to respond to change.

However, if you look deeper into the Agile manifesto and principles, you will notice that it is very much related to Lean Principles. Which, the primary of Lean Principle is eliminating waste.

So, my typical answer to those question is, if you truly wanted to be Agile, you have to practice Zen thinking as individual and adopt Zen culture in your corporation. But why do I say so?

Practicing Zen allow you to grasp a better understanding of what is "Value", and value is at the center of the entire Agile spirit and methodology.

Let's look at the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

If you notice, being Agile means we really need to concentrate on the things that really matter. Not the noise which commonly overwhelm the attention.

Abby has some more points in his post regarding this thought which is similar in line.

http://hackerchick.com/agile-vs-lean-yeah-yeah-whats-the-difference/

We are in a transition from Industrial Economy to Knowledge Economy

Does it means Industrial Economy is no longer exist? Nope, it will continue to be there. The only different is, we have gone passed the day we produce for the sake of producing. To stay alive in the competitive business environment, we must now set our focus on producing value. The company who can produce more value win. This is even obvious in software industry, where duplication is cheap. Basically whoever know how to perform a “copy & paste” function in their computer know how to reproduce something.

This brings to the transformation the title is talking about, we can no longer live in the industrial economy mind-set to be successful in software industry. It’s about producing value. Hence, adopting Scientific Management method from Industrial Economy does not make sense anymore.

The key principle behind Scientific Management is Efficiency! Technical explanation of Efficiency is “The ratio of the useful work performed by a machine or in a process to the total energy expended or heat taken in”. Yes, the focus is to product fast with good quality. 

It is nothing wrong with this approach, however in Software industry, produce more line of code does not yield anything if at the end of the day the software could not produce any value. The situation made worst with other Scientific Management guide:

• Establish clear rules on how work was to be performed. Reduce “rule of thumb”
• Select, train to develop workers
• Cooperate with workers to insure work is consistent with rules identified
• Equal division of work & responsibility between management & workers

Basically, Scientific Management promote specialization. The responsibility of decision making is delegate to the elite person, a.k.a Manager. While the worker just perform the task and complete the plan. The same method has been applied to Software Industry where you can see specialized role or title, i.e. programmer, business analyst, tester, architect and etc. You have the line manager or project manager to perform all the planning and decision making.

Some may ask, what’s wrong with this approach?

Well, Software Industry belongs to Knowledge Industry, where the minimum entry criteria are highly educated worker. Hence, applying Scientific Management does not emphasis learning. In the knowledge economy, the only way to maximize the investment on people is to amplify their learning. To increase their knowledge so they could produce more value.