Developing an agile enterprise of course means changing systems and processes, but it also means changing how people behave and work together.
Let us set an outline first, why do we want to be Agile? For me this is evident. In a world where change has become the one and only constant factor, this in combination with ever evolving technological opportunities, we have to be able to respond.
Agile delivers better business value in an earlier stage with better intrinsic quality. On top of this, this is where the word Agile comes in explicitly; we are better able to respond to change, new insights, new opportunities and new possibilities.
In addition, agile is a way of working which is fast, effective, efficient and focused. And in 2017 every organization which is not able to handle the dynamics of the ever-changing environment, is doomed to fade out. Agile makes your business or organisation future proof.
The agile mindset
Agile in itself, the rituals which you can find in various forms in Agile methodologies such as XP, TDD, AgilePM framework, Scrum, Integrated Agile, etc., are not complex. Still we see many individuals, organisations and departments struggling. The question is, how come?
I was working on my first Agile transformation (DSDM implementation at the time) in the late 90-ties. Ever since I notice people who just can’t believe it works, not even when you have the client with you explaining what and how we worked changing the client’s organization. “Yes but” is heared to often. Quote: “Yes but, that does not work for us.”, Reply “Did you try?”, Reply “No”…. Strange isn’t it, people who state it doesn’t work but never even tried. This often happens even when agile has been successful in organizations similar to their own.
This is where my approach on the paradigms comes in. People work within cultures (organization, region, country) and behavior is based on paradigms (perceptions on how life is and how it works). The paradigms are strong, and on top of this, paradigms define reflexes. Reflexes of people, departments, managers, etc. This is the issue. They learn how to do Agile but are not coached in changing their paradigms, their beliefs.
So changing an organization to Agile means helping the individuals to overcome their own paradigms. A pre-condition is that you change the environment. You can’t change individuals. They will only change when their habitat (their “system”) is changing. This is where the management and hierarchy suddenly really become important.
Role modelling is essential. When the environment (and therefore management) does not change, paradigms stay the same, behavior stays the same and Agile will not be successful. Organizations which implement Agile without changing anything in their structure will not be successful.
I learned that real change can’t be delivered without strong and directive guidance Businesses and organisations must:
• Change the habitat (including hierarchy, management, bureaucracy, etc.)
• Guide directively otherwise they will stick to their old paradigms
• Allow people to learn (and therefor make mistakes)
• Make sure the change is sustainable (because paradigms are strong)
Over time I developed the Integrated Agile Transformation Model or IATM. IATM is in itself an Agile approach for change based on a model for corporate Agility. It has head and tails, start and a finish. For me, an Agile transformation is a project or a program. When you ask me when an Agile transformation is finished I would say “when the level of adaptability of an organization has become high with an internal platform for continuous learning, continuous improvement and continuous innovation”.
Here logic comes in. If you want to change a habitat you have to know and understand the habitat in order to take appropriate action. The “habitat” has to be plotted to determine the steps needed to deliver the agile environment, which is the ultimate goal of the exercise.
Let us call this an Assessment. All sorts of change. Behavior, processes, technology, rituals, standards, etc. Creating an overview of the changes to make (the transformation backlog) is basicly the first set of the work for the agile coaches.
Before you start coaching you have to know who to coach, to agree on how to work as a transformation team and, most importantly of all, identify candidate internal coaches. Coaches who can take over the work when the team is disassembled (as they often are externals, hired for their expertise). You need continuous Agile coaching after the transformation because the old paradigms are strong and you need people to maintain and build on the change achieved.
So, once you know where to start and where to go and understand what every change you make has to be sustained, you can step into the real change process. Let us say, you just set Transformation Foundations. To be clear, this process takes a few weeks, all worked and delivered in a very Agile way. Just beginning is not an option for me. When I sail I need to know my boat, my target and I have to set an outline how to get there.
So now we go into the change process, the Agile transformation. We have to start synchronizing people first. There are always individuals or teams already doing some sort of Agile. Making sure everyone understands each other is important. It doesn’t mean everyone has to work the same way. The point is they have to work from a shared framework from which they can use what helps them best.
Training is how be begin. Because people are still used to their old habits, paradigms and rituals, the first thing we have to do after the training is give them very directive coaching. This is a strong learning moment and guided by their coach. They continue with their usual work but approach this in a new way guided by their coach.
The next step is coaching the teams and all stakeholders (including all levels of the organization) on the team level. The success in Agile comes with quality and the discipline you apply using the Agile rituals.
Coaches will guide all involved strictly, at the team level. Getting the team process going is essential. When this is in place, the moment for individual refinement has arrived. After being trained and coached as a team it is now about the individual. Ultimately everyone will develop over a two-four-week period the agile mindset they need to make and sustain the changes needed.
In IATM this takes 13 weeks. Coaches can work during those weeks with a maximum of three-four teams, a maximum of approximately 30 people. This cycle I call the ‘wave.’ At the end of the wave we look at the transformation backlog, we refine it, adapt the working agreement when needed. Moving forward the internal coaches can now take on much of the remaining training that is needed, leaving the coaches to begin work with a new set of teams.
Sustaining the change is essential. In IATM we have two vehicles for this. The first one is the internal coaches and the second one are the communities.
The internal coaches are selected together with the client. Motivated people who understand Agile and coaching, supported by their management are the ones to look for. They will join the transformation team during the first wave as apprentices and starting wave two they can contribute as coaches to the change, after three or four waves they should be able to take over the process completely.
The communities are also essential for sustaining the change. Agile has always been community driven. Best practice, proof and learning, are key elements. This should be used during the transformation as well.
People have their ‘communities’ before the change starts and this can be the kick-start of new communities. Some are and some are not yet in the transformation process. Having regular knowledge shares with all helps to understand these communities and how they function. Individuals within the new communities are able to ask questions and above all,take notice of achieved successes obtained by those who are in the transformation. Success is always very seductive.
I work in what we call the Agile way since 1994. And as long as I remember people have told me when I talk about example at conferences that I am a ‘true believer.’ I consistently reply “no I am not”. The fact is I don’t believe, I know. I do, I learn and I improve (there is not try, you or do not as master Yoda said). I am a knower.
Agile transformations can be truly successful. It is however important to understand where the complexity in the transformation process really lies, which is replacing the paradigms.
Understanding this and having really educated (our coaches are trained in human behavior or even have a degree in for example (clinical or social) psychology) is essential.
The benefits of working Agile in one sentence would be; “Knowing what we deliver, Transparency when we deliver and delivering together.
Robert BOSCH GmbH, Business Unit Breaking Assistance, had clear objectives about how they wanted to improve their working processes.
They wanted to speed up their delivery, in order to have more time for innovation. Also, they wanted to improve the transparency in their workflow, break down knowledge silo’s and prioritize the workload in a structured manner.
“We work in a highly technical and competitive market, bidding against competitors who sometimes are greenfield technical startups,” said Timo Divivier, Senior Manager Data Driven Technical Optimization, BOSCH GmbH. “We have the advantage of having a great reputation and established production line, but we feel the pressure to be more innovative.”
Timo continued: “Supported by Wemanity’s Agile coaches we chose for power coaching on the subjects that hindered us most. We have made progress in knowing what we deliver, and we mostly deliver incrementally. Also, we’ve identified knowledge silo’s and broke them down. We are pairing now and have focus on resolving our technical dept. The collaboration amongst teams is higher, which has a positive effect on the teams as well.”
Facilitating the discussion
Timo also commented: “The biggest impediment we are facing right now is solving the technical debt of a team with several specialties. It’s visible that the lack of technical skills needed is slowing the team down. But I’m sure that with the right focus we will be able to get the team up to speed.
“What helped us most in our progress was transparency and the implementation of the Agile rituals. It took a while before the teams and the stakeholders were in the rituals together.
“But now that we are, it’s obvious that the discussion that we have helps us focus on our goals and deliver value. The Wemanity coaches helped us by facilitating the implementation of the rituals and giving us insight on the technical debt and transparency in our project portfolio and setting the right priorities.”
Arie van Bennekum, Thought Leader, Wemanity and Co-author of the Agile Manifesto
Arie is a pragmatic who embeds his pragmatism in structure, discipline and common sense. This eventually led to being one of the authors of the Agile Manifesto and expert in the area of Agile Project Management, team facilitation, Agile techniques and user involvement.
Believing in his team, facilitating them to reach their best combined with end user involvement have his focus when he speaks, presents, demonstrates and lectures about Agility. Today, as Wemanity’s Thought Leader, Arie focusses his energy on leading big Agile transformations for big international corporates and researching better ways of integrating Agile.