In this blog Steve Ingall, Head of Business Services at iCore Ltd shares some of his observations of what has not gone as well as expected in programmes introducing Agile.
5 Main Failings
There are different approaches to introducing and embedding agile ways of working. These are dependent on how you work today (covering people, processes and technology) but it is essential to have a strategy to direct how you are going to approach this opportunity.
I have been involved in a number of programmes to introduce Agile and written several papers on how to go about this so this time I thought I would share the characteristics of some troublesome journeys in introducing and embedding Agile.
#1 Uncoordinated Introduction of Agile
In organisations where there are several independently operating development teams, I have seen each of these teams also take an independent approach to Agile. This has led to different definitions (and naming conventions) of Product Centres and disparate use of tools, which in turn leads to multiple licences and inefficient buying.
A concerning aspect has been that instead of the various Product Centres becoming more collaborative they have actually become adversarial. There have been different approaches taken to key roles, e.g. Product Owner. This disparate approach has a knock-on impact on the Infrastructure and Service Management operations who are now trying to service many different modes of working, which is just a Lose:Lose situation.
#2 Not Ready for Change
Through a lack of strategic oversight there is also a lack of planning and readiness for both the Business and the IT Department. I recall the phrase “To fail to prepare is to prepare to fail!”
Simplistically this often shows itself with more non—standard requests coming in from development teams; more demands for self-managed environments and administrator/super-user access; development teams by-passing the traditional Service Management processes to release code and add user accounts to systems. I have even seen development teams developing in the PROD environment or leaving back-doors in to their code to give them access if there is an issue. This might be ways of working that you want to allow, so existing policies and processes need to be adapted to accommodate this change.
There has been inadequate or unstructured communication, training or coaching and in one organisation I heard the classic “they want us to do Agile so lets put a Kanban board up”.
#3 Don’t Develop Hybrid Working Practices
Whilst I do think that moving to more agile ways of working is a necessity for organisations there are still IT services like corporate and large-scale packaged solutions that need to be kept running and for some of these services Agile may not be appropriate. I have seen organisations fail to include in their strategy how they are going to run this multi-mode operation and do not adapt when necessary.
Organisations that fail to adapt will fail to meet the increasing demands being placed upon them. Areas that I have seen IT Departments struggle with is around Change, Release, Configuration and Service Transition where:
- Stage Gates, Go/NoGo and ELS are just not Agile ways
- Not evaluating at the start of a Project whether Agile is appropriate leads to the wrong approach to Service Transition
- Making the use of Standard Changes difficult to utilise leads to unnecessary bureaucracy and delays in delivering value
- Building large releases that require system outages and lengthy testing phases does not deliver the flexibility the business needs
- Not embedding a Business ‘representative’ within the Agile team leads to slow and possibly inaccurate decision making
It is reasonable that large scale Infrastructure projects or major packed system upgrades will still require the rigor of a Waterfall approach, but I have seen some organisations who do not recognise the benefits of agile ways of working on smaller scale projects, e.g. introducing a new piece of software, trialling new solutions for computing and storage services.
#4 Fear of Losing Control
An area that I have observed some organisations often take time to come to grips with is that the different ways of working applies to Senior Management as well. Different organisational structures, different leadership styles, different relationships, different service reporting, and tackling matters that have been put off for years as “too hard”. Lets take them one at a time.
Organisational Structures
Many times I have seen a desire to move to a more centre of excellence (COE) or a community of practice concept and whilst organisations know this means breaking down organisational silos to enable cross-functional teams to work together, they struggle to agree the organisational model that allows this. It is further exacerbated when you think about the impact on the managers budgets. There are new roles and responsibilities to be agreed perhaps roles like Chief Digital Officer, Chief Data Officer, and what was described as an evolution suddenly starts to become a revolution.
Some work on what the Target Operating Model (TOM) will be should happen early in the programme. This also helps you to contextualise some of the changes for people based upon their role and specific environment.
Leadership
Failure to acknowledge that the changes needing to be made require a structured approach to Management of Change (MoC) has also led to poor communications and lack of direction. When the Business and the IT Department are going through this type of change they need leaders who understand what is required of them and they have the gravitas and support around them for people to believe this is the right way to go. Some Senior Managers do not have this ability and they should be used in areas where their strengths can be maximised.
There is a change in leadership and management required with Agile which I have seen some Senior Managers fail to grasp. Spotify talk about getting ‘Autonomy and Alignment’ where the people have autonomy to solve problems that have been defined by the business and aligned to the business needs.
“We need to get to the other side of the river” rather than “build a bridge here”
Relationships
The different ways of working needs a different relationship model, with less peer-to-peer relationships and more role-to-role relationships, which again some Senior Managers are not entirely comfortable with. Senior Managers need to start operating closer to the business than they probably do today, more in an Account Manager role working with BRM and SDM teams to better define demand and planning on how to achieve it. This in turn can remove tiers in the organisation and where this has not been addressed there are often several gaps and overlaps in how the IT Departments customer experience is managed.
In a cross-functional team everyone in the team has certain activities that they are accountable or responsible for and others where they are just consulted or informed, and indeed there are some activities that the role plays no part in. So the Business Owner role has certain RACI items to fulfil, the SCRUM Master role has other RACI items fulfil, the Developer, Service Management Broker, the Infrastructure Co-ordinator, the Security Advisor, etc … regardless of their grades in the organisation. Be clear on the RACI model.
Reporting
Managers often struggle with the need to report their services in a more business value manner. They know that the typical ‘Widgets’ IT Service Monthly Report that is produced is not giving them this information, however they do not know what to replace this with and in some cases I have seen the business do not know what to ask for either.
So be Agile. Start with something small and simple and discuss this with the business leaders to see if it works. Failing to demonstrate that you are accelerating the delivery of solutions that directly contribute to the success of the business is not sensible.
But don’t throw the baby out with the bathwater as they will still want to know about Major Incidents and Outages, Major Releases, Problems, Service Continuity Tests but they will want to know about outcomes expressed in business terms.
Example
The change introduced to address the problem with lost mobile signals has decreased the average time the Mobile Engineering team responds to emergency calls from 57mins to 52mins, which means we are now well within our regulatory obligation of 1 hour. A breach in this regulatory requirement costs the business £250k each month we breach.
To be able to achieve the agility required everything about the operation has to be reviewed (people, processes and technology) but this time with business value add in mind. I frequently tell those grappling with this new way of reporting to just add the phrase “which means that …” on the end of their current stats, so failure to hit an availability target means what to the business?
Too Hard?
Where the IT Department has been using good practice guidelines such as ITIL, TOGAF, and COBIT this has helped progress process improvement but no matter how efficient and effective things seem today IT needs to do more to make processes lean and increase automation. Senior Managers continue to be bothered about things they should not need to be bothered about. They need to focus on what is ‘Above the Line’ and stop looking at things ‘Below the Line’.
Where organisations have had years of sweating assets they must address matters around technical debt and obsolescence or have a strategy and plan to ‘re-platform’ using Virtualisation, Cloud or ‘… as a Service’ offerings. This is also an opportunity to look at the sourcing strategy for the IT Department and again where this has not been done then a very muddled SIAM model has developed.
Where the in-house staff have not been given the skills for the future, have not been able to see an attractive career path or are simply in a mundane, repetitive role there has been considerable resistance to change (even sabotage) and/or high staff turnover. The teams need to be built with collaboration in mind, where they are more empowered and trusted to ‘do the right thing’, have the tools and environment to get things done, and not be slowed down by now meaningless activities. Everything needs to be looked at to identify the ‘Minimal Viable X’ where X is ‘Product’, ‘Change’ ‘Bureaucracy’, ‘Documentation’, etc…
#5 Go it Alone
Whilst there is no hard and fast manual for Agile (or agility) there are many organisations that are well advanced in adopting these ways of working and often they are more than willing to talk about their experience. There are also several good YouTube articles and of course there are consultancies who are able to provide pragmatic assistance with planning, building (or adapting) and embedding the new ways of working / practices.
Conclusion
It is often through the mistakes of others that we can learn what our own path should be to introduce Agile and more agile ways of working. Hopefully this paper will help you to avoid some of the areas I have observed in other organisations.
If you would like to find out how iCore can help you with your Agile journey then please contact us on 0207 868 2405 or email info@icore-ltd.com