Suppose you have a software development project that will take you one year to complete. What if you broke the work up into two projects of six months each? Which approach would be better? Would it make a difference? What if you broke the work up into four three-month projects? What about six two-month projects? I could go on, but you get the point.
If you’re like me, you may be thinking “what difference does it make as long as the software gets developed?” If so, keep reading. You may just change your mind.
Getting Smarter
If you execute the software development effort as a single project, you have to wait twelve months before your product gets into the hands of the users. For twelve months, you will have developed software without the benefit of the one thing that only users can give you…feedback. Breaking the project up into smaller projects allows you to have the benefit of user feedback from previous “chunks” with each successive “chunk”. Feedback is essential to learning. Smaller projects means shorter feedback cycles which means faster learning. In other words, you get smarter! Longer projects…well, now the title of this post makes sense!
Lessons Behind the Wheel
Still not convinced? Imagine you’re learning to drive a car. Maybe you over-steer. Perhaps you drift out of your lane and hear the “bump, bump, bump” of your tires rolling over the road reflectors. Whatever you do, you’re probably getting immediate feedback – probably from the screaming person in the passenger seat! Now, imagine trying to learn how to drive if you had to preset all of your acceleration, steering, braking and turning moves ahead of time – say for twenty moves at a time. Few automobiles would survive long enough for anyone to learn how to drive.
Start Small for Big Results
I admit I am no expert on agile software development methodologies, but isn’t delivering working software on short schedules one of the core principles? If so, it would appear that agile software development supports faster learning. You may not be ready to jump in and adopt an agile methodology, and that’s okay. But why not look at the next software project you have to plan and look for a way to deliver it in two shorter parts instead of one long part? It’s a step in the right direction and if you learn from the experience, you can try to go for even shorter cycles.
What about you? Do you plan to apply agile techniques to your software development? Have you already adopted agile? Do you think going agile might make you and your organization smarter?
About Julius Campbell