Bill Dickenson, Independent Consultant, Strategy On The Web

In most commercial environments the developers are distributed — rarely occupying the same physical site and often on very different hours. Faced with this reality, AGILE struggles. In the 12 principles from the “Agile Manifesto” is the principle that “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” This is clearly true and taken as a fixed principle, would rule out Agile for remote teams.

Research from CISQ (Consortium for IT Software Quality) has recently evaluated the effectiveness of software teams using Agile as well as Waterfall and found a surprising result. While both Agile and Waterfall produced quality software, organizations that used both methodologies produced higher quality software than organizations that used exclusively with one or the other. This opens up some interesting approaches for Agile in a distributed environment.

Start with the Right Projects

In general, Agile is best suited when the requirements are too high level or unclear to benefit from a more rapid, iterative approach.One approach that successful companies have used is to separate the well-defined, and clearly documented changes from those that benefit from the interactions that Agile provides.

Smaller Work Packets

One of the strengths in Agile is speed to value. The smaller the project the more likely it is to deliver the value (Capers Jones). Agile work packets should be small enough to be completed as quickly as possible, and if the organization is moving to DevOps, released to production as soon as practical.  Understand the problem clearly. Resist solving the problem until you understand the problem that needs to be solved.

Form Consistent Teams

Creating a team requires more than physically grouping developers together. Organizational dynamics dictate that even high performing individuals need time and practice to be a team. Create some stability by naming teams in advance and find ways for the group to interact. A trip to a common location tends to jump start team dynamics. The goal is improved communication and communication becomes far more effective when the team has a level of trust. Chances are that at some point, one of the team members will talk to the business about a function worked on by a remote member. Trust makes that process smoother.

Create a Team Room

Teams need persistent communications. Shared team rooms help make that possible. Many allow a full spectrum of common notes, virtual post its, drawings, etc. that rival a live team room. At some point everyone will be remote and these need to be as robust as possible.

The business users should be included here as well. The “community” of people who have an interest in the results of this change should be included. One highly successful remote Agile group borrowed the rules from an online university with required posts, answers and instructional techniques. As a side note, many of the “problems” the team was asked to solve were solved by other members of the business community who just had not talked to themselves. Communities are a major source of business effectiveness.

Include some “personal” space here as well for non-work related posts. Teams have common interests outside the project and again, the more these are used, the higher the trust.

Defect Free Code

Inexperienced Agile teams tend to lump bugs and defects into the same “group” and then hide behind the “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” while ignoring the “Continuous attention to technical excellence and good design enhances agility” principle a few items down.  Defects are the measure of technical excellence and Agile teams need to understand, adhere and be audited on compliance. Few issues destroy business value and credibility more than defects in code. 

Consider the following benchmarks for quality:

1) Security violations per Automated Function Point: The MITRE Common Weakness Enumeration (CWE) database contains very clear guidance on unacceptable coding practices that lead to security weakness. In a perfect world, delivered code should not violate any of these practices. More realistically, all code developed should have no violations of the Top 25 most dangerous and severe security violations, 22 of which are measureable in the source code and constitute the CISQ Automated Source Code Security Measure

2) Reliability below 0.1 violations per Automated Function Point: In any code there are data conditions that could cause the code to break in a way that allows an antagonist to gain access to the system. This can cause delivery failures in the expected functionality of the code. Reliability measures how well the code handles unexpected events and how easily system performance can be reestablished. Reliability can be measured as weaknesses in the code that can cause outages, data corruption, or unexpected behaviors. See the CISQ Automated Source Code Reliability Measure.

3) Performance Efficiency below 1.0 violations per Automated Function Point: Performance Efficiency measures how efficiently the application performs or uses resources such as processor or memory capacity. Performance Efficiency is measured as weaknesses in the code base that cause performance degradation or excessive processor or memory use. See the CISQ Automated Source Code Performance Efficiency Measure.

4) Maintainability violations below 3.0 per Automated Function Point: As code becomes more complex, the change effort to adapt to evolving requirements also increases. Organizations that focus on Maintainability have a lower cost to operate, faster response to change, and a higher return on investment for operating costs. It is important that code can be easily understood by different teams that inherit its maintenance. Maintainable, easily changed code is more modular, more structured, less complex, and less interwoven with other system components, making it easier to understand and change, conforming to “good design enhances agility”. See the CISQ Automated Source Code Maintainability Measure.

Feedback

Most Agile shops are familiar with the traditional burn down charts, user acceptance of the functionality delivered, time and productivity measures. All Agile teams should incorporate the quality measures above as well as a tracking across time. Teams function best when the feedback is unambiguous and frequent.

Conclusion

Agile is a powerful tool that can enhance the time to value in many organizations. These principles will guide an organization to finding the benefits of Agile while taking advantage of the best available resources globally. The extra effort in planning and execution pays off with better software and business value.