As organizations mature, the natural tendency is to document and codify software-development processes, and then provide a system of oversight to ensure they’re followed.
This is a good thing. No one would trust software written by a team that codes from the hip, and worse, deploys from the hip. Even lean software practitioners like me follow a well-defined process for software development.
Insurers, vendors and consultants use methodologies and processes to deliver software solutions to a market, whether internal or external. The process that any development project follows must cover some basics—for instance, the need to know explicitly where requirements will come from, how source control will be handled, and the need for testing by someone other than a developer. And of course, accountability; everybody involved needs to know who has the authority to say "it ships."
So after that, everything else is gravy? Well, far from it. There are still dozens of other important decisions to make about your process.
The temptation is to find the products and methodology solutions that promise to be the ever-popular “answer to all your problems.” "Hey, we've seen these problems before," promoters of various products and methodologies say before adding, “We have all the answers.”
People love to hear that the answers have already been found, and all these impressive people/conferences/articles agree that scrum/kanban/RUP/etc. represent the absolute best approach for any project.
The devil is always in the details, and hard questions must be asked: Are your teams well suited to pair programming, unit-test code coverage, fine-grained tasks and burn-down charts that a particular methodological approach might call for? Do you need functional specification documents or non-functional requirements?
The best answer doesn't come out of any single methodology, nor can it ever. It requires careful consideration of your staff. For instance, some developers like clear short-term goals they can claim success on; others want involved challenges that have some R&D element to them.
It also requires consideration of your customer's appetite for risk, cost, time and quality. It requires understanding whether your customer knows what they want, or whether they are just taking a first stab.
Putting It in Practice
So, we’re supposed to have a process but aren't supposed to mindlessly follow a recipe. Where does that leave us?
There are many best practices, which are easily identified because they are common across many methodologies and process approaches. Things like repeatable deployments, frequent user feedback and bug/enhancement tracking tools are almost always key components of a successful project.
Overreliance on formal methodologies often leads initiatives down a dead-end path where methodologies and processes are used and performed for their own sakes. Following a ritual will likely mean that the project will take far longer and costs more than it should have—and the software often still doesn’t do the job.
This should never be the case. The answers to the real-world challenges are almost never prepackaged and shrink-wrapped. Instead, always take a step back to take a look at and assess your own environment and needs—before you find out that your development process is broken.
Jason DeBoever is a senior architect with X by 2, a consulting firm in Farmington Hills, Mich., specializing in enterprise and application architecture for the insurance industry.
Readers are encouraged to respond to Jason using the “Add Your Comments” box below. He can also be reached at jdeboever@xby2.com.
This blog was exclusively written for Insurance Networking News. It may not be reposted or reused without permission from Insurance Networking News.
The opinions of bloggers on www.insurancenetworking.com do not necessarily reflect those of Insurance Networking News.
