5 Symptoms of an unhealthy software SDLC process

This is the scenario that I have seen (and experienced) too many times than I can count. We tend to limit or restrict the tools that users have available because we are either attempting to ensure data integrity, uniformity of training, consistency of information, and/or some sense of application security. As a result, user roles within the tool may be restricted and/or counterproductive to getting their job done. But these tools should help them do their job better and faster.

 

While this has happened to me many times in my career, my favorite story happened a couple of years ago when I was thrust into a very siloed and segmented QA process. The organization had purchased Quality Center (available at that time) which included a corporate mandate for all development initiatives to use ALM-QC—only a third of the 120 active projects were using ALM-QC. In addition, only eight of 15 projects/initiatives with a budget that exceeded $one million had created a project within ALM, two only used ALM- QC to store manual test cases. In total, this company was using 21 different applications and processes within the IT department solely to track issues, task, and defects, with less than 2000 employees.

 

Their software quality assurance groups had 12 applications/tools to manage information, not including all the automated testing tools they had purchased over time. These information repository tools ranged from shareware/freeware to several homegrown tools, which primarily were based off of shared spreadsheets. But these tools may not have provided the answers the team was looking for.

 

When the kids don’t like the toys you buy

 

Companies, CIOs, and directors purchase tools to empower, simplify, and enable, their people. They are looking to ensure quality, speed, and efficiency—thus producing measurable and traceable results in the form of ROI. 

 

maze 2.jpgThe problem is that end users often see these tools as restrictive, redundant and counterproductive. A lot of times they prefer tools that they can download off the web, spreadsheets or even working without tools at all.  When this occurs your user base spends more time circumventing these tools and processes than it actually takes to learn and use the tools that you purchased for them.

 

You’re probably asking where is the disconnect, and how it can be rectified without implementing mandates or developing strategic bottlenecks to ensure that the tools and processes they have been put in place are being followed by your teams.

 

I have watched so many companies’ shelf the top-of-the-line tools and processes simply get dusty and not used because of   low user buy-in to the product or idea. This type of anti-ROI mentality is reminiscent of the old saying “change is good as long as it doesn’t affect me." The fact that the tools aren’t being used leaves everybody from the CIO down to the conclusion that the product salesman oversold the tools and processes.  While there may be some truth to that scenario, in most cases the real answer can easily be identified and rectified by looking at how the product was implemented. After being put into operation, was the infrastructure to support the product designed and executed to be successful?

 

As an unofficial MD (Doc if you will), I have noticed five common symptoms of an unhealthy implementation of tools and processes:

 

  1. Does the tool or product you're implementing have an advocate or champion? ---- Are they part of the decision-making process? Additionally will they be using this tool on a daily basis and are they willing to share their knowledge with others? During the implementation process, these people are just as important as the process and/or the product. It is very rare to find internal subject matter expert on your application to be a champion for a process or tools; however, I highly recommend that you search internally before looking elsewhere. When companies adopt shareware typically the subject matter expert (SME) finds a tool online that either enhances or simplifies their current job description. The SME shares his findings with others on their team (similar to the interactions of social media) thus placing this small application tool and processes above collective processes and best practices. We not only see this with applications; the best example of this type of grassroots adoption method is demonstrated on a daily basis by the small teams within the corporate environment adopting agile methodologies. They are doing this to mitigate the very structured and heavy methodologies which large companies still struggle with. While at the corporate level, this kind of structure is still required because they’re not only driven by results-oriented strategies as much as they are dealing with regulatory governance.
  2. bypass maze.jpgIs a tool or product acting as the backbone of your software-development process or is it simply acting as an appendage to the process? ---- A great example of this is how most companies use tools like SharePoint as only a repository for information and nothing more. Most tools and products such should enhance the user experience as well as simplify the current processes that are required to do their job. While working with a company to consolidate over 300 Application Lifecycle Management (ALM) projects into a more manageable size, I noticed that some teams and projects had a very low utilization compared to the rest of the company. After doing a little research, I found that these Quality Assurance (QA) team’s members were completely unaware that they had a tool to manage and document their test cases (other than a simple spreadsheet). The culprit for the low utilization was the test leads of these QA teams. The teams were required by the test leads to document their test cases and test executions using spreadsheets and at the end of the month they would hand over these spreadsheets for the test leads to upload into the ALM-QC project instead of having their teams directly enter information into ALM-QC.  When interviewing these test leads they talked about a corporate mandate to use ALM-QC, and how much they were overworked.  After reviewing these test cases within ALM-QC I found a staggering 500 percent duplication over a three-year period. Are you having to duplicate information or add tasks to your current routine to support the overall Software Development Lifecycle (SDLC) process tool or product? I can easily surmise that the product or tool failed to meet the primary goals that the stakeholder had originally intended. I’ve never been invited to an architectural or design meeting and heard a stakeholder agree to making their employees work more to achieve less. To restate the obvious the tool or product should NOT add time or effort to the SDLC process.
  3. strait.jpgDon’t write, automate. ---- If your SDLC/QA process requires manual intervention, I can guarantee that your development and QA teams are not following the process that you took so much time to develop and document. I can almost guarantee that any written process that has not been also automated, will be circumvented to maximize the quality of the product during the length of the initiative. The best example of this type of tool or process fratricide is accomplished by just simply counting up the number of artifacts (emails, notes, status updates, etc.) that are manually generated on a daily basis and don’t directly contribute to the development or quality of any product is a waste of time. In most cases, these processes can easily can be automated and/or integrated.
  4. Spend less on training and more on integration whenever possible. ---- Remember that one tool can’t fix everything. “If a developer enters and updates several defects without being trained on the defect management tool. Where is the defect stored?" The answer is simple.  It stored and managed in ALM and integrates directly with the developer's integrated development environment (IDE). By using Application Lifecycle Intelligence (ALI) add-in, the concept of having developers, infrastructure and operations teams to be trained directly on ALM is no longer required. Instead they simply work on the tools that best fit their team’s needs all without adding a single step to the predefined process by using both automation and integration.
  5. The most common death nail to any tool or process is the over-regulation or limiting access to the tool or process. ----This is simply an act to secure territorial domination of information or in some cases it is the lack of educating the administrators on the process that supports the tool. This applies to sharing information business unit stakeholders as well as internal teams of business analyst, developers, and project managers, within the same SDLC process. This over-regulation typically comes in two different flavors. The first uses predefined roles within ALM to prevent external users from evading QA’s team’s internal process. This is typically revealed in scenarios where a business analyst can create and update requirements within ALM-QC. They are usually restricted from opening or updating defects, which makes no sense because most defects can be traced back to the requirement's phase of the application development process. The second scenario occurs when the administrator restricts the use of roles and access privileges under the false pretenses of enforcing data integrity and/or uniformity across projects. This translates as a tool that’s inflexible, and highly problematic for the end users. This scenario creates a support nightmare and has the administrator constantly dealing with frustrated users.

 
money maze.jpgIf you keep this these concepts or ideas in mind when implementing and maintaining these tools, I can almost guarantee that your return on investment will have the best chance of meeting your original goals and expectations:

 

  1. Think of the tools that you implement to aid you in the development of applications as the backbone of process or methodology for your IT department’s
  2. Look at automation processes and workflow as a way to remove manual burdens from end-users—freeing them up to do the job that they were originally hired for. Remember it is estimated that 90 percent of the redundant activities within the SDLC process can be automated, thus freeing up your staff for other things.
  3. Don’t think of roles within a tool as a way to regulate users; this only leads to user frustration. Use roles within ALM to empower users and automated processes to regulate. A great example of this is allowing all users to enter issues within ALM; however, it doesn’t become a defect until it’s been validated by another team within the SDLC process. In other words, once an issues/defect has been entered the automated process takes over and automatically sends an email out to alert either the development or testing teams that an issue has been identified needs to be validated.
  4. Don’t design process, roles and responsibilities in a tool that only fits one project size. If your company has multiple methodologies and processes that can’t be managed using one template within ALM, create as many templates as needed to support every single methodology. Furthermore, remember that this will require more resource hours as well as additional expertise in the product.
  5. If you have tools that overlap in functionality, use integration as a bridge over the gap between different team preferences.
  6. Spend as much time as needed to achieve buy-in versus getting an IT mandate which requires twice as much work and infinite amount frustration.

 

In my next blog post I will discuss the antidotes for these problems, and I will have some downloadable tools to help you.

 

And remember, the doc(tor) is always in to answer your Software Development Lifecycle  questions. Feel free to reach out to me in the comments section below and follow me on Twitter: @Wh4tsup_Doc. 

 

NewSite.jpg

Thanks @wh4tsup_doc

 bugs-bunny-hole.jpeg

Comments
John Pereless(anon) | ‎08-14-2014 04:29 AM

Thats really meaningfiul post on SDLC because something really impaccable here. The biggest pitfall in using any SDLC approach is lack of product understanding completely. Developers should first do reverse engineering in doing its module live. The best approach on doing it is the first phase on SDLC which is Problem Analysis.  

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Michael Deady is a Pr. Consultant & Solution Architect for HP Professional Service and HP's ALM Evangelist for IT Experts Community. He spec...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.