More Reasons Agile is the Best Choice for Your Mobile App Development

Seven mistakes to avoid when going Agile. 

Agile has been both evangelized for its ability to allow for rapid delivery of product, and dismissed as chaotic.

After years of frustration with traditional project management, I have grown to love Agile. The speed with which you can complete projects, and the ability to manage cost and time better than ever before make it the ideal development model.

But time and time again I see people make these same mistakes, turning Agile from an efficient way to empower team members into chaos.

1. Believing change has no consequence

Agile welcomes change. New information and developments should be considered throughout the process. Many people mistakenly think welcoming changes means no consequences.

As stories are added, deleted or updated in the backlog it’s essential to ensure the changes still fit in the sprint and the project.

There are a host of estimating tools available to help including traditional Planning Poker to advanced tools like JIRA, Axosoft’s OnTime Scrum, LiquidPlanner and many more.

2. Poorly maintained priorities

Each resource should always be working on the highest unblocked priority assigned to them. If product owners do not provide or update priorities regularly, there is serious risk that a project will exhaust its sprint allocation without getting all the highest priority features in place.

3. Unclear processes

Agile accomplishes ultrafast development by ensuring each person can communicate quickly and work continually on all unblocked tasks on their plate. Excellent communication and well-defined processes are essential.

All processes should be defined before the project kicks off and updated as new developments occur. I keep and regularly update all processes on a wiki to which all team members have access.

4. Waiting until the end for retrospectives

Lessons Learned should not be a meeting just for the end of the project. If left to the end, those learnings tend to be vague and less actionable.

For each project I maintain a Lessons Learned Google Doc. Team members are encouraged to add notes as issues arise; I add to and monitor the document, making changes to the project as needed.

5. Dogmatism

I like to say I practice agile not Agile. With all paradigms, effective process and rational implementation of theory can slowly slide into a rigid and irrational dogmatism.

Brands need to encourage all ideas to be filtered through a lens of, “does this improve our speed and efficiency?” rather than, “is this true Agile?”

6. Stand-ups as bullhorns

The daily stand up should be your team’s most productive 15 minutes of the day. It’s an opportunity to get a firm grasp of the overall project, immediately solve quick blockers or determine next steps for larger issues.

It is an efficient and a powerful communication tool. It’s not a perfunctory list of tasks with no team feedback.

7. Overloading Sprints

The single biggest mistake I see with Agile is not leaving time for planning, bug fixing or polish.

Invariably, planning discussions and recalibration cause development for some sprints to kick off later than expected. And when bugs are encountered there’s no time to fix them. What happens? Stories overflow from sprint to sprint, and at the end you don’t get a releasable mobile app.unc