After ten years of following eXtreme Programming and Scrum-like development practices on more than 150 major commercial projects, there are vast numbers of lessons learnt. Most of them involve sticking to your guns and not compromising. But the most important factor in failure is a lack of transparent communication.

The key to Agile is not to make things perfect, it is not even to make people better, it is to make problems evident earlier. And that requires constant communications. Developers and managers need to be brave enough to communicate failures and mistakes. Those receiving these communications need to be respectful enough to focus on solutions rather than blame. This requires mutual trust and respect (Read this as well: The Importance of Communication in Agile Software Development).

Here are some common factors in engineering that could lead to failure when cutting corners:

(1) Stopping pair programming to “save money” or “work faster”. This just squeezes expenses and delays into the future. Without constant code review and constant collaboration, more defects get into production, weaker engineering ideas get executed. More code gets written that is hard to understand. Code becomes very “personal” and that is not a good thing for a commercial application. The team “bus count” declines because fewer people (maybe just one) understand important parts of the application. The code base can not be transferred to new teams. And the existing team is less resilient to attrition. There are more security flaws. There is more risk of IP theft. More performance problems. More second best engineering practices. And more failures to apply team agreed standards. Solution: keep doing paired programming, or start doing it. (Read more: Why Agile Works For Your Projects?)  

(2) Skipping test coverage to “save money” or “work faster”. Doing TDD (“Test Driven Development”) actually saves time for teams that intend to have test coverage. That is because writing tests before and during development leads to insights about how to write the code better, results in more focused and meaningful tests, and stops bad code development paths earlier. Not having automated test coverage leads to applications and businesses that slowly grind to a halt after a year or so as they shift focus to endless pervasive, insidious and baffling defects. New features become extremely hard to implement and the business becomes increasingly unable to compete with reliable incumbent competitors and fast followers. Solution: keep your test coverage high, or slowly build it back up.

(3) Weak iteration planning. One should always implement features that have the greatest business value or engineering risk first. Delaying the hard things or business critical things until the end can reduce initial conflicts and embarrassments. Managers might want to show visual “results” faster to please their investors or bosses (and maybe that is a business value). Engineers want to do something fun first and avoid the tasks that involve trial and error, and embarrassing failures, bugs and might reveal they are not the right person for the job. The result of these failures is a project that seems to be coming along just fine, with consistent results being delivered, until near the end when the team struggles to deliver the last key features. Or if funding or timelines get squeezed, managers find that even though three quarters of the work has been done, there is still nothing of business value or engineering accomplishment that can be demonstrated or released early. Solution: always do the hard stuff first, or the thing that delivers business value first. Leave the things you will “definitely need later” until the end — you might find you will never need to do it.

(4) Fear of releasing. An agile manager does not take advantage of one of the key benefits of Agile — early and frequent releases. This avoids communication with end users about failures, and thereby entrenches them. You do not learn about what features should have been done sooner, what implemented features no one needs yet. You do not learn about real world defects. And your team does not practice deploying smoothly and reliably. The managers say “it needs to be perfect or users/managers/investors will lose confidence in us”. Instead, they keep working until they run out of good will, money, or the market opportunity disappears or is taken by competitors. Solution: force yourself to release an MVP, and new iterations with a tight schedule.

(5) Planning too much. This is really just a failure to be agile. Of course a vision is required, and some key engineering ideas need to be in place. But sometimes too much time is spent carefully planning, even in “agile form” using user stories and features with engineering point estimations. Or perhaps much too much time is spent just estimating engineering effort. There is an optimal amount of planning, there is an optimal amount of estimation. Too much certainty is bad because it comes at a cost that is not economically viable. In extreme circumstances, just as much time is spent planning and estimating as it would take to implement the actual application or feature. 

Agile is meant to increase productivity of the engineering team and therefore, results in a better result for the client. Stay clear from these mistakes and both sides can get to achieve a successful project.
 

Questions? Comments? Concerns? Contact us for more information. We’ll quickly get back to you with the information you need.