As is the case with most project and program managers, I often encounter the challenge of determining which software development methodology will deliver the best business value within the proposed budget and timeline. Agile Development has grown in use and practice. Two key principles of this method are ongoing interaction between users and developers and the delivery of software in frequent intervals. Other guiding principles include:
- A KIS (keep it simple) approach
- Customer satisfaction
- Working software as the primary measure of progress
- Attention to technical excellence and good design
- Self-organizing teams
- Face-to-face communications within teams
- Accommodation of late changes
While these Agile principles appeal to the developers and project team, I still see some challenges in applying the principles in practice that distract teams from delivering timely value.
Challenge 1: Flexible Scope
I have had first hand experience with Agile Development where we’ve achieved and delivered successful business value. I’ve also experienced my share of feedback from disillusioned business sponsors who obtained less value over a longer than expected period of time. The primary difference between these two experiences was “flexible scope” that can be attributed to a lack of discipline in governing the project scope.
Since the software is developed and delivered in pieces or sprints, the customer starts using the functionality immediately and giving feedback. The feedback can and frequently does result in more ideas to be implemented. The project team and developers fail to differentiate between a minor change with little impact and a major technical change that increases the scope of the development. Without discipline and in the name of customer satisfaction, all changes can appear to be treated equally.
The result? In the case of a major change, the delivery of value extends the timeline. If the sprint ends, then the value attributed to the change does not get included and results in the value being deferred to the next sprint. Value can be delayed by a month or more.
Challenge 2: Estimating the Effort
Agile Development is known for accepting requirements at any stage. Again, requirement adds and changes may be minor or major but, more importantly, the timing of the change can have a significant impact. For example, I witnessed a required system rewrite that, had it been communicated during the first 2 sprints, alternatives could have been evaluated. It was months before business value could be achieved.
The above scenario makes it very difficult to estimate the effort required – a critical component for budgeting and input into return on investment.
Involving business users in daily meeting helps a lot. However, it triggers more ideas to the user. If not managed well, the scope increases. Extra emphasis on the discipline of the iterative process and managing both the developers and users will help keep the scope as well as budget in mind.
Challenge 3: Developer’s Skill Level and Group Think
Another challenge with applying the Agile methodology is the development team’s skill level. Are all of the developer’s experienced enough to complete the work in the sprint time frame? If there is an inexperienced developer who is not managed well, the whole process slows thereby defeating and contradicting the benefits of Agile. In addition, a “group think” mentality can cause developers to concentrate more on pleasing team members than achieving overall project goals. The “I can do that” or “wouldn’t it be cool” attitude can add unnecessary time and costs without adding value.
So what is the answer?
It’s easy to see, then how an Agile Development project not governed well can run wild. And, if you are working on a fixed budget project, it can be a disaster. But what is the answer?
If possible, choose your methodology for software development specific to the project. From my experience, Agile Development is good for smaller projects employing highly skilled staff where discipline can be maintained. Larger projects generally need more scope management than is typically found in Agile Development. Of course, Agile can be used when trying to resolve unknown user requirements.
But what if you are already committed to Agile Development and not achieving the expected results? Here are some suggestions:
- Run initial scrums prior to development work to get high-level requirements, effort level, business value to be delivered and committed delivery dates.
- Ensure the project team and developers understand and are held accountable for the delivery of business value.
- Make sure there is regular communication between the scrum and the business and technical leadership.
- Track “scope creep” and defects to establish benchmarks for future Agile Development projects.
- Evaluate results and conduct project closure exercises to understand the effectiveness and efficiency of the Agile Development team.
For other project management tips, check out my previous blog, Taming the Project Beast.