This is a chapter excerpt from the just released book, “Distributed Agile,” by author Upadrista Venkatesh, published by Technics Publications LLC, all rights reserved. To receive a 20 percent discount, use the code InfoMgmtDistAgile20 when purchasing here.

 


Almost all senior executives think very carefully about the long-term health and strategies of their organizations. They understand that their industries offer many untapped opportunities, so they try to take advantage of the more current trends, sometimes even reorganizing their firms to exploit these options. For all such executives, the challenge is to differentiate the true opportunities from those that are obsolete in nature. Many opportunities have arisen, but they have faded in the long run because of the limitations they carry. 

Such instances occur when you constantly strive to leap ahead of the competition by focusing on a particular narrow concept, rather than maintaining a broader perspective. Although the concept may demonstrate benefits in some areas, the broader benefits that were achieved in the past might have been lost. Such cases have shown up in the software development industry (IT industry), where new techniques and concepts emerge on a very frequent basis. This is one of the reasons why executives in the IT industry scramble in response to each opportunity – they lack the perspective to separate the truly important and mature developments from the temporary distractions. By adopting a strategy that provides additional advantages without compromising the existing benefits, organizations can channel their efforts to maintain distinctiveness and battle for continuous improvements. 

One such innovation these days has emerged from the model of Collocated Agile development. There are certain advantages of the Collocated Agile model. The key benefit is in the area of communication and collaboration – Collocated Agile ensures that face-to-face communication and real-time collaboration is achieved between teams, thereby reducing the chances of errors and misinterpretation. The model also ensures that timely feedback is received from teams, thereby reducing the wait-time – this is achieved because the teams are collocated. These advantages are lost when executing Agile projects in a distributed environment because the teams may be distributed across different time zones and do not work from the same office. 

Although there are many benefits to Collocated Agile, the cost of a project executed in the Collocated Agile model is far higher than projects executed in a Distributed Agile model. Cost is one of the major drivers for any organization to be successful; hence the Collocated Agile model is certain to pose a challenge for large organizations that want to practice innovation, but not at a high price. 

The Design for Hybrid Agile Adoption Methodology (DH2A Methodology) was developed to overcome the current challenges of Collocated Agile methodologies by providing not only the overall benefits of Agile, but also focusing on executing Agile projects in a distributed environment. It provides value by facilitating achieving high quality projects at a low cost. The DH2A Methodology also overcomes the challenges of communication and collaboration by utilizing proven good practices of distributed development and technology, thereby ensuring that the team provides the same results in a Distributed Agile environment as they would have shown in a Collocated Agile model. 

The lifecycle in DH2A is based on several successful experiences executing Agile projects in a distributed environment. Several methodologies existing today address non-Agile approaches combined with distributed strategies. Others combine Agile in collocated strategies. DH2A is the only methodology that marries the world of Agile with a distributed development strategy to resolve many of the challenges existing today in Distributed Agile. 

With several Agile methods today providing high adaptability to changing requirements and advantages over reduced documentation and minimal process adherence, many organizations have come to appreciate the merits of the Agile Methodology. However, over time, a lack of discipline and guidelines has led executives to become skeptical about using Agile for large, complex projects, especially in a distributed environment. One reason for such skepticism is that each organization or team interprets and implements the principles of Agile quite differently.

For example, some teams following Reduce Documentation as a principle have written requirements on whiteboards. Although they were successful in developing the right software, in the long run, manageability of the product was a failure due to lack of proper documentation. These organizations were forced to either recreate or retire such products. Agile does not recommend having Zero documentation, but the fundamentals have always been misinterpreted and, in many cases, taken unconstructively due to a lack of proper guidance and processes. 

Another reason executives keep themselves away from Agile Methodologies is based on the principle of keeping the scope and cost of the project open. Agile Methodologies recommend that the cost and scope of an Agile project should not be fixed. Based on this principle, many executives are doubtful about what will be delivered at the end of the project after spending X dollars. 

These are a few of the many challenges presented by traditional methodologies, in addition to the challenge any organization faces by moving from an Agile to a Distributed Agile environment. The reasons for these failures are not the defined principles, but rather the independent interpretation of each one that influences how each individual tailors the methodology to his or her own benefit. This can lead product development to unmanageable disasters. My own experience with many projects that claim to be doing Agile is that they aren’t actually using the Agile way. Some have told me that they’ve been doing Agile development for years; when I asked what they are actually doing, it wouldn’t qualify as Agile Methodology.

The DH2A Methodology was developed to overcome these challenges and prevent organizations and individuals from defining their own processes for software development in an Agile approach. DH2A is a methodology for executing Agile projects in a distributed development environment.

The DH2A Methodology is compliant with the Agile Manifesto. (See Figure 1.)

The DH2A Methodology follows the Agile Manifesto by:

  • Defining the right set of guidelines for individuals and their interactions to make distributed teams successful;
  • Ensuring that working software is created at shorter intervals and defining guidelines to create the minimal and right set of documentation to make distributed teams successful;
  • Ensuring that customer collaboration is achieved completely for Distributed Agile teams;
  • Ensuring that changes may be adopted at any point and creating a plan that is useful for making projects successful.

The DH2A Methodology consists of a four-phased approach, as illustrated in Figure 2. The methodology was developed from several patterns, good practices, proven processes and procedures to make a distributed team successful in a Distributed Agile approach. 


The DH2A Methodology is based on the principles of Plan-Driven Development and the empirical process control model. It has four segments: the Appraisal Segment, Estimation Segment, Planning Segment, and the Implementation Segment. 

A Plan-Driven Development Model is defined as a development process in which a well-defined and formal approach is followed to develop an application. Plan-Driven Development mandates predictable and detailed planning, including a monitoring process to control the project. DH2A Projects follow the Plan-Driven Development Model for creating basic minimal blocks of predictable factors, which form the foundation for a DH2A project. The Appraisal Segment, Estimation Segment and the Planning Segment follow the Plan-Driven Development Model.

An Empirical Process Control Model is defined as a model in which projects are executed without a plan. The model exercises control through frequent inspection and adaptation, and provides for continuous changes based on learnings from the past. Contrast this with the Plan-Driven Development model, which mandates accurate planning and is a model that supports frequent changes to a project. The Empirical Process Control Model for DH2A projects is followed in the Implementation Segment such that the DH2A Methodology can facilitate changes in the project at any point of time. 

While planning is considered an important aspect towards project success, there is a need to support and accommodate changes in plans quickly and easily when the team is faced with new challenges and information. This is achieved in the DH2A Methodology by adopting a combination of the Plan-Driven Development Model and the Empirical Process Control Model. 

Appraisal Segment

The Appraisal Segment is based on the fundamental concept that the DH2A Methodology should be adopted in projects only if the change will provide value. 

The first Phase of the Appraisal Segment is the Value Analysis phase. This phase is used to understand the benefits an organization can achieve by adopting the DH2A Methodology.

After the benefits are justified, the next phase in the Appraisal Segment, the Project and People Assessment phase, commences. This phase assess the AS-IS project and people characteristics against the DH2A requirements. The output of this phase is a recommendation on whether or not to adopt the DH2A Methodology.

At the end of the Appraisal Segment, a project is assessed for suitability for adopting the DH2A Methodology. 

Estimation Segment

The second phase in the DH2A Methodology is the Estimation Segment. This segment is based on the concept that an Agile project can be executed in a Fixed Price Model. 

The Estimation Segment is defined by understanding the needs of a well-defined estimating model for Agile projects to execute in a distributed environment. An Estimation technique that provides ultimate accuracy and clear visibility to all stakeholders in a project is an important requirement for today’s software development projects. 

This segment defines a methodology called DH2A Spry Estimation. The DH2A Spry Estimation Methodology is used to estimate fixed costs on a project, as well as to determine the scope and time frame of the project. 

Compared to today’s Agile methodologies, which mandate that organizations execute projects with an open-ended scope, time and cost, the Estimation Segment of the DH2A Methodology provides every organization with the ability to determine the cost, scope and timeframe of a project before starting to execute it. 

For projects executing in an outsourced environment, in addition to the above benefit, the Appraisal Segment and the Estimation Segment together facilitate the bidding process. Based on the output of these two segments, organizations can select a vendor based on their experience in the DH2A Methodology and the total cost of the project. 

Planning Segment 

The DH2A Methodology is based on the principle that without the right planning, a project cannot be in accordance with established standards and is very likely to end in failure sooner, rather than later. 

The Planning Segment of the DH2A Methodology defines rules, guidelines and an approach to planning the DH2A project per the DH2A guidelines. This is considered one of the crucial segments for DH2A project success. 

The Planning Segment of the DH2A Methodology also addresses the core fundamental that requirement changes can happen at any time during the course of project execution. The DH2A Change Management Guidelines define an approach to managing requirement changes in a very systematic manner and ensure that all changes are tracked and managed appropriately. 

Implementation Segment

The final phase of the DH2A Methodology is the Implementation Segment. The Empirical Process Control Model is followed in this segment because development in DH2A projects is always unpredictable. Changes to requirements should be accommodated and can take place at any time during development. 

This segment is the core of the DH2A Methodology and is where actual development commences, based on the DH2A guidelines. Application code is designed and developed in short cycles, called iterations. Development and implementation priorities are based on business priorities. This segment mandates that business users perform complete end-to-end testing on the application, so that all loose ends are tied up and tightly integrated. 

This segment also ensures that project performance is captured using the different metrics defined by the DH2A Methodology, encouraging every project to analyze its success compared to past projects. 

The Implementation Segment introduces several concepts to minimize cultural gaps and make Distributed Agile development successful. 

The four segments of the DH2A Methodology bring together several good practices and principles of Distributed Agile development, enabling the DH2A Methodology to ensure success for all projects that adopt Agile in a distributed environment. 

The four-segmented approach of the DH2A Methodology provides every organization with unconditional control over their project development, from project inception through deployment. The Methodology also provides a well-defined approach to measuring the success of a project. 

 


This is a chapter excerpt from the just released book, “Distributed Agile,” by author Upadrista Venkatesh, published by Technics Publications LLC, all rights reserved. To receive a 20 percent discount, use the code InfoMgmtDistAgile20 when purchasing here.

 


 

 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access