Top 5 Do’s and Don'ts for Executing Agile Application Development

In the previous article, we covered the top 5 traps to sidestep during Sprint planning and requirements gathering. This concluding post looks at avoiding common mistakes during the development and delivery phase, including:

• The top 5 misconceptions in Agile delivery management to watch out for
• How to overcome common issues that can derail your project during the implementation phase
• How to enable continuous improvement of your Agile teams

#1: “It’s Agile - we don’t...” or “...can’t do documentation.”

Don’t...

…disregard the need for good record-keeping under the Scrum veil of minimalist or informal documentation. The importance of a quality deliverable is too often glossed over by the myth of writing it down being an 'overhead'.

Think of it this way, are your artefacts – product backlog, design, test plans etc. – self-contained enough to minimize overlap as well as people dependency? Would app support teams be self-sufficient once the development team has moved on?

I was recently part of an Agile team where the documentation (or the lack thereof) left much to be desired - discovered only when the proverbial can of worms was opened – and the bugs began to sing.

Do...

…establish ground rules for documentation – based on the artefacts needed, their intended usage, audience and owners across the development lifecycle. For instance, documenting code is not an added inconvenience, simply a good programming practice.
 
Practice quality over quantity. Many of the standard deliverables such as functional and technical specifications, design documents, development and test strategies can be done away with – through user story mapping and test-driven development. Similarly, updating operations support and training manuals for each Sprint may be a ponderous task, so consider developing Sprint-wise quick reference guides rather than comprehensive tomes instead.
 
Sit with your team to figure out what you need, and correspondingly settle into the documentation way that works best for your Agile team.

#2: “Have you completed this? Why not? And what about that one…?”

Don’t...

…micromanage. Don't let the daily stand-up meeting turn into the drudgery of status reporting. If you spend time telling each other just what was accomplished since the last meeting (typically the day before), your information sharing practices need an upgrade. In the same vein, don’t let the scrum become a technical discussion or a planning meeting either.

Do...

…go back to the basics. The daily stand up must be held standing up, limited to 10-15 minutes, and focus on 3 aspects:

1. What did we do to achieve the team’s Sprint goals yesterday?
2. What will we do today to meet the team goals?
3. What might impede us or the development team from achieving our goals?

Any item that doesn’t fit into the above or merits a longer discussion should be parked for later, preferably right after the scrum. Emphasize the importance of self-management.

Use tools effectively. Set up team dashboards visible to all, such as Kanban and burndown charts (online or offline), showing the status at a glance, and cutting down time spent on reciting each line item and tagging it red, amber or green.

#3: “But you said we could always change it later!”

Don’t...

…mistake the iterative evolution for an unending array of scope updates. Business stakeholders frequently operate under the misconception that requirements can be modified almost endlessly. Plus, lack of appreciation of why certain changes are debatable can lead to a blame-game later.

Do...

…have a short and long-term vision for your final product – in terms of business outcomes or value, which I refer to as the Value Backlog. Educate the business that certain key process or design decisions may not be reversible at a later stage, or need significant effort to revert.

The Agile team should work as a cohesive unit to align requirements (easier said than done, I agree). As far as possible, enable co-location, face-to-face discussions and focus on team over individual accomplishments. 

#4: “Quality is a function of Time.”

Don’t...

…persist in the notion that reducing defects can only be achieved with a longer Sprint cycle. Although quick turnaround times may justify the lack of a ‘polished’ feel, if the user experience expectations are not met – you risk being sub-par instead. 

Do...

…embed a focus on quality into your practice DNA. Make sure your team understands that improving quality with every Sprint is a collective responsibility.

Track the defect profile along with velocity and burndown. Pinpoint the major source of defects, and ‘left-shift’ the target profile from testing to development to analysis. Improve delivery cycles through test automation.

#5. “But this is how Agile is always done.”

Don't...

…stick steadfast to the app development culture prevalent in the organization. Don't forget the need for continuous improvement during the course of the project, especially if your organization is new to implementing Agile.

Do...

…realize that Agile development is more than a set of practices. It is a mindset, and building that mindset needs learning from each successive cycle and repeating the ‘better practice’ till it becomes second nature. For instance, varying Sprint cycle times based on the product backlog, test automation, improving the ‘look and feel’ with every release, and so on.

Challenge the status quo. Conduct post-Sprint "What can we do better...and How" sessions, conscientiously. Work towards imbibing the Agile value of consistent (or improving) pace of delivery across Sprints.  

To cite a cliché in conclusion, a theory is only as good as its practice. Keep in mind the basic Agile principles, but mold the operations to your exact needs. Avoiding these potholes will go a long way on the drive towards successful implementation.