8 Agile Mistakes that Are Killing Your Development Projects and How to Avoid Them

Often perceived as the holy grail of software development, Agile methodologies have revolutionized the way we develop software. But while for many companies the adoption of one of its varieties (Scrum, Kanban, Lean Development) has helped produce software more effectively, many companies not only haven’t seen any performance improvement, but actually believe Agile is doing them more harm than good. Usually, it has little to do with the Agile methodology itself but the result of abysmal implementation mistakes.

Considering that over two-thirds of companies reported using Agile [1] either full-time or in certain aspects of their project management, it becomes clear that these mistakes cost the industry billions of dollars every year. What are they? And how do you avoid them to ensure they don’t stifle your company?

1.Expecting Transformation Too Soon and Too Easy

This is for those who’re yet to implement the Agile methodology principles at their company. Unfortunately, merely implementing sprints is not enough. Quite often the initial stages are very hard for you and your team. For example, if you don’t know your team’s capability well, you’ll keep ending up with unfinished sprint tasks. This could quickly discourage team members from embracing the methodology.

What to do:

If you’ve implemented Agile but can’t see any improvement, look at other areas that might require adjustments. Implementing such a big change often requires overcoming problems with company culture; a lack of trust, for example. To help your team members with the transition, make sure that it’s always clear who should make the decisions [2] regarding each piece of the project.

Of course, the mentioned lack of trust and other problems won’t disappear overnight. Instead of trying to talk about the values or empty slogans alone, influence the habits and, thus, the behaviors and stories [3]. Make sure that people take priority over processes. Don’t manage – let the teams find solutions to the problem under the leadership of the managers. And, most importantly, don’t merely ask people how they can transform. Encourage them to experiment, try the new approach and ignore thoughts that tell them they can’t change their way of work.

A great thing that can help you speed up the transformation process is Scrum Studio [4] – a separate work environment (which can be created within an organization or exist as a physically separate one) which helps your employees focus and embrace Scrum and its values. Naturally, your IT or digital department is not the only one that should be involved – especially if you need a company-wide transformation. A great example of such Scrum Studio implementation is the KLM Digital Studio [5], where they invited 200 people from various departments, including Passenger Operations, Cargo, HR, and Finance to work closely together.

Read also: How to structure a scrum team?

2. Trying to Substitute Agile Principles with Tools

Tools can be very helpful regardless of what kind of project management system you choose. Unfortunately, the problem with tools is that they often overcomplicate the adoption and put too much focus on automating stuff and delivering fancy data instead of focusing on the individual members of the team.

What to do:

Ensure that your team members get proper training and understand the goals of the methodology before you introduce any fancy tools. As the focus should be on individuals and interactions, even stickers on the walls and simple spreadsheets can be more beneficial than complicated Agile software – especially if you want to keep things simple for the team.

3. Forcing the Scrum Master to Be the Project Manager

Many companies make the mistake of not differentiating between the Scrum master and the project manager or lead developer. Of course, in some cases that would work – however the role of the Scrum master is first and foremost to help the team members follow Agile principles. If they’re busy managing the team, they most likely won’t have enough time to offer guidance to the team or help the product owner.

What to do:

If you’re a manager, instead of picking someone yourself, let the team decide who should be the Scrum Master. Of course, such a person will need to have impeccable software production skills – but even more important will be their knowledge of the Agile environment and soft skills that’ll allow them to be a “guardian angel” of their team.

4. Separating Key Players

The emphasis Agile methodologies put on the team means that it can be hard to get the most out of your team members if they are spread around the world and working in different time zones.

Unfortunately, even the best communication software and tools won’t compensate the loss caused by time differences – it’s hard to work effectively if your team members are still sleeping while you’re trying to solve an important problem.

What to do:

Try your best to make sure that all your key team members are “onshore”. There’s nothing wrong with outsourcing software development offshore – just make sure that the companies that you choose have physical production locations in one place (just like Software Mind) and don’t spread their core teams between different branches.

5.Poor Estimation Habits

Even though they seem simple, estimations are one of the toughest and most stressful things for new team members. In the end, how are they supposed to know how much time certain tasks are going to take? Of course, it gets easier with time but regularly underestimating or overestimating the amount of time required to complete the work may severely impediment sprints.

Because of the high level of uncertainty in software projects, trying to estimate the time in plain hours is often pointless. Most of the time, the work takes at least the estimated time; quickly leading to delays and breaking the whole schedule.

What to do:

The psychology of planning shows that team members often estimate the duration of projects much better using relative than absolute estimation [6]. That’s why instead of trying to estimate an hourly value of the work required, it’s better to compare the items or group them based on their difficulty and complexity.

Similarly, relative values are important when working with story points. While you should assign raw points to each story based on its complexity, the absolute values are not as important as the relative ones – thus a story that got assigned 4 points should take twice as much (or be twice as complex) as the one that got just two points.

6. Wrong Product Backlog Idea

Product backlog is one of the key elements in Agile product development. If it’s not prepared properly, it can lead to ongoing sprint failures and significantly demotivate your team. The most common mistakes include running out of work to do or focusing on work that doesn’t bring too much to the table when there are other, more important (but incorrectly prioritized) tasks waiting.

What to do:

Make sure that the tasks in the backlog get prioritized by someone who knows how to do that most effectively. Usually, this will be your product owner but don’t focus on strict roles – especially if there are people who are closer to the “customer” and can come up with better user stories.

Similarly, if your product owner is new to the job, they’ll most definitely need help. More experienced team members will need to show them the way (and even hand-hold them) in the very beginning so that they learn how to properly estimate and prioritize the tasks; thereby setting the right expectations from the team in a given sprint.

7. Not Asking Users for Feedback

We all know it’d be best if we could just magically develop the exact software our users expect from us right off the bat – with no changes, adjustments or feedback on the milestones. Unfortunately, not discussing your project often enough with its future users is not only irresponsible but can cost you thousands of dollars in failed development – especially if you end up with a piece of software no one wants to buy.

What to do:

Publish your software as soon as new features can be tested. That way you can get feedback just in time to implement any necessary changes, before you get to a point where turning back could turn too costly for you or your client.

8. Focusing too much on Meetings – and Hoping They’ll Solve All Your Problems

The last one is probably the biggest killer of all Agile teams. Whether we talk about backlog refinements or post-sprint meetings, the sole fact that you invite all team members to discuss your project doesn’t make you a successful Agile team. No matter how hard you or your project managers want you to believe that.

What to do:

If all you do is meetings, start with implementing other principles of the Agile Manifesto [7]. But if you think that you and your team have laid the foundations but can’t figure out what to do with the meetings themselves, you either need to change their plan or reduce their frequency. While they are one of the principles too, each of those meetings should be focused on reviewing the progress and helping you move the project forward. Leave discussing company politics and gossiping for another time.