Over the years, I’ve been involved in large and small software development projects that have used many different process models (Waterfall, Incremental, Iterative, etc.). These experiences have led me to my present day use of the agile SCRUM model of software development, which is a combination of both iterative and incremental methodologies.
I’ve used SCRUM to develop enterprise applications for large client sites and learned a few giant lessons along the way. Take a trip with me up the SCRUM beanstalk and see what I learned from one particularly giant client.
Good intentions don’t always amount to a bag of beans.
Before starting the project, I went through a lengthy and in-depth analysis with the client. Part of that analysis included a pitch about using SCRUM as the development process. We explained SCRUM to the client, noting that they would be able to see the scheduled SPRINTS and requirements in the SCRUM tool as well as enter issues and bugs directly during testing.
The client was on board with the idea in a big way and then Fe… Fi… Fo… SCRUM, issues started being logged. I spent a lot of time explaining the difference between urgent and high priority issues and working to avoid being crushed under the giant pile of issues and feature requests.
The result: We created a more formal triage process for issues before passing them off to developers. A little pain will result in a big gain for an internal SCRUM process.
If the beanstalk is the project, then change requests are the giant’s club.
The “upside” to SCRUM is that because you break functionality into shorter development cycles, or SPRINTS, you get to show progress to your client early and often.
The “downside” to SCRUM is that because you break functionality into shorter development cycles, you get to show progress to your client early and often. Once we started delivering components to the client for testing, a frenzy of urgent priority “bugs”, or what I like to call “feature creepers”, started coming in.
To be perfectly honest, there are always a few urgent bugs needing attention, but this client was really having “requirements remorse”. They started saying, “Shouldn’t it work this way instead?” or “Wouldn’t it be nice if it did this or that?” They forgot the work of the analysis and BEHOLD, change requests are born.
On enterprise-sized projects, you can be tempted or even pressured to just accept these requests. Some can be included with little or no impact. Others, however, need to be included no matter what the impact. The remaining bunch, well, those can just wait. The best tool you have to determine this is thoughtful impact analysis. Even early on in the project lifecycle, small changes can have a big impact on your schedule and budget. Ensure all project stakeholders understand the impact of each change presented to you before starting the work.
The result: Planting seeds at the beginning of a project resulted in better control over the project scope, schedule, and budget.
The beanstalk is ALWAYS taller than you think.
The analysis of larger software development projects can uncover complicated requirements and business processes. In practice, it is often impossible to capture the complete set of requirements during your analysis. In fact, between 5 and 10 percent of your requirements may not be understood until you are into your development cycle. Many times, it is obvious during the analysis which requirements will be part of that 5-10 percent.
Don’t get upset or stressed about it — just plan for it. Include time in the appropriate SPRINTs (or even have a separate analysis and design SPRINT) to do additional analysis and design for those requirements at various points in your schedule.
It will be a lot easier to explain schedule and budget changes once you explain to project stakeholders that some items are still unknown and why, and that time has been scheduled to address those unknowns.
The result: A little advanced planning and explanation resulted in better management of client expectations, project scope, and budget.