Resistance to agile working: Why people are resisting moves to agile

Resistance to agile working: Why people are resisting moves to agile

Resistance to agile

Resistance to agile. A new piece of research into changes in methodology of software development has highlighted many of the problems that are faced in nearly every change programme in organisations. Resistance to agile working is an increasing phenomenon as the agile methodology spreads out of the software industry.



Resistance to agile working

Resistance to agile working

 

Resistance to agile working

 

‘Agile software development’ is a relatively new but firmly embedded approach to software development that is focused on working with customer needs rather than a project completion centric ‘traditional approach’. As with nearly every organisational change programme, this shift from what used to be a project completion mentality to agile working appears to be facing increasing levels of resistance from a number of more established software development teams and companies.

 

Be impressively well-informed

Get your FREE organizational and people development research briefings, infographics, video research briefings, a free copy of The Oxford Review and more...

Powered by ConvertKit

 

Likewise reports of resistance in organisations to agile working in organisations appears to mirror the resistance emerging in the software industry. We will look briefly as to what agile is and then look at the major issues raised in the large scale study.

 

What is The Agile approach?

 

Agile

Agile methodology

 

 

Test – build – change

In short, the agile approach to software development and project management help teams respond to customer needs and wants through incremental, iterative releases of pieces of work, known as sprints. They then gather feedback direct from the customer for the next sprint. In this way the work is both  responsive and innovative at the same time, based on a ‘build-test-change’ approach where early releases are tested and retested with the customer as the software or product develops. This is opposed to the traditional method of waiting to release a product until it is the finished article. .

 

Agile means build the basic working product and release it as soon as possible. Get feedback fast, change the product based on the feedback and release again and so on. The product development is done live with the customers in short iterative bursts. It is all based on getting feedback, swift action, change and release. It also means that you will necessarily fail at points.

Fail fast

The trick is to fail fast and learn. In agile failure is feedback and nothing else.

 

Agile methodology

Agile methodology

 

The 12 Principles of the Agile Manifesto

 

Looking at The 12 Principles of the Agile Manifesto for software development is instructive when trying to understand agile approaches:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility
  10. Simplicity–the art of maximising the amount of work not done–is essential.
  11. The best architectures, requirements and designs emerge from self-organising teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Resistance to agile

 

Resistance

Resistance to agile

 

The study, published in the Journal ‘Computers in Human Behaviour’, looked at how change to the new approach was being received and acted upon by software developers, their teams and companies around the world. The first thing the researchers found was: “Data analysis … showed that human-related challenges play a significant negative in moving to Agile”. In short, resistance to change is a significant hurdle to achieving agile working practices.

 

The 5 principle causes of resistance to agile

 

The researchers found the following five issues among software developers and their teams:

 

1.    Lack of understanding of the process and its principles caused resistance. If you don’t understand a concept, then you’re less likely to warm to it. Part of this is not having seen the process in action before.

2.    Cultural issues. The longer a team or organisation have been embedded in traditional and more sequential working practices the harder it often is to shift the thinking to agile thinking. This shift means changing cultural values around failure, success, being right, being open to challenge etc.

3.    Generic resistance to change. Fear of the unknown and in particular a fear of making mistakes causes resistance. This was a significant challenge where the teams and individuals considered they had expertise in the old systems of working. The move to agile challenges the status quo of the previous knowledge hierarchy.

4.    A certainty mind-set and failure adversity. This can be best summed up as logical sequential and complete thinking v ‘get it out there, test and learn’ thinking. This requires small but fast iterations and direct and near to instant responsive behaviour and the ability to pivot and change direction if needs be.

5.    Lack of effective collaboration. Agile approaches requires an internal collaborative approach at all levels that focuses on problem solving rather than political manoeuvring, status building and ‘being right’.

 

Editor’s Note

Whilst this paper is focused on the challenges of shifting software development teams and organisations into agile working, it is quite easy to see the close parallels in organisations moving towards more agile approaches. As more and more organisations embrace agile approaches, there are growing of resistance to agile in many organisations.

Being aware of the resistance to moves towards agile working and, more important, being able to break it down, analyse and understand what is behind resistance to agile working is a really important step in being able to address it.

 

Reference – available to members

Had a Difficult or Painful Change Programme? The Next One May be Worse

 

Be impressively well informed

Get the very latest research intelligence briefings, video research briefings, infographics and more sent direct to you as they are published

Be the most impressively well-informed and up-to-date person around...

Powered by ConvertKit
Like what you see? Help us spread the word

David Wilkinson

David Wilkinson is the Editor-in-Chief of the Oxford Review. He is also acknowledged to be one of the world's leading experts in dealing with ambiguity and uncertainty and developing emotional resilience. David teaches and conducts research at a number of universities including the University of Oxford, Medical Sciences Division, Cardiff University, Oxford Brookes University School of Business and many more. He has worked with many organisations as a consultant and executive coach including Schroders, where he coaches and runs their leadership and management programmes, Royal Mail, Aimia, Hyundai, The RAF, The Pentagon, the governments of the UK, US, Saudi, Oman and the Yemen for example. In 2010 he developed the world's first and only model and programme for developing emotional resilience across entire populations and organisations which has since become known as the Fear to Flow model which is the subject of his next book. In 2012 he drove a 1973 VW across six countries in Southern Africa whilst collecting money for charity and conducting on the ground charity work including developing emotional literature in children and orphans in Africa and a number of other activities. He is the author of The Ambiguity Advanatage: What great leaders are great at, published by Palgrave Macmillian. See more: About: About David Wikipedia: David's Wikipedia Page

  • Agile is not in the slightest bit new. The Agile manifesto is from 2002 but the core of the Agile techniques or variations date back to the 1990s. At least in banking IT there was a huge Agile movement from the the early to mid-2000s onwards. Agile (at least claiming to Agile) has been predominant form of software methodology for several years now. What is really surprising is that there seems to have been a second Agile boom over the couple of years and so many people, particularly the under thirties seem to think this is “new”. There also seems to have been an expansion of Agile out of core software development into other areas of organisational change. You can see this in Google Trends where searches for Agile petered off towards the end of the last decade and then started growing again over the few years.

    One of the other key problems with this article is the one of definition. Even going back to the Agile Manifesto, a well run waterfall type project could fit within the generally quite vague defintion. Part of this was because even then, there were so many competing schools of Agile, it was hard to reconcile them with any clarity. The article seems to assume that Agile is synonymous with just one of them, “Scrum”.

    The other is an implicit belief that “Agile”‘, however you define it is good. Any analysis really needs to define what type of agile you are talking about and critically assess the evidence for that variant. Another problem with assessing Agile in general (or specifically barriers to adoption) is implementation fidelity. It is fairly common for people today (especially compared to the more fundamentalist Agile boom of a decade ago) to be pragmatic in applying agile. This is very sensible on one hand but it makes the problem of definition and consequently the challenge of assessing the value or obstacles to implementation even harder.

  • >