Prescription for your unhealthy software integration: 5 tips to improve your ALM experience

In my previous blog post I identified five signs that your Software Development Lifecycle (SDLC) is unhealthy. These symptoms include:

 

  • Does the tool or product you're implementing have an advocate or champion?
  • Is a tool or product acting as the backbone of your software-development process or is it simply acting as an appendage to the process?
  • Don’t write, automate.
  • Spend less on training and more on integration whenever possible.
  • The most common death nail to any tool or process is the over-regulation or limiting access to the tool or process.

WC.jpgIf you haven’t had a chance to read the first post, I encourage you to do so now (then come right back). Today I want to give you the prescription to correct these ailments.

 

To create a cure, you must first identify the symptoms and then treat the infection. To do this, I recommend that you do a complete health check at least once a year on both the tools and the process. This can be as straightforward as running diagnostic tools, viewing the support tickets over the last year and having your administrator send out a survey to the users. If this doesn’t cover all of your bases you can also review the original goals of the tools and processes and what they were designed and implemented to address. Evaluate if it has contributed to the overall productivity of the teams? I also encourage you to review the cost-effectiveness and return on investment on a regular cadence.

 

Before shelving the application/tools make sure that they address the root cause and not the symptoms:

  • If you find the lack of buying from teams within the SDLC process and/or proliferation of other tools (shareware or other third-party tools) that circumvent the current processes in place. Ask yourself these questions:

 

  • Has the advocate for the tool spent time with these teams and have any issues been escalated that cannot be resolved to user satisfaction?
  • Have these groups been properly trained in the process as well as the tool? If they are not using the tool directly, is there a point of integration—is it working? Too often we build elaborate and automated integration points within multiple tools and simply fail to monitor or maintain these points of integration.
  • Have you had a large influx of consultants or personnel in the time since you originally installed these tools?  Have they been educated on your processes and tools? Too often we have big and carefully thought out initiatives to educate people on a tool or process and forget to address the long term education needs and support requirements for the future. Even new people can sometimes be resistant to changing old habits.
  • If you’re still seeing a lot of manual or duplicated efforts after implementing these new tools and processes I would recommend asking your end-users the following questions:

 

  • When you are implementing the product are there some oversights that the tools or processes did not address during the original installation? For example, can you see the forest for the trees, yet the overall automated process did not address the specific needs of the end-users?
  • Was enough time spent on educating users about every facet within the team structure? You can usually identify this if the end-users have been educated, yet senior management still requires specialized reporting or status reports with information found outside the tools and processes.
  • Look for bottlenecks within the process, and tools that may be causing users to sidestep the current automated process. This is often exposed when looking at integration points between two teams and the signature of a single team member or group is required to get a process approved. This single act can create bottlenecks.
  • The last one is the easiest one to find—simple human defiance.
  • If we have tools and processes in place why are teams not more productive?

 

  • The “process within a process” syndrome is typically where the team or person has layered other processes on top of the current tools. A great example of this is project managers or team leads requiring external or manual status reports outside of the tools or process.
  • Look at the teams within the SDLC process and how they are communicating.  Is communication carefully thought out and documented. This scenario is seen if a defect has been generated by the tester and automatically sent to the development team for validation. When this happens communications between the two teams begin via emails and circumvent the capabilities of the tool to document. Does this mean the tester is documenting everything needed for the developers to troubleshoot the issue and/or is the integration between the two systems adequate?
  • Has the process been fully automated and integrated? Is there overlapping functionality within the two tools that conflict with each other? Make sure when developing the integration between two systems that you look at all of the aspects of the applications and the overlapping functionality. For example, Jira and ALM both have the capabilities to document requirements, create test cases and manage issues. In this case, you must first define the system of record and then be sure that the information of both systems is mapped correctly and eliminate any omnidirectional information, if at all possible.
  • Sample Roles and Access Levels_Page_01.jpgMake sure that the roles assigned to everybody on the team are not restrictive to the point that the approval of two or more people is required to complete a simple task—such as change of status to the defect or entering an item to a single list. This occurs when a tester is the only one that can close a defect, or you have to sign multiple roles within ALM to an individual user which defeats the original intent of assigning roles. A well-thought-out process flow can close a defect. However, if the process is not followed the system will automatically rectify the issue and then inform the user why this action was taken. Let’s say a developer attempted to go from “assigned'” status to “close" status, the system identifies that is a step in the process has been bypassed and quickly changes the status to “fix” instead of “closed” and the workflow informs the user is a step has been bypassed at the user. If they would like to “close” the defect, they merely need to change the status once again from “fixed” to “close." Once the developer “closes” the defect notifications are automatically sent out to the test lead, and the author of the defect, giving them the opportunity to revert the status back to “fix” if necessary. The system has also logged all of these changes to the history logs for traceability. In looking at the overall process, this is nothing more than five to ten lines of code, which empowers and enables the user to do their job and much more. However for this to happen, everybody has to follow the process.
  • Is user dissatisfaction with the tool increasing or are you spending more time training and mentoring teams after the initial implementation?

 

  • Are  a majority of your support tickets based on informational or uncomplicated functionality? This may be a result of users who are occasional users and may use other tools such as eclipse, Microsoft Visual Studio etc. . Within SDLC development, process is not a one-tool solution. If I was supporting one of these tools, I would dread the day that everyone would have to log into a tool like Application Lifecycle Management (ALM) to enter defects. I would much rather integrate with other tools such as Microsoft Visual Studio, Eclipse, or Jenkins so that people are able to use the tools that best fit their job description and tools like ALM become unassuming recipients of this information using APIs/integration.
  • Are your administrators and/or support group trained in the process (as well as the tools) and do they have experience and expertise within the groups they support?

 

  • Too often support and administrative activities are handed over to teams that are experts in supporting but are not qualified in the processes to support those applications. Have you ever had to explain to an administrator of ALM why you need to delete a record or that workflow isn’t working? When visiting clients you’ll often see a junior tester as the administrator. On some bigger implementations, you will see a career database administrator alongside a server/application professional administrator who has never been educated on the processes—this situation impacts these tools. A lot of times it’s simply easier for an administrator to lock down or limit access to a tool due to a limited knowledge of what the tool can do.
  • I have attached a sample to this blog post of roles and responsibilities from the standpoint that the user is required to adhere to the process. But remember that the process is put in place to enable the users to be both efficient and effective in doing their job.  If the tool or process fails to help the end-user, then the user has two options: either bypass the process or complain that having the users buy into the process is highly unlikely.

 

  • Take advantage of the workflow to help you implement simple functions that could save the user time and reduce support tickets immensely. For example, by implementing a few lines of code you can allow a test lead or tester to add something to a list item that can be tracked within reports—without having to open a ticket.
  • Try to create KPI’s and reports that cater to specific groups. For example, a director will not want to see the same thing that his direct reports see.  Managers will want to be able to go into detail (if necessary) but not to the level that an end-user needs to do their job. The director may want only to see the number of open or closed defects over three or four projects.  A manager needs to see the typical new, open, assigned, fixed, rejected and fixed status. As an end-user you need sub-statuses (sometimes called dispositions), which tell the user that a defect has been assigned  and is currently being unit tested for research as shown in figure 1.

 1234567.png

Figure 1

This article is primarily focused on how administrators, architects, and management can alleviate some of the pitfalls of implementing and integrating tools like AGM and ALM. Keep in mind that these recommendations hold true with any tools and processes that your company or groups are trying to implement. Someone once told me “If you are implementing anything spend time to build it right and spend less time to keep it that way”.  This is important advice to keep in mind as you build your environment.

 

The attachment to this document is a sample that you can use to help you identify roles and responsibilities within your team. I highly recommend that you never use the default roles and responsibilities within ALM because the default roles and responsibilities cannot be changed. They are only templates to help you create roles and responsibilities that fit your process.

 

I’d like to ask, if you have any tips or tricks that you can share with other readers I would really appreciate it. Remember that which you think is a simple hack may be a lifesaver to another reader. So please make this a better community and share.

 

If you have ideas, questions or would like to know more on the subject please feel free to post your questions in the comments section below, ask me on twitter (@Wh4tsup_doc) or just send me an email and I’ll get back to you as soon as possible.

 

NewSite.jpg

Thanks

@wh4tsup_doc

bugs-bunny-hole.jpeg

 

Comments
| ‎02-20-2014 06:55 AM

Can you post a copy of the defect workflow? Trying to sell management into a updated process. Thanks.

Michael-Deady | ‎02-27-2014 05:36 AM

Yes Please send me Email at Michael.deady@hp.com and I'll be happy to

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.