Why agile fails - even when it doesn’t look that way

Why agile fails

The first is that your attempts at working in an agile way fail, either right away or are abandoned after a short time.
The second is that they are adopted and represented incorrectly from the beginning.

Just as a pillar of agile is avoiding risk, knowing these potential obstacles to agile can help avoid getting stuck on them. We’ll outline the ways that agile adoption can fail, and how you can prevent that from happening. We also will explain how to identify the agile imposters among us.

Why your attempt at agile failed

Despite what feels like comprehensive planning and training, becoming agile doesn’t always work out. What are some of the reasons why (and how can they be avoided)?

You don’t know why you’re doing it

Or you’re doing it to feel cutting-edge.
Changing processes just to change throws new, potentially unnecessary challenges into your organization. Not all teams or projects require using Scrum or other agile methodology. It might sound modern and cool to say you’re adopting agile practices, or it seems like everyone else is doing it, but if your whole team doesn’t understand why you are working this way, the real value won’t be achieved.

Before implementing a change to agile, make sure that there is a clear definition of what success will look like, so that you can set goals and measure progress. All stakeholders must understand this as well, as well as the reason for implementing agile, and what that really means.

Your team doesn’t fully understand it

It’s easy enough to learn some terminology and set up some meetings. That doesn’t mean that your team really understands the values behind the vocabulary. If team members are resisting the change, maybe because they feel it’s changing their status or simply wasting their time, they are likely to use these words without really changing their practices.

To avoid this, proper training must be provided to everyone involved before making and major changes. Continued training is also wise, as the team’s appreciation and understanding will deepen with more experience. Bringing in an experienced key players, like a scrum master, can also help keep the team on track. The appropriate infrastructure must be set, and respected--but don’t forget that moving towards an agile way of working is a cultural shift. It’s also important to monitor before and during periods of change to make sure that the needs of the team are being met.

Your product or organization doesn’t support it

A main feature of agile is frequent deliverables and regular feedback and adjustment. Sometimes it simply doesn’t make sense to break a project down into 1-2 weekly sprints, each ending with some kind of finished component. Users or management may not want to work with unfinished products, as agile requires. Factors beyond the team that are not adaptable to agile methods are significant obstacles to the success of a project.

Make sure that all stakeholders are ready to work the way needed. This includes, the user, client, management, and decision-makers outside of the project team or department. In the case of working with Scrum, having a knowledgeable, experienced Product Owner on the project is important, as this person can direct the project, guide the team, and help external stakeholders align with the needed way of working.

Why your agile isn’t actually agile

Another more difficult to spot scenario where agile fails is when it’s not really agile it all. You may talk the agile talk, but the walk is another story. Plenty of elements can seep through your agile processes, undermining the value. Make sure your practice really is agile, and not a more rigid framework in agile clothing. These are some things to look out for.

Your meetings are a mess

One common practice for agile teams is daily stand-ups. These brief catch-up meetings are meant to share 3 things, and 3 things only: what got done yesterday, what will be done today, and any obstacles to progress. All too often stand-ups turn into proposals, brainstorms, chat sessions, or decision-making that run two or ten times as long as they should. Another meeting mistake is the failure to hold regular retrospectives. As agile teams self-organize, it’s important that they regularly assess feedback and tweak how they work, and retrospective meetings a scheduled time to make sure that the team is always running efficiently.

Your feedback is not being used (or even collected)

A common mistake in planning the scope of a project and budgeting it is to leave out resources for getting and implementing customer or user feedback. This is a critical part of agile processes--there needs to be not only a clear protocol for routinely soliciting feedback, but also infrastructure to assess and adapt to it. Without implementing changes due to feedback, collecting it is useless. Without collecting feedback, there is a very high level of risk that the final product is not what the user really needs.

Your stories are getting lost

User stories are a key tool in agile, and are a great way to understand the functions and features for their benefit to the user. They are not, however, an objective or a to-do list. A user story can’t be partially complete, like a task list. Another pitfall is thinking of user stories as the measure of success, when the focus should be on what working deliverables have been completed and the total value.

The common remedy for avoiding these failed situations is thorough planning, comprehensive training, and counting on experts. Agile is a mindset, and set of values, which are interpreted into processes--and adopting a new mindset isn’t easy.