If you’ve worked in software development and/or quality management (QM) for many years, you’ve probably found yourself in all kinds of thorny situations when it comes to managing the software development lifecycle. In my twenty-six years in this profession, I sure have, and I have the bruises to prove it. Missed deadlines, buggy releases, upset customers, and cranky bosses drilling me on why I didn’t foresee and proactively plan for these issues. Taking from those lessons learned, this article addresses a few of the challenges that you may face when implementing application lifecycle management (ALM) strategies.
Managing Software Development and QM Complexity
We all know that software development and QM is complex, has many variables, and is not an exact science. It takes planning and oversight to reduce the risk of things going wrong. Over the years, I’ve identified ways to mitigate many prickly issues. I start with good engineering practices, measure what I can, and make adjustments things go astray. Unfortunately, some developers have a much more reckless approach.
Running Behind Schedule
It is very common for projects to fall behind schedule–almost from the initial phase. The inability of the team to come up with realistic estimates may be a reason for this. To address this issue, you should first find out who is estimating the work, the project manager or programmers. You should be concerned If the project manager is doing the work estimation. Always allow the programmers to estimate their work because they’re more attuned to the essential duties required to complete each programming task.
OK, so your programmers are estimating, and they’re still running behind. At this point, we need to dig a little deeper. Are the requirements properly defined, and did the programmers take the time to draft a design when estimating? If not, they’re probably under-estimating because they did not decompose the requirement into low-level design tasks needed to fulfill the requirement. By getting into the weeds of the design, you can really start to estimate better.
Scope creep is another common issue. You start off with a design, start coding, and then someone comes up with some cool enhancements to the feature. So, you try to fit that coolness into the same work schedule when, instead, you should re-estimate the work based on the new features to ensure that they will still fit within your time constraints. If they don’t, let the cool feature wait.
Finally, some people are just not good at estimating tasks. You have optimists that like to think they can get more work done than they really can (I fall into that category), and some pessimists that sand bag by putting out huge estimates to cover their butts. Both of these issues are detrimental to a project, so determine who estimates well and who doesn’t. Find ways to improve their estimating skills. In addition, consider why projects take so long in the first place.
Why Do Releases Take So Long?
Let’s say you are working on a software project. The requirements were defined upfront, and it still took six months or more to began producing the software. How you got here may have. Maybe the estimated time to start production was six months or less, but things kept getting delayed until too many months elapsed. What the heck happened?
Whatever the circumstance, six months is too long to finish a software project. Projects like this suffer from what I call the elephant syndrome: How do you eat an elephant? One bite at a time. Hopefully, you don’t choke.
Staffing or quality issues may have caused delays, which I’ll address later, but most likely, you bit off more than you could chew. Fixing this is quite easy. Instead of trying to deliver a complete software product with all the bells and whistles, break it down into manageable, short releases (no more than two weeks in duration) with a specific and pragmatic set of features and scope.
This approach is called an “iterative” approach to software development, which the agile community made especially popular. The truth is that iterative development predates Agile. Iterations were first suggested in the classic development process work by Winston Royce in defining the lifecycle that became known as Waterfall. You can also use an iterative approach with Waterfall development where you fully define all requirements up front, code, and then test in a staged approach. Or you can use agile development where only the tasks that fit within an iteration are completed. In my personal experience, agile development lends nicely to solving this problem (iterations are called sprints), but it can certainly be done with an iterative Waterfall approach. Bottom line: Undertake less work and finish quicker.
Tackle Your CM and ALM Strategies in an Iterative Way
So you’re on board with limiting the work but worried about delivering something that is useful. Say that you’re building contact management software that is used to track customer and sales contacts. When you start planning out the software, all the features and functions needed to pull this off can quickly overwhelm you.
I can imagine your wheels turning as you are thinking about building a security system, contact listing, contact maintenance screens, reports, dashboards, email functionality, and import and export features–the list goes on forever. Stop stressing! In the first iteration (or sprint), build just the contact listing and the ability to add or edit a contact. Forget about security, auditing, ability to delete contacts, etc. Focus on the bare necessities. The juicy stuff can come later.
In fact, you may even be inclined to start gold plating the contact listing. You might dream up ways to allow in-place editing, print preview, file attachment capabilities, and many other flashy enhancements. Those are all cool ideas, but let those features materialize in future iterations. If you are developing this for internal use, your team could actually start using the bare-bones model after the first iteration allowing you to receive immediate return on investment, and, more importantly, feedback from your customers.
Conclusion
These are just a few of the issues that I have had to deal with when implementing ALM strategies. There are obviously many more and hopefully I will have a chance to share them with you in future articles. Regardless of which thorny issue you tackle when implementing CM and ALM strategies, make sure that you take a pragmatic approach to analyzing the issue and come up with solutions to help you continuously improve your own processes.
