Free introduction to my book

Please enjoy the first chapter of my book here for free, starting with the Preface.

PREFACE

Agile Transformations are currently a popular choice as a solution to helping organisations deliver large complex programmes of work. Leaders are often told of their huge benefits and lured by the promise of increased efficiency that Agile Transformations are purported to deliver. However, what leaders are not told is that a large percentage of Agile Transformations actually fail!

Why do so many Agile Transformations fail?

This is the question I asked myself and I believe I know the reasons, which I reveal in this book. One of the main reasons is the conventional approach to implementing Agile Transformations and the fact that certain vital aspects are omitted too.

So, I created a solution to this problem, and devised a new model which I subsequently reveal. The solution I present is relatively simple and easy to follow and, if implemented, will save leaders from wasting millions on their Agile Transformations and enhance their chances of success.

Nevertheless, this new strategy comes with a warning!

It challenges the popular method of delivering Agile Transformations.

It challenges the conventional style of leadership.

It challenges conventional change management practices.

Therefore, if the conventional style is your preferred style of leadership – you will probably not like what I present here and will most likely reject it!

However, before you do, if you have already tried to implement an Agile Transformation in an organisation and seen it fail, or if you are considering it for the first time, I urge you to read what is presented here. I urge you to give your Agile Transformation a fighting chance of succeeding. 

It won’t take you long to read what I propose. I have made it purposefully short for busy leaders. It should take only as long as a short-haul flight!

If I am going to present such a challenge to you, why should you believe me? Who am I to propose such a different strategy for Agile Transformations? I don’t believe you can convince people purely by reading about something – they will be convinced by experimenting and finding out for themselves. However, in the meantime, it may help you to know the following about me:

I have been a part of the Agile movement, using Agile Practices and Agile Concepts, for over 20 years and facilitating Agile Transformations specifically for over 14 years. Additionally, for the last decade, following my training in psychological methods, my work has focused on the leadership and culture aspect of Agile Transformations.

Having worked for so long in the Agile space, I know the challenges that will arise when the conventional approach to Agile Transformations is implemented and I know how to overcome them. And so, I urge leaders to take the short time required to read about this new strategy to Agile Transformations.

I also urge leaders to take up the challenge of being pioneers in implementing this new strategy!

By doing so, you will be participating in the important movement towards reducing the level of failed Agile Transformations and prevent your organisation from needlessly wasting vast sums of money on the conventional approach by instead – starting it right.

Mark Buchan. MSc, May 2019

INTRODUCTION

Once upon a time … there was no Agile

Agile is rather in vogue, currently. This is due, I believe, to the volatile, uncertain, complex and ambiguous (VUCA) environment that leaders, businesses and consumers are having to navigate. Agile seems to be the response to VUCA because, by definition, to be Agile is to be flexible. Moreover, Agile as a philosophy is about being more responsive to change (rather than resistant) and adaptive (rather than rigid) and accepting that ‘shift happens’ (rather than expecting certainty).

However, there is an additional meaning of Agile. To geeks like me, who have been immersed in creating and delivering methodologies long before Agile became a sexy term, it also means ‘a software delivery process’ – but there was a time before this form of Agile even existed. In 1989, as a 24-year-old graduate in electronics and systems theory, I started a career in software systems engineering. I worked on some of the most safety-critical projects imaginable, analysing customers’ system requirements and subsequently designing and writing software to implement these systems. In terms of complexity, from radar systems on jet fighters to managing airspace slots in air traffic management systems, I think there are very few projects or programmes that are as complex as some of those I helped deliver. Things do not get much more complex than designing state-of-the-art real-time, safety-critical systems. Trust me, I know complex when I see it!

In order to deliver these programming behemoths, back then we used a ‘Waterfall’ (see Royce, 1970) delivery method. In fact, we did not even call it ‘Waterfall’; we just referred to it as the ‘software delivery cycle’. It was the undisputed way of delivering software, which certain customers insisted on, such as the Ministry of Defence. It even had its own British standard, BS 2167A! We were unaware that this was in fact the worst way to deliver complex programmes such as these, even though this had been identified many years previously (Royce, 1970). In my case, at that time ignorance was bliss!

And then there was Agile …

As my career progressed as a systems analyst/programmer, in the late 1990s, a few colleagues and I started experimenting with a set of new-fangled engineering practices called ‘XP’, including trialling ‘pair-programming’ and ‘story writing’. We did this for a few years within a government agency and experienced some great success, and really enjoyed the experience. Although not officially described as ‘Agile’ at that time, that’s what it was; this was my first experience of working in an Agile way.

In 1999, I progressed into management, so, I was no longer writing code, but managing the delivery of the type of projects I had previously co-designed. In my first management role, I was forced to use Waterfall and found it ‘not-fit-for-purpose’, at least for what I was being asked to deliver. That was when I started becoming more interested in other ways of delivering software. I subsequently became an advocate of Rational Unified Process (RUP), an earlier ‘somewhat-more-Agile’ process than Waterfall. I started helping organisations, including some very prominent and visible government departments and their suppliers, to ‘do Agile’. In effect, I became one of the first Agile Coaches (disguised as a Project Manager), to start to mentor people in Agile delivery.

In 2001, the Agile Manifesto (see Figure 1) was created, after those at the frontline of software delivery championed a new way of managing and delivering complex software projects and products, and Agile was officially ‘born’! It was created because there were four main issues with software delivery that the creators wanted to solve:

  • 1.   Delivery of software was always late.
  • 2.   Software was over budget.
  • 3.   Quality of software was poor.
  • 4.   Software rarely did all that the customer wanted.

Figure 1: The Agile Manifesto

However, since the inception of the Agile Manifesto (2001), Agile has evolved from Agile engineering practices, to Agile project management methodology, to Agile Organisations, and it has really started to gather pace in the past few years. Hence, it has expanded from having a general focus on delivering complex software solutions more effectively, to helping organisations respond more effectively to change (e.g. The Agile Organisation; Holbeche, 2015).

And then there was Agile Transformation …

Rather than being localised to small teams at the project level within the IT department, Agile is now being applied at the organisational level, something that is referred to as ‘Agile at Scale’, ‘Enterprise Agility’ or, as I like to call it ‘Organisational Agility’. Scaling Agility from one team to literally hundreds of teams involves a meta-process that is referred to as ‘Agile Transformation’. After working for some years as an Agile Coach with frontline teams, I also moved on to delivering larger scale programmes of Agile. Being involved with these large-scale Agile Transformations concerned working with teams based in multiple locations around the globe utilising the off-shore model, and coaching and consulting at all levels of the organisations. Consequently, I have been doing ‘Organisational Agility’, facilitating Agile Transformations, for more than ten years, at the time of writing.

I personally consider the evolution of Agile from project-level engineering practices to Agile Organisations a positive one, because there is much to be gained from using Agile Practices in other areas of an organisation, not just within IT. Many of the Agile concepts applied within technology are equally applicable in a wider business sense, such as ‘inspect and adapt’, for example.

However, moving Agile out of the context of purely delivering technology projects and into the business context, has resulted in differing opinions with regard to Agile Transformation. Differing opinions are not the issue though. The issue is that these particular differing opinions have resulted in confusion, particularly regarding what Agile actually means, what is involved in an Agile Transformation, and the benefits of it. Customers of Agile are often told that doing Agile will make the organisation more efficient, which is not necessarily the case.

I believe this is compounded by the fact that there is a lack of a single agreed definition of Agile. I see this as also partly due to how the Agile Manifesto (2001) is interpreted, and the emphasis placed on different aspects of it, because people’s values differ. These values relate to their experience and who taught them about Agile, i.e. the perspective of their Agile teachers (Agile Coach, Agile Consultant etc.). Hence, it is understandable that the subject of Agile can be confusing for leaders, and unfortunately, many mistakes are made in relation to implementing Agile Transformations.

Pseudo-Agile Transformation vs Genuine Agile Transformation

To add further confusion to the subject of Agile, which has a major impact on the success of any Agile Transformation, is that in my opinion, there appear to be two different categories of Agile Transformation. To illustrate the two categories of Agile Transformation, it helps to examine them from the point of view of two specific types of change: ‘Transactional change’ and ‘Transformational change’. Drawing on the work of many change management gurus (e.g. Heifetz & Laurie, 1997; Anderson & Anderson Ackerman, 2001; Bass & Riggio, 2006) I have created a table (see Table 1) to summarise the differences in these specific types of change.

Table 1: Types of Change

Thus, using the descriptions in Table 1, it is evident that programmes that purely focus on the delivery of an Agile Process and other transactional change elements, are not actually transformations, which is why I refer to this type of Agile Transformation as a ‘Pseudo-Agile Transformation’

This viewpoint is strongly aligned with the thinking of Anderson & Anderson Ackerman (2001) who also contend that unless leadership mindset is addressed as part of the change initiative, then there will be little or no transformation at all.

In contrast, change initiatives that include addressing the organisation’s culture, the relationships and interactions of its people, their psychology, mindset, attitudes, beliefs and other transformational change elements, are more likely to be considered transformational. Hence, this is why I classify programmes which largely focus on these transformational change elements as ‘Genuine Agile Transformation’.

However, there are different views, among my contemporaries, regarding what is meant by culture change, and how it is approached. In my experience, their perception generally is that culture change is addressed by focusing on the transactional elements, e.g. processes and structures, and at the team level. Although I agree that this provides some culture change at the team level, it does not address culture at the higher levels, which is crucial to ensuring that the culture at the team level remains in place, post the Agile Transformation.

My view is that unless the ‘transformational change’elements are included, and at the highest levels in the organisation (i.e. leadership), then culture has not been addressed in its truest sense. In other words, for Organisational Agility to be a reality, and Genuine Agile Transformation to happen, transformational change needs to occur, and this will only take place when the organisational culture changes from the top down.

Pseudo-Agile Transformation – The conventional approach and why most Agile Transformations fail!

When organisations first experiment with Agile, they tend to focus on small teams within the IT department, on small pilot projects, using processes such as Scrum (https://www.scrum.org/resources/what-is-scrum). Once the software teams have experienced some success, the middle managers begin to get involved and will start to consider scaling the process to larger teams across multiple departments.

It is at this point middle managers often opt to bring in a number of Agile Consultants/Coaches to assist with implementing and running ‘Agile at Scale’. This is the conventional ‘bottom-up’ approach. This transition from small- to large-scale Agile is referred to by people in the industry as ‘Agile Transformation’, as mentioned. There are now a number of large-scale methodologies and frameworks that broadened the application of Agile, such as the Framework for Business Agility, LeSS, DaD, SAFe.

Although each of these methodologies provides some focus on the people element, this aspect is generally not given sufficient emphasis when being applied. Hence, culture change, and other transformational change elements previously described, are not addressed, and therefore I consider this conventional approach ‘Pseudo-Agile Transformation’. The focus with the conventional approach to Agile Transformation is to improve on what the IT or technology department is currently doing, in other words, the transactional change elements. But, as practitioners of Agile know, because Agile extends far beyond the confines of the IT department, for it to be effective, departments relying on Agile need to be more Agile.

In the context of the conventional approach, once the Agile Process has been delivered and the process manuals have been handed over by the Agile Consultants/Coaches to the Project Management Office, it is frequently perceived that the goal of Agile Transformation has been achieved. But, in reality, what the client is left with is an Agile Process, which staff frequently do not know how to use, even after training. This is another reason why I refer to this approach, which seems to focus on ‘processes and tools’ rather than ‘individuals and interactions’, as ‘Pseudo-Agile Transformation’.

It is ‘pseudo’ in that the transformation does not result in lasting change, and before long, those practising Agile revert back to how they were working in the past. In my view, this constitutes a failed transformation and, as has been recently pointed out in research by McKinsey (2017), a disproportionally large proportion (77%) of Agile Transformations fail.

The question then is, why is there such a high failure rate of Agile Transformations?

My hypothesis, as I have said, is that they fail because they are Pseudo-Agile Transformations, which focus on transactional change elements, rather than Genuine Agile Transformations, which emphasise transformational change elements. In addition, over the past fourteen years working in implementing Agile Transformations, I have identified a number of other key mistakes, some of which relate to the transactional change elements previously described, which I believe lead to the downfall of Agile Transformations. These key mistakes are:

1.   Lack of informed dialogue between leaders and senior managers, regarding Agile and its applicability in the organisation. This results in Agile not being sufficiently understood, leading to a loss of investment of time, money and effort, when an organisation discovers it was not ready for Agile.

2.   Agile Transformation not sponsored at the top (C-suite), which can lead to inter-departmental politics that block or obstruct collaboration. If delegated too far down the organisation, only partial benefits can be realised, due to organisational silos being re-inforced.

3.   The mindset of the managers entrusted with the transformation may be less Agile than is required for running such a complex change initiative. Mindset change is also conventionally focused on the teams, rather than the managers and senior leaders.

4.   Agile Transformation planned and run in a ‘Waterfall’ way (which can happen if run by managers with a more ‘Waterfall’ mindset.

5.   Agile Transformation focused on the team element only (to the exclusion of leaders and managers). Culture work is important and must not be relegated in favour of focus on process/tools delivery.

In other words, the conventional approach to Agile Transformation starts at the lowest levels of the organisation. The assumption is made that the focus of the Agile Transformation should be on delivering an Agile Process and training people in the process. This form of Agile Transformation, instead of being sponsored at the highest level in the organisation, is managed by middle managers, and it is perceived that these managers do not have to be that Agile themselves, but can instead ‘buy-in’ experts to train their people in the process – i.e. ‘do the change to others’. Consequently, although it may be perceived by some that an Agile Transformation has been implemented, what actually happens is that the transformations are planned and subsequently run in a non-Agile, or less than Agile, way. In other words, no genuine transformational change has occurred and thus it should be considered as a ‘Pseudo-Agile Transformation’.

Moreover, as culture is ignored or downplayed in favour of process delivery at the lower echelons of the organisation, resources tend to run out before there is time (or money) to focus on the critical layers to complete the transformation above the teams, i.e. the managers and leaders. Instead, when the Agile Coaches and Consultants move on, they leave with the existing non-Agile Culture in place. Consequently, the Agile Process cannot be sustained effectively, as it needs an Agile Culture to support it and thus no real lasting transformation occurs, and vast sums of money are needlessly wasted.

While it is possible to deliver a new IT process without complete Organisational Agility, it will be less effective and will deliver significantly fewer benefits to the business. In short, there is a high dependence on Organisational Agility for the Agile Process to be successful. The organisation may start out delivering a shiny new process but, at some point, someone will need to address key impediments that block the way of the process being effectively and appropriately deployed.

Hence, the high failure rate of Agile Transformations.

A combined Waterfall and Agile Transformation – another reason why Transformations fail

Over the years implementing transformations, I have observed another reason why Agile Transformations fail, which is worthy of mention. It is the case that implementing the conventional approach to Agile Transformations described, which starts at the bottom of the organisation within the IT department, and rarely rises any higher than the middle managers in IT, can, in the short term, bring some levels of success with regard to implementing an Agile Process.

In the short term, the software teams, and their direct line managers, can report success, such as improvements in effectiveness in delivering software and more value to their business customer in a shorter space of time, for example. But at this point, these benefits are limited to within the IT department and the business department utilising the services of IT.

At the same time, Waterfall continues to be implemented from the top down, and so effectively there are two processes running in parallel: the existing Waterfall Process and the newer Agile Process at the bottom of the organisation. This combination of a Waterfall and an Agile Transformation is often referred to as ‘WAgile’! In this instance, the change initiative is sponsored by the middle managers who enforce the change on those below them in the hierarchy. Moreover, Waterfall is both a command-and-control and predict-and-control process (Laloux, 2014) It requires power and authority to be granted from above, so that the middle managers can control the outcomes of the Waterfall Process.

Hence, the Waterfall way of working is in total contrast to the Agile way, where teams decide what needs to be done, not the managers. Additionally, Agile requires a collaborative culture which relies on teams being able to adapt to the emerging environment of the customer, and not a command-and-control culture. Consequently, because the middle managers in this instance have the power, their culture prevails. As a result of this, the Agility of the teams is compromised because the will and authority of the managers drives the direction of change – or ‘non-change’ in this instance.

Ultimately, the software teams resist the change being done to them, in the same way that the managers resist having the Agile change imposed on them. Subsequently, the benefits experienced by the IT teams, who had been doing Agile, are short lived. In addition, the software teams then feel resentful about this situation and so they become counter-productive, and what is even worse, is that in my experience, the level of Agility actually decreases. In other words, when Waterfall and Agile, two contrasting and conflicting processes, collide it causes major problems for the organisation (see mistake number four). This results in what we in the industry refer to as a ‘cluster-****’! Because of the extent of the damage that results in this fallout situation, much time, money and effort are wasted that could have been put to better use, by implementing Genuine Agile Transformation instead.

Agile Transformation – a new strategy

The conventional approach to Agile Transformation previously described is, nonetheless, very appealing to today’s busy leaders. They are attracted to the fact that having an Agile Process delivered in an organisation is easy, simple and relatively quick to do. They are able to hire others to deliver the process to those in the lower levels of the organisation, who then have the responsibility to change their behaviours to the ‘Agile way’, leaving senior leaders free to continue with the many other important tasks of running the organisation they are in charge of. However, although this may be effective in the short term, because transformational change at the important and appropriate levels has not occurred, not only is it a waste of valuable resources, it also commonly creates even more problems for the organisation, as previously explained. Therefore, a radical new approach to Agile Transformation, that is Genuine Agile Transformation, is needed – hence my new strategy.

In contrast to the old method, the strategy that I propose in this book turns the conventional approach completely on its head, with its top-down strategy, which starts with the most senior leader(s). This strategy involves helping senior leaders to understand in detail, right from the start, why the proposed change initiative requires not only their focus and attention, but also their sponsorship and ownership for it to succeed.

It addresses the erroneous assumption that the focus of the Agile Transformation should be on delivering an Agile Process and training people in that process. Instead, this new strategy focuses on educating leaders not only about transactional change elements (i.e. the Agile Process), but also, and more importantly, the transformational change elements, including the organisation’s culture, leadership, psychology, mindset and so on.

In addition to providing them with the knowledge senior leaders need to implement Agile Transformation, this strategy also helps them to transform themselves, to change to a more Agile Mindset and leadership style in order to support the Agile Process and run the Agile Transformation in the most effective way. Consequently, because this new strategy involves the leaders actually changing their mindset and behaviours – to have Agile thinking, and to behave in an Agile manner – the transformation is then planned and actually run in an Agile way, in contrast to the conventional approach.

This new approach focuses on how to change an organisation’s culture to support an Agile Process. To do this effectively, all layers of the organisation, starting with leadership, must be included. If senior leaders do not take responsibility for the Agile Transformation themselves, then there is little chance that Organisational Agility (Agile Culture), will ‘gain traction’, as it is referred to. This strategy is a truly top-down approach, with organisational leaders leading the culture change, as discussed. Although this may appear to be a radical and revolutionary strategy in the field of Agile Transformation, it is what the classical change management texts (e.g. Kotter, 1996; Schein, 1987, 2004; Argyris, 2010) have always advocated.

Another benefit with this new strategy is that, as it includes not only transactional change elements, but also a major focus on transformational change elements, particularly leadership and culture, leaders avoid the previously mentioned mistakes associated with failed transformations. These transformational change elements are what I consider to be some of the missing elements required for successful (and genuine) Agile Transformation, hence they form an essential part of the model I have devised with this new strategy (see Figure 3). In addition, when the Agile Transformation is completed, following this new top-down strategy, because the Agile Culture will have been put in place to effectively sustain and support it, the Agile Process remains and evolves. Thus, ‘Genuine Agile Transformation’ is implemented and given the optimal chance of success.

Five-step Pre-Tx model – A new strategy continued … Overview of the model

What I present in this book, and how I devised the Pre-Tx model, relate to my particular perspective on Agile and Agile Transformations, a perspective that I have developed from both my technology background, and my training in psychological methods. Over the years, I have been heavily influenced by my work with the Agile Business Consortium (previously known as the DSDM Consortium), applying the Agile Manifesto (Figure 1) in its truest sense, or purest form, particularly with regard to the aspect of ‘Individuals and Interactions over Processes and Tools’, as will become apparent in this book.

While I recognise that all methods and frameworks have both their strengths and their weaknesses, over the years of implementing Agile Transformations, and having worked closely with the Agile Business Consortium, I have often used their DSDM framework (Figure 2). The DSDM Handbook (to which I contributed) identifies a critical phase, referred to as the pre-project phase. This quote from the DSDM Handbook, emphasises the importance of starting right:

“The pre-project phase ensures that only the right projects are started, and that they are set up correctly, based on a clearly defined objective.” (DSDM Ltd, 2014. p37).

In using the DSDM process over the years, I have observed that, regarding running projects, only a small amount of time needs to be spent on the pre-project phase. Also, practitioners of DSDM have what is known as a ‘Project Approach Questionnaire’ (PAQ) to ensure that their projects start right and with the right amount of Agility, to ensure their success.

While this may be sufficient for running projects, achieving culture change is much more complex. Therefore, I believe it requires a much more significant amount of time and attention, and not just a PAQ, during the pre-project phase, to achieve successful culture change. 

Figure 2: DSDM model

Hence, the Pre-Tx model is designed to ensure that sufficient focus is given to this important early phase of culture change programmes, to ensure they start right! 

The Pre-Tx model includes the critical missing factors of Agile Transformation in the form of five essential straightforward steps, over a 90-day period. It helps senior leaders answer a number of important questions which are crucial to starting an Agile Transformation correctly, including what type of Agile the organisation needs at this stage, and how Agile the organisation is already. The model also provides leaders with a template for facilitating culture change in their organisation, with the assistance of a Trusted Agile Advisor (TAA) (see Genuine Agile Transformation – The need for a different type of Agile Consultant).

At the end of the 90-day period, leaders will be more informed about such things as the different types of Agility, Pseudo-Agile Transformation, Genuine Agile Transformation, and what Organisational Agility will realistically mean for their organisation.

Consequently, the model enables leaders to be in a position to make a fully informed decision regarding Agile, and to decide if Agile is appropriate for their organisation. They will also be in a position to know if it is more appropriate to postpone the Agile Transformation. Either decision has the potential to save the leaders time and money, compared with embarking on an Agile Transformation without this Pre-Transformation work.

Figure 3: Summary of the Pre-Tx model for Agile Transformations

Summary of the five steps

The first step is running an ‘Agile Leadership 101’, which gives leaders a basic grounding in Agile and includes addressing the questions of Why Agile? and What type of Agile is best for the organisation? This leads on to further discussions that educate the leader in the practicalities and nuances of Organisational Agility, as opposed to just running an Agile Process in the IT department.

Also, the Agile Leadership 101 provides leaders with an opportunity to confirm their understanding of Agile Transformations or to correct any possible misperceptions they may have pertaining to Agile which negatively affect Agile Transformations.

The topics covered in the discussions facilitated by the TAA in Agile Leadership 101 (step one) are subsequently used in step two to set the parameters for the assessments that the TAA then carries out. The results of the organisational assessments, or ‘Agile health checks’ as I call them, enable leaders to discover how Agile their organisation is. They are subsequently able to identify the areas of the organisation that are the most Agile and those that are the least Agile, in addition to identifying what the potential blocks to Organisational Agility will be.

Once the assessment data and results have been shared with the senior leadership team, leaders can proceed to step three, a two-day Agile boot camp. The aim of this step is to help leaders deepen their knowledge of Agile (following the Agile 101) and know how to design and deliver an Agile Transformation. The Agile Leadership boot camp also immerses leaders in Agile Leadership behaviours and thinking, enabling them to fast-track their Agile Mindset and behaviour, all in advance of initiating an Agile Transformation. It also helps them to apply their Agile knowledge practically in their own organisation, whether or not they decide to continue to pursue a full Agile Transformation.

The fourth step involves the leaders and the TAA working together to carry out a Co-Diagnosis of the organisational issues that may prevent Agile from being adopted throughout the organisation. Additionally, in step four, leaders build on the knowledge gained in the Agile Leadership boot camp, by experimenting with Agile as they carry out their business-as-usual activities, using Agile thinking and behaving.

In the final step, the leaders use the outputs from step four, along with outputs from the other previous steps, to create a Co-Design, assisted by the TAA, for the Agile Transformation. The leaders are subsequently provided with several options at the end of step five and the Pre-Tx model, and are assisted by the TAA to make an informed decision regarding proceeding with their Agile Transformation.

Genuine Agile Transformation – The need for a different type of Agile Consultant  

This new top-down strategy that I describe as ‘Genuine Agile Transformation’, which contains the Pre-Tx model, requires a different type of Agile Consultant/Coach, to the conventional approach. Therefore, I have devised a new external role which I refer to as the Trusted Agile Advisor (TAA). The TAA is a person independent of the organisation, hired to oversee and facilitate the implementation of this new strategy, and ultimately to facilitate Organisational Agility.

Although using numerous Agile Consultants and Agile Coaches to implement and run a transactional change initiative to deliver Agile can be effective, as this excludes culture change, the Agile Process cannot be sustained effectively as previously explained. Hence, this new strategy requires only one principal Agile Consultant during the delivery of the Pre-Tx model in this Pre-Transformation Phase. The TAA is skilled and experienced in facilitating both transactional change but also transformational change and working at the Executive Team level. This is because many leaders starting an Agile Transformation will not have implemented such a change initiative before, or be experienced in running an Agile Organisation. Hence, the TAA’s role is to help the senior leaders to start their Agile Transformations right. They do this by assisting the senior leaders to lead and implement the Agile Transformation themselves, from the top down, and using the Pre-Tx model. This is in contrast to the conventional approach, with the work normally delegated to the Agile Consultants/Coaches, who do the job on behalf of the leaders (or on behalf of the senior managers) from the bottom up.

The principal role that the TAA carries out is that of Senior Agile Consultant to the Executive Team. This is a different model of consulting to the traditional consulting model and this is because of the type of change that Genuine Agile Transformation involves. Consequently, the TAA Senior Consultant does not act as a traditional consultant in the ‘doctor–patient’ sense but is instead a practitioner of the Process Consultation model (Schein, 1969). It is unfortunate that Schein has used this particular name for his model, because it is easy to confuse it with the Agile Process, but it is not that! Schein’s model refers to ‘human process’, such as how people interact day to day. Hence, ‘Process consultation’ is very different from the standard or typical models of consulting as practised by the large consultancies. It works on the basis of a very different set of assumptions, such as that consultants cannot ‘do the change’ on behalf of their clients, and the consultant is not there to be an additional pair of hands (Schein, 1969).

Therefore, the TAA offers the Executive Team advice on the culture change programme, including how they need to respond in an Agile way to the emerging business environment during this Pre-Transformation Phase (and throughout the transformation). They also help leaders to co-diagnose the organisation’s problems and challenges, and to identify whether Agile is or is not the best solution to those problems (step five). The TAA is also there to provide an objective and safe sounding board and to be the ‘Agile good conscience’ for leaders during the challenges of Agile Transformation. Hence, they do this by carrying out a number of different roles, in addition to their principal role of Senior Agile Consultant.

These additional roles include Executive Agile Coach to the Executive Team, helping them with the learning involved at the Pre-Transformation stage and, as the transformation progresses, they facilitate the team’s Agile Leadership Development on a more formal basis. The TAA is also a Mentor to the Executive Team as they tackle working in an Agile way, because the TAA is experienced in implementing Agile Process and facilitating Organisational Agility culture change. In addition, they carry out the role of Educator to the Executive Team regarding how to start, and then successfully drive, an Agile Transformation. The education continues during the transformation but typically forms part of the executive Agile Leadership Development programme. The TAA is also a Facilitator for the discussions and workshops that emerge as part of the overall programme of culture change. Moreover, the TAA only provides these roles to the Executive Team/C-suite. They do not coach or consult with anybody else in the organisation, in order to avoid any conflicts of interest throughout the Agile Transformation.

Unlike with the conventional approach to Agile Transformation, whereby the Agile Coaches/Consultants often work full-time in the organisation for a specific period of time, the TAA’s role is part-time, except during the running of the organisational health checks (see step two). The most intensive use of the TAA will be during the first 90 days, when the Executive Team works closely with the TAA to create the initial roadmap for the transformation.

To be able to carry out these roles effectively, particularly with regard to assisting senior leaders to lead an Agile Transformation, the TAA has to meet a number of specific criteria. They have to have an Agile Mindset, be experienced in facilitating psychological change at the senior level, have some business awareness and be independent of and non-attached to any particular Agile method. For further details regarding these requirements, along with a TAA criteria checklist to assist leaders in their search for a TAA and details on how to best utilise the TAA post the Pre-Tx model, see http://www.theagileleader.co.uk/Pre-Tx

Thanks for reading … if you would like to know more then please help me to retire sooner by buying a copy for you and all of your team! Just click here to buy full copy for your digital device. Paperback copy coming soon.