codetravellers

Reduce Risk

Over-managed or Under-managed SDLCs

  • Development lifecycles are either under-managed or over-managed
  • Under-managed SDLCs creates product instabilities
  • Over-managed SDLCs are slow and have low yields

Designed Agile SDLCs

  • Self organized and customized to the organization
  • Reduces Risk
  • Has high quality yields in optimized time frames

Introduction

With every batch of new developers coming out of universities, there appear new skills and new ideas and new approaches. Software development is new discipline and developers are always discovering new and interesting ways to solve problems.

However, experience shows that time and again engineers entering the workforce have little or no knowledge of how to build enterprise grade software products. It is almost like every new generation has to relearn how to build software from the beginning as though there we no prior knowledge regarding this matter. Legacy organizations have rigid refinery-like silos  in which software is developed. Startups with new recruits develop software in an ad hoc manner. And even successful companies mature their development lifecycles in very different ways.

Almost every organization builds products slightly differently than  any other organization. Even departments within a larger organizations build software entirely differently from their neighbors. There are pros and cons to this approach, but by reinventing the wheel in every development effort, large or small, the element of risk is introduced often in hidden and surprising ways. The development process itself is fraught with risk. It is surprising to find that the methodologies in existence for reducing risk and promoting quality are not more ubiquitous in the industry. There is a natural way to building software. By its very nature software development is evolutionary and based on piecemeal growth. It also, like other behavioral systems, does not work in isolation, but depends upon other components to fulfill its purpose. Because of its behavioral nature, software is resistant to rigid structures or dogmatic control. It does not respond well to civil engineering practices and must be guided instead of forced into fixed structures. Regardless of the organization or what new technologies it is adopting, the fundamental nature of software ramains the same. The principles and practices discovered and used by Agile are essential to buiding software products. However, each organization has unique needs and how Agile is adapted for each SDLC in an organization will be unique as well.

Failure Percentages

A significant percentage of software products fail, with estimates ranging from 70% to 95% of projects failing to meet their initial goals. Specifically, one report states that 95% of software products fail. Another source, Zipdo reports that 31.1% of software projects are canceled before completion.

Several factors contribute to these high failure rates, including;

  • Poor communication and collaboration:
    Lack of clear communication between stakeholders and development teams can lead to misunderstandings, misaligned expectations, and ultimately, project failure. 
  • Incomplete or poorly documented requirements:

    Insufficient or unclear requirements gathering can result in products that don’t meet user needs or expectations. 

  • Insufficient planning and unrealistic timelines:
    Projects that lack proper planning or have unrealistic timelines are more likely to fail. 
  • Scope creep:
    When project requirements expand beyond the initial scope, it can lead to delays, cost overruns, and ultimately, project failure. 
  • Lack of testing and quality assurance:
    Insufficient testing can result in products with bugs and issues that can negatively impact user experience and lead to project failure. 
  • Resistance to change:
    Stakeholders may resist adopting new technologies or processes, which can hinder project implementation and lead to failure.

Designed Development Environment

It interesting to note that in the list of factors that can cause a software product to fail, the process for building software is not mentioned. The SDLC itself can significantly increase the costs of software development and can in itself, introduce a level of risk in the organization that can lead to product failure. 

On the other hand the opposite is also true: the software development process itself can reduce the risk in all the causes of failure listed above.

  • A well designed development environment promotes communication and collaboration.
  • Incomplete or poorly documented requirements, surface very quickly when any component in the product stack is being tested in an integrated development environment.
  • Unrealistic timelines can surface very early in the development lifecycle if an iterative approach is being taken.
  • And a well designed development process with an on-premise cloud promotes quality from the beginning.
  • Finally resistance to new technology change can be lowered once stake holders see how it benefits them when added to their product. 

Over the years it has been demonstrated, consciously or unconsciously, that a development environment based on Agile is as essential to building a successful product as anything else. Conversely, having an ad hoc or over-managed development environment creates instability, churn, friction and miscommunication that can subvert product development leading to its rapid downfall.

Reducing Risk

Since every organization has a unique way of doing things, then it follows that each Agile development environment needs to be adapted however slightly, to the particular needs of that organization. This approach adapts Agile to the organization and not the organization to Agile. There is no one size that fits all. Each instantiation of the design takes into account the needs of the organization and how to reduce risk as much as possible for that organization.

Custom Agile environments designed and built in this way don’t only reduce risk, they elevate factors that promote successful product development. Factors like communication, collaboration, product visibility, quality, adaptability and time to market.

Risk cannot be eliminated but it can be mitigated, thereby allowing the organization a greater chance to get its product out the door successfully.

Ideate Iterate Innovate