In my last post, I discussed getting the waste out of your existing software development process. The idea is to get lean and use the leaner process as a stepping stone to becoming more agile. Let’s continue that discussion.
So now that your project approach is leaner — streamlined — what next? Many companies are taking long-term software projects and breaking them up into a series of shorter ones. Thus, they’ll deliver portions of the full feature set across several releases. It sounds reasonable, right?
Sadly, it’s really not. This approach appears to be agile but it’s usually not for one simple reason. Those companies will gather all of the business requirements at the outset, build a prototype GUI, and create a grand design. This means many weeks or months of effort at the front end of the project as they lock down the requirements and idealize their software designs.
By the time implementation begins, the business will have grown impatient as its needs will have evolved requiring changes to the original feature set. As change requests mount, the development team will need to go back and update the requirements while modifying their grand design. Meanwhile, the target deployment dates will appear less and less achievable.
Is this approach better than standard front-to-back waterfall? It’s marginally better, especially if you’ve adopted lean principles, but it’s clearly not agile. You can’t claim to be agile if you lock down the requirements and the design for an enterprise software project at the beginning. Being agile means being flexible and adaptable throughout the project.
Here are a few suggestions for breaking out of this “big design up front” mentality.
- Keep the initial business requirements general. Avoid deriving too much detail. Get a solid understanding of the business needs and intents but not the gory details. The team will work out the details when the time comes to implement the software features.
- Use standard design patterns and implementation frameworks wherever possible. Avoid inventing solutions for problems that have been solved many times. Leverage what’s available and adapt it to your needs.
- Embrace “good enough”. Avoid the pursuit of perfection. Conduct frequent reviews — design, code, GUI, functionality — and seek consensus as to what’s “good enough” for the next release. (The emphasis is on good enough for the “next release”, not good enough “forever”.)
- Allocate time in the overall schedule for refactoring and tuning. You’ll end up doing these things anyway. They are often hidden from view on waterfall projects but we all know that we rarely get complex implementations completely right the first time.
- Work at developing trust and respect among the development team and with the business stakeholders. Without these attributes, you’ll never be truly agile or achieve greatness.
Even with all of the above, your team may still not be truly agile but you’ll be in far better shape than you were. Perhaps more importantly, you will have established a foundation upon which true agile teams are built.