For all the excitement we see around the adoption of agile methodologies, and the positive effect it can have on product delivery, there are some reports which show that companies are struggling with agile.
- In 2012, Voke conducted a survey of over 200 companies and found that 64% found their agile transition to be confusing, hard or slow, and 40% of the respondents couldn’t identify a single benefit from the transformation.
- In 2014, Ambysoft found that only 44% of respondents to a survey felt that their company’s agile transition had been a success.
Granted, those reports are a few years old and the numbers may have improved since then. Nevertheless, it’s clear that many companies are having a hard time making a successful change from a more traditional process to an agile one. No doubt there are other problems as well: one joke I’ve heard suggests that the three most common agile practices are:
- Calling things “agile”;
- Calling things “Scrum”;
- Installing JIRA.
From our experience here at ArgonDigital, and looking at the experience of others, there are a number of themes that seem to recur when looking at failed agile adoption. Some of these issues are found at the level of the individual team, while others are at a broader organizational level.
The major themes that seem to cause problems in agile adoption include the following:
Lack of understanding at the team level as to what exactly agile is and how a shift to being agile requires changes in roles, work habits, and most of all in mindset. Agile can be, and often is, presented as nothing more than doing the same old things but in small chunks and faster. If teams find themselves focused on delivering work to meet artificial deadlines, if they don’t shift to a focus on getting rapid feedback and adjusting course to respond to it, they can end up just building bad software faster.
Poor discipline and a lack of appropriate engineering practices can also lead to major agile failures. Without an ability to trace the delivery of an idea from concept to value realization, teams can’t tell if they are actually improving. Without real agile experience on a team, the shift to agile can be used as an excuse to dump activities that are critical to the delivery of a quality outcome. Retrospectives may not be used to inspect team practices and adapt them when needed.
Discomfort or resistance to change may also disrupt the transformation. Nobody likes to have change imposed on them and the change to agile may be seen as something driven from the top-down to cut costs or staff, especially staff who have roles that aren’t traditionally emphasized in agile development, like business analysts and project managers.
The larger organization may not be ready to support agile transformation and see it as a purely IT change. If the rest of the enterprise continues to operate in silos, can’t reach a consensus regarding priorities, and limits control to a few key decision-makers it will be impossible to make decisions at the pace and cadence required for a successful agile team. Without a clear commitment to agile from the leadership team, there’s no reason to expect the rest of the staff to make the journey.
Of course, there’s always other possibilities. Maybe agile really doesn’t meet the needs of your company, for example. However, if you are really looking to move to agile, and it’s not happening for some reason, it’s likely due to one (or many) of the factors above.
