Be honest. No software development process is flawless — not one. Every process, regardless of approach, has something wrong with it. The reason is simple. Different approaches, and various implementations of those approaches, always focus on a few areas deemed critical to success. Those critical areas vary by company and development group. The narrow focus is not because other areas of the process don’t matter. It’s because we can only focus on so much at once. The areas lacking focus tend to be suboptimal.
So, the real question isn’t whether or not your process is flawed but rather, how it’s flawed. What’s wrong with your software development approach? The answer is likely to be convoluted but there’s a more immediate question — how do you determine what’s wrong? You can’t fix the process unless you can clearly define what’s wrong with it. This is where things get interesting.
Linear vs. Non-Linear Approaches
Linear approaches to software development — waterfall being the most common variant — tend to identify problems late in the development cycle. I’m not saying that all problems surface late, only that many problems surface late simply because SQA testing and production deployments occur toward the end of waterfall projects. Thus lessons are learned too late to help the current project and have to be applied to the next one.
Non-linear approaches — Scrum being the most common variant — tend to identify problems sooner, usually after each iteration or sprint. I’m assuming that Scrum is being used properly. Specifically, SQA testing is integrated into the development team and production deployments occur after each sprint. Thus lessons are learned throughout the project and can be applied to future sprints.
Learn Fast, Go Fast
Wouldn’t you agree that the development team and the business as a whole will learn faster and improve quicker if problems are identified earlier? Clearly there needs to be a commitment to solving the problems. Ideally, there also should be an environment that encourages trying out new ideas. Rather than spending a lot of time seeking the perfect solution, the team should toss around a few ideas, pick one and give it try.
In a cyclical development environment like Scrum, new ideas are validated or invalidated in a hurry. Those frequent plan, design, implement, test and deliver cycles are just what the business needs to draw out problems, devise solutions, and keep improving.
So, if you want to know what’s wrong with your development process, you need to shorten its cycles so you’ll have more frequent opportunities to implement, observe, learn, change and improve. Do those things more often and you’ll learn, adapt and improve faster.