Every application development methodology has its own set of core beliefs, practices, and a more or less devout followership. Agile is no different, rising to cult status in the practitioner community ever since the Agile Manifesto was proposed in 2001.
This article is going to look at:
- Separating the theory of Agile from the practice
- How to keep your Agile project on track and at pace
- How Sprint Planning and Requirements Elicitation sets the tone for the successful execution of an Agile Application Development program
- Agile’s iterative nature and how Sprints should be planned as ‘bite-sized’ units, with tight management of the scope and requirements for each Sprint cycle
Doing Agile right starts with the basics – planning and requirements gathering. Here are 5 key pitfalls Agile Application Development practitioners need to steer clear of.
#1:
Don't...
...let the requirements gathering group grow beyond a manageable audience. Large teams elongate this exercise, with a domino effect across the Sprint cycle - from analysis to design, development and testing.
Do...
...limit the stakeholder group to 7-9 for eliciting and capturing requirements (usually as 'user stories'). The typical participants:
- Product Owner
- ScrumMaster
- One or more Business Users or SMEs (subject matter experts)
- Business Analyst/Process Designer (ideally the same role)
- Application Architect
- Along with a Developer
- And at least one Tester
#2:
Don’t...
...use the requirements elicitation sessions to iron out the business process. Too often I've been part of workshops where gathering user stories turns into idea-generation and brainstorming on business process enhancement.
Do...
...while new tech inevitably sparks off new ideas and improvement opportunities, it would be better to keep such process revisions out of the Sprint requirement sessions and addressed with the business process owners.
The ScrumMaster and/or the Business Analyst primarily drive the Sprint requirements meetings, setting the tone and expectations for the business users at the start – that the Agile Sprint cycle is not the right avenue for business process mapping.
Focus on improving speed and accuracy of capturing requirements through collaborative tools to bring business and IT together, and unify requirements management.
#3
Don’t...
...keep user stories open ended and liable to multiple changes during the Sprint. True, changing requirements are welcomed in the Agile software development method, but frequent changes can be counter-productive if driven by lack of clarity.
Do...
...align business users to identify the intended outcome. De-prioritize a 'To Be Confirmed' requirement to a later Sprint. Make this a ‘Guiding Tenet’ for your Agile program.
As importantly, keep in mind:
(a) The Product Owner signs off on the Sprint scope.
(b) Your product design couples flexibility with robustness to accommodate change.
#4
Don’t...
...consider every requirement from business users into the To-Do list. The Agile feature set is not intended to be a laundry list.
If there's a feature business is unsure about, not immediately needed for the MVP (minimum viable product), do not simply park it for later – but ask whether it is needed at all. The exception would be a 'must-have' functionality that cannot be developed at the current stage in the project.
Do...
...derive user stories from the initial feature set – high level requirements – and expand them through design. Cross-validate the user stories with different stakeholders. Rationalize and prune. Park the shortlisted futuristic requirements for a later Sprint.
And above all, iterate each of these steps. Religiously.
#5
Don’t...
...estimate the development effort simply based on past experience or 'gut feel'. While historical analysis of Sprints helps, unless there's a clear definition of simple, medium and complex user stories, you run the risk of under (or if you're lucky, over) estimating the effort.
Do...
...ensure requirements are self-contained enough for each to be covered in entirety in one Sprint. Break them down further into tasks (usually technical in nature - process flow addition, new screen creation, database update, etc.). Make these tasks as granular as possible, as the effort should be estimated at that level.
Also consider identifying additional user story(ies) that may be taken up as stretch targets - but only if the original scope is delivered.
Running a Sprint needs getting off to a good start, and once you nail the scope, the cogs of delivery mesh smoother as well.
In the next post, I'll talk about the operational pitfalls to avoid during the Delivery phase of Agile application development.
Access the latest business knowledge in IT
Get Access
Aman Vijh
Aman Vijh is a technology strategist and trainer with over 11 years of experience enabling C-suite clients to solve business problems by leveraging technology.
Comments
Join the conversation...