Common Agile Pitfalls

By Yared Ayalew

I had the chance of conducting a project launch in an agile workshop with Alan Jackson from Aptivate back in June. We were getting ready to kickoff a new project and wanted every team member to be at the same level on the process we were following. We did a two-day developer workshop before engaging users in a three-day backlog identification workshop. It was quite a success both in terms of the buy in we got from the client and the amount of stories we gathered at the end of the workshop. One of the most interesting conversations the development team had was around the common concerns and pitfalls in any agile project most teams face. This post is a compilation of the list of items we had discussed during our session.

Client upset at the end

Making sure that the client understands the underlying principles of scrum is a very important step to take at the beginning of every project. It is very easy to misunderstand the value propositions agile brings to the table. The whole concept of prioritization must be communicated at the beginning of the project (and not everything in the product backlog that gets done at the end of the project). This is especially true when it comes to fixed-budget and schedule projects. In a true agile fashion the team needs to work with the product owner about the release plan while doing prioritization.

Specifications in contract

This causes quite a friction between the client and developer when they sit down to sign-off/handover the product. If the initial contract signed between them includes product specifications at the start of the project, those items might be deprioritized during the development effort causing conflicts to arise. In my opinion it is very tricky to both sides to articulate specifications in a contract. If it is important to put specifications in a contract then it is better to put very broad and high-level product features instead of elaborated requirements. Having stories and detailed specs in a contract makes prioritization and requirement changes very difficult as the project progresses.

The product owner hassling the team

The way the communication between the team and that of product owner should be on the basis that team members can call the product owner anytime but the owner can only do so through the the scrum master. It is always good to have a clear code of conduct when it comes to communication between the team and the product owner.

No communication with the product owner

An inactive product owner can be considered as a major risk when it comes to agile projects. In cases where the engagement of the product owner is in question, it is always good to put clauses about the duties and obligations of the designated product owner. This however should be supported with a good agile training for anyone being considered as product owner.

No time for estimation

Most teams consider estimation as some sort of magic and with good reasons. For most teams estimation efforts are considered as waste of time since its value to the development effort is not directly visible. Every team should invest a portion of its time in improving its skill in estimation, be it story points or otherwise to help identify its velocity. A team’s velocity is probably the differentiating factor between over or under committing in a given iteration. So putting an effort in learning the different methods of estimation will definitely help during release/sprint planning.

Having non-stories in a backlog

This might not seem an immediate issue when starting new projects since most of the items in a backlog can be considered as user stories. Fast-forward a couple of releases after users start playing with the product where bugs and improvements start coming in. Having a separate board for stories and bugs becomes handy in separating regular development from that of support efforts. So it is always a good idea to have a separate backlog for bugs. In my current project we have a scrum board representing our product backlog while another Kanban board is used to represent and to prioritize our bugs and feedback.

Demo blows up

There is a common term for this ‘demo death’! It is a fact of life in software demonstration that something will always go wrong but at least something can be done about it. In our team we introduced the concept of ‘code–freeze’ a couple of days before our demonstration. The team will continue to work on the project while we tag a stable version and make it ready for the demo. Of course nothing beats proper preparation for a demo by preparing a scenario to walkthrough participants during the demo.

Technology dreams

This is probably an issue with a technically obsessed team wanting to come up with technically excelling solution. The team should always focus its efforts on what matters the most from the point of view of the client. Yes it never hurts to use cutting edge technologies but the team needs to embrace the ‘just enough’ principle whenever possible. And it never hurts to check the burndown chart every often to make sure that the team is progressing as planned. If there is time left at the end of the sprint then the team and the product owner can decide on whether to introduce on those nifty technical items or engage in something else.

Product owner loses ownership of backlog

The product owner should be empowered in making any type of decision related with the backlog. In fact s/he should be responsible for managing and maintaining it therefore s/he should be involved in all activities that involve the backlog especially grooming sessions. Another related pitfall is a product owner who has no authority or vision. In such scenario the product owner must be empowered to take decisions.


This usually happens during demonstration whereby senior management is present and comments are given by senior management about a feature of the product without a clear understanding of the reasons for such decisions. This is a very serious problem because it undermines the authority of the product owner and confidence of users in guiding the product. Yes comments from management is what guides the vision of the product but in order to do so any one from management who wants to give comments and feedback should attend most if not all demo sessions otherwise they will be causing more problems than productive comments. Having ground rules during demonstrations and ensuring that decision makers attend demonstration sessions regularly can ease the friction.

Changing requirements mid sprint

One of the principles of scrum is the concept of time-boxing iteration where the team engages in delivering a portion of the backlog. There might be situations that force the product owner to change a significant proportion of stories mid sprint. If this is happening frequently for more than a couple of sprints in a project then it might be a good time to consider using Kanban rather than scrum which puts less focus on time-boxing an iteration.

No retrospective

If I have to pick the single most important ceremony from scrum it has to be the retrospective meeting. It allows a team to continue learning about the agile process in a true ‘inspect and adapt’ approach. No retrospective means learning freeze!

Yared Ayalew is a certified ScrumMaster who has been developing software professionally for the last decade.

Article source:


Powered by Facebook Comments

Leave a Reply

Your email address will not be published. Required fields are marked *