Agile Fails! 6 Most Common Reasons Stating Why - Innovify

Agile Fails! 6 Most Common Reasons Stating Why

October 20, 2015

Agile Fails! 6 Most Common Reasons Stating Why

IN Blogs


Many points should be considered while you transform any software development process into an Agile process; like team chemistry, team engagement, strong team maturity, communication, trust, top management support, continuous learning, and the list is countless. Listed are the most common points that make Agile a failure.

1. Unbalanced Team

The role of a ScrumMaster: He involves himself in removing impediments that the development team might face, coaches the product owner & stakeholders, and keeps the development team away from all distractions. ScrumMasters should not dictate the team or micro-manage them. This may damage the team morale, create a lack of trust & also prevent the team from achieving their goals innovatively.

Opposite scenario is where the ScrumMaster is disengaged or uninvolved. In this situation, the person may only attend meetings, which leaves him clueless or unaware of what the team is doing.

The role of a Product Owner: This one is an important role. But due to lack of decision-making authority, training, & clarity, they don’t really understand the values and principles of the Agile process. This adversely affects the team.

The role of the Agile Team: Generally there are strong barriers between Dev and QA team members. There are conflicts between defect vs. improvement, defect logging process, providing stories to test at last moment etc. Teams should be self-managed & united with a clarity of ultimate goal i.e., successful sprint delivery.

Secondly, an understanding that everyone’s time is precious, the Dev team must deliver stories to QA team in a predictable manner which should be informed in daily scrum meetings.

2. Teamwork is not natural – it should be a continuous learning process

A team should constantly focus on how they work, making sure that stories get done, & on how processes can be improved. In general, people don’t get continuous training for this, & it is just assumed that the average developer can do it ‘naturally’ or training the team only once will give them an Agile mindset.

There is a giant leap from coding to owning the product development process. The team requires maturity & awareness of responsibilities. Some people just don’t care enough about how they contribute to an agile team – no matter how good they are at development.

3. Inadequate trust & communication

Trust: Fear’s mortal enemy is trust. A common example of fear stifling team growth is the issue of commitment. Teams often under commit or pad their estimates, due to fear of being responsible or blamed for failure. Initially, allow the team to give themselves permission to miss their estimations. Foster an environment of trust, such that the team can explore the causes of a miss without blaming. This helps you find the true upper limit of velocity. A single miss will translate into dozens of future successes.

Communication: If team members don’t talk to each other regularly, troubles lie ahead. Even with the most meticulous documentation, the best way to discover issues and blockers is through face-to-face communication. Foster collaboration by setting up a dedicated team area, where all team members work within reach of each other. Use video conference and instant messenger software to create a virtual room for global teams.


4. Gaps in planning & estimation

Some believe there is little or no planning with Agile. In fact, there is detailed planning. The difference with Agile is that planning is ongoing instead of a one-time event that gets signed off at the beginning of the development cycle, which occurs at varying levels of complexity and granularity.

Some teams relate user story points to actual working hours. Avoid this mistake! Use abstract values such as t-shirt sizes, animals, colors, or points to represent the size of new work. This is important.

Abstraction helps in tracking the complexity of the story instead of an individual’s availability. Point estimation reflects the abilities of the team as a whole. Once user stories are sized and committed for iteration, individual capacity comes into play in the form of hourly task estimates.


5. Inadequate testing

Agile isn’t about delivering software faster; it’s about delivering quality working software faster. The product owner shouldn’t accept completed work until it has been tested and meets the team’s definition of done along with the acceptance criteria. One way to combat poor testing habits is to place an emphasis on developing automatic testing. Test every single build until it passes. You may believe testing is done last, after developers complete coding. That is not so!  With testers sitting on the cross-functional team, testing should be done simultaneously. After iteration planning, the requirements of the user story are known. Start building tests against the value the stories provide so that they may be verified as soon as the code is ready. This removes a potential bottleneck.

6. Insufficient support from management

Management’s support for Agile development is very crucial when there’s a lack of it, it becomes  a common cause of software project failures. Management is sometimes surprised or unprepared for things to slow down as teams learn Agile. It may take years, not months, to implement Agile development fully into an organisation.

Some senior managers think “Agile development is just a speed play. If we go Agile, we’ll get stuff done three times faster”. It has been observed that management’s focus on speeding up application releases without quality leads to heavy business losses. They must clearly understand technical debt — the accumulation of application flaws if the quality control does not occur. It’s important to be able to deliver software that provides value frequently and at a sustainable pace, means that speed takes second place to good QA practices that keep technical debt low; practices such as test-driven development, regression test automation etc. should be in use.

Agile transformation brings along with it organizational transformations. Agile requires change and continuous improvement, not just in development but also in all practices that touch products.

Command-and-control management styles do not work with Agile, they need to become facilitative in their approach to lead people. Openness, honesty and transparency in communication are the logical places to start.

thank you for

You're a step closer to
becoming an innovifier

We'll get in touch with you
as soon as possible.