January 25th, 2019 by Thea Maisuradze
The blog is produced in conjunction with Journey Into Agile With Inflectra - A Free Webinar Course.
Often, when people hear about application lifecycle management, they interpret the terminology with things they know. Project Managers or Scrum Masters will think of the current scope of the project or the specific iteration/release that has a known scope and relatively short duration. Business Analysts, Product Managers, and Product Owners think of the product lifecycle management that has an uncertain scope and unclearly long duration. Architects, Designers, Developers, and Testers focus on software development lifecycle. Operations, Service Delivery, Program Managers and Portfolio Managers think of the deployment considerations, release documentation, and benefits realization.
Now, combine these chaotic misinterpretations with each business group’s or individuals’ preferences to one specific tool based on their comfort zone or opinions, we have just created a “perfect storm”. This storm manipulates itself as a) requirements are in different places, tasks are in one place, test cases are incomplete, and the list goes on, b) the single and central source of truth to what customer wanted and what we delivered is open for interpretation!, c) the concept of application lifecycle management becomes murkier because all problems are treated like the same nail and the same hammer is used to solve everything, and d) total Cost of Ownership for the organization becomes high! Needless to say, like any “perfect storm” leaving a “trail of wreckage”, the lack of applying important principles to application lifecycle management in any tool leaves a “trail of failed projects”.
Is Agile Panacea?
Often, people jump on to the Agile bandwagon and think “all their cure” has arrived! In fact, whether people do plan-driven project management or agile approaches to managing projects or a combination of hybrid approaches, the problems continue to remain if we don’t understand five principles that need to be in place for any tool of choice to manage the application lifecycle. Let us review at the latest state of the agile survey published by Version One. This is an industry agnostic global survey where several hundreds of members share their input on the reasons for going agile.
Perhaps because of the short time-focus on iterative and incremental delivery, 75% of the industry says accelerating software delivery is the reason for going agile? But, if time is fixed and scope is variable, only 46% people claim increased software quality? What good is a software without adequate quality? Agile’s claim to success was also that it allows change compared to plan driven approaches. Only when stakeholders are properly managed to control change, this claim can be true! That management of stakeholders is not associated only with agile! Don’t you think so? In fact, despite 64% of the industry’s claim to using agile as a framework to manage changing priorities, only 55% claim productivity increases and 49% see agile as a means to align business and IT. So, just going to agile is not going to be solution. People, process, and technology has to be integrated around the value proposition. The tool of choice across this people and process should enable this change!
STAGE: Five Principles
These challenges illustrated above are not new. Yet, the reason for their recurrence is often due to the lack of learning the required lessons these failures taught us. Regardless of the framework used for project management, product development, or software development, if the software products evolving from any project has to add value, the principles of STAGE apply. This STAGE is an acronym standing for “Services”, “Traceability”, “Auditability”, “Governance”, and “Engineering”.
Any tool of choice should, therefore, provide this single source of truth. For instance, the governance component of the tool should provide a seamless decision making in light of strategic benefits, coordinated planning, complex dependencies, deliverable integration, and optimized pace. As requirements evolve through the iterations, the requirements traceability should not only map to the test case but also to the binary deployed to production environment. This mapping should be bidirectional where engineering interface to both the source code and version control become pivotal. The same tool should also enable auditability to compliance procedures and standard operating procedures enabling process audit and procedure audit laying the foundation for operational excellence. Gathering ongoing requirements from the operations and client facing personnel that support the application in the field, this tool should enable a quick way to provide additional insights by reducing the time taken to field end-users’ questions in the field but also sustain the application in production.
Now, many tools may provide one or more functionality that meet these STAGE principles but does your tool meet all of them? If one or two functionalities is missing or an organization is invested in one tool, such tool’s interface to other tools that provide the missing functionality seamlessly as a one-stop shop is critical for all stakeholders to get to the single source of truth from a central location and sow the seeds of continuous improvement.
So, does your tool provide all the elements of STAGE principle opening the gates to increased productivity, reduced cost of ownership, and seamless integration?
Dr. Sriram Rajagopalan is a project management guru with extensive software development and project management experience in many industries. Dr. Rajagopalan lead Inflectra's agile project management training course: Journey Into Agile With Inflectra - A Free Webinar Course