Can you complete a software project faster using an agile approach?
That’s the wrong question to be asking. Let’s start by defining what it means to “complete” a software project?
- Deliver all of the initially agreed upon functionality? – That’s not enough.
- #1 and deliver a high-quality, robust solution? – Still not enough.
- #1 and #2 including all of the high-priority changes requested during the project? – Nope, not yet.
- #1, #2 and #3 while delighting the users with the functionality, ease of use and speed of the software. – Now it’s truly complete!
Such a rigorous definition of complete means that it can be difficult to know when the project is really done. Simply meeting time and budget goals is not good enough. The project isn’t done until the real users and business stakeholders say it’s done. Don’t even think about playing the user-acceptance-test game. Just because you delivered what the documents defined, doesn’t mean the real users will be delighted.
Agile deliver faster — over time.
Can an agile development approach like Scrum, Kanban, Lean or XP get your team to #4 faster? I believe the answer is a qualified yes, and here’s what I mean.
Traditional waterfall projects simply don’t engage the real users often enough or deeply enough to learn from them. We gather requirements, write documents (lots of documents), develop the software, conduct carefully choreographed demos, test the software, deploy it and declare victory. By the time real users get to do real work with the software, the development team has moved on. Now there will be an excruciatingly long wait until a new project is started to correct problems or shortcomings the real users will invariably find. That’s wrong!
We need to deliver less functionality with better quality and do it sooner. Get real user feedback early and often. Keep delivering a little more, a little faster. Get more feedback and repeat. Do this and you’ll get to #4 faster.
Don’t give up too soon.
However, be aware that it won’t happen during your first agile project. The development team and the organization will need time to master agile techniques. Don’t call agile development a failure after just one project. Give it time.
There will be administrative and cultural impediments to adopting any agile approach. Many business stakeholders are skeptical when it comes to the ability of software development teams to deliver anything of value in any reasonable time period. Such skepticism won’t evaporate overnight.
Keep delivering new functionality in small increments. Keep engaging the stakeholders. Keep improving quality.
Delivering faster will happen in time, if you let it.