This article is a personal interpretation of the CA Technologies white paper:
The Impact of Agile. Quantified

The paper hits the ground running with the first sentence, "Agile and lean are built on a foundation of continuous improvement: You need to inspect, learn from and adapt your performance to keep improving.". In my experience, when most software professionals hear the word 'Agile', it is interpreted internally as a dirty word. It translates into traditional factory worker management techniques plus the overhead of Scrum rituals (#scrumfall).

The paper is a summary of data from many agile projects and teams. The data is correlated to four dimensions: Responsiveness, Quality, Productivity, and Predictability.

Team Stability

The first measurement discussed is the allocation of an individuals time to a particular team.

I once made a joke in a floor wide meeting that:

you can split a cookie in two and you have to equal halves of a cookie... if you split a person's time in two, you get just a shit cookie

This report seems to make the same statement, but with the data to prove it. Stable teams with fully dedicated team members is a clear competitive advantage.

The stated recommendation for team management is:

• Dedicate people to a single team
• Keep teams intact and stable

Scrum + Estimations

The next section discusses the correlation of levels of Scrum adoption and quality.

The data is broken into four groups: Full Scrum, Lightweight Scrum, No Estimates, Hour-oriented

I personally am a fan of the no estimates movement, but this data shows this a lower quality venture in comparison to more traditional story point estimation and task break down techniques.

In my view, there is a logical progression of how teams estimate and plan work.

• At first a team does what it is used to, estimate in hours
• Then adoption of scrum by the book - shu
• Once estimation and tasking has become a routine practice, then lightweight scrum ensues where the team is able to properly plan a sprint with only the high level estimate in mind - ha
• Finally, as a scrum team begins to approach a flow state, maybe moving towards Kanban, then the no estimates becomes a viable option - ri

Skipping a step in this road towards mastery will surely lead to a lower quality product.

WiP

Careful management of WiP limits leads to reduced time to market and less defects. At the same time, a low WiP leads to lower productivity. IE, less get's into the system, but it tends to be available sooner with less defects.

Little's Law is mentioned: L = λ W : Cycle Time = WiP / Average Completion Rate

This makes intuitive sense. The more focused you are on a few things, the quicker you’ll get each one done. If your WiP is high, reduce it! Don't push WiP too low!

Team Size

I am a huge fan of team size theory. Fewer individuals on a team means, less lines of communication, which in turn leads to a higher potential productivity as there is less overhead to manage the communication channels.

Scrum recommends that teams size be seven plus or minus two. Data from this report reflects the above statement with one caveat. Teams with 5-9 have the most balance performance. Teams of size less than or equal to four are lightning fast, but tend to have a lower quality bar.

An interesting part of this survey states that organization size does not matter. Typically, organizations tend to make teams in its own image (big org, big teams).

Iteration Length

Typically, shorter iterations lead to higher productivity and responsiveness. Two weeks seems to be the industry standard at this point. One week has comparable predictability, productivity, and responsiveness, but a lower quality score.

Ratio of Testers to Developers

Solid technical excellence has a higher impact on quality than the number of testers on a team. Teams with no testers have the highest productivity, similar quality but at a much wider variation.

My assumption for this data is that the result in quality variation is dependent upon the maturity of the team's technical excellence. A pair programming team that practices TDD will have a higher quality bar than a working group full of cowboys.

Retrospectives

IMO, one does not be 'the Agile' without retrospectives... much of the agile world is built upon continuous improvement.

"Teams that strongly agree that they have sprint retrospectives have 24 percent more Responsiveness and have 42 percent higher Quality with less variability." It's hard to deny that retrospectives, with the ability to course correct as a result, is the core tenant that makes agile shine above other software development life cycle methods.

A side note, an hour to two hour bitch fest does not equal a retrospective. The decompression from a difficult sprint often leads to an ineffective retrospective, but these should be the exception, not the rule.

Motive

Overwhelming evidence proves that companies that practice agile development practices have a significant market advantage over traditional heavy weight processes (waterfall). Regardless of the motivation behind a company's reason to adopt agile, executive support (and executive agile fluency) is absolutely critical to the success of an agile adoption/transformation within an organization.

Summary

To an avid Agile practitioner, these findings align with most widely adopted agile techniques. It's interesting that this report did not touch into any of the various explicit flavors of agile! Instead, by focusing on the a select few of the pillars that most (all?) agile frameworks subscribe to, the CA group was able to create an objective report that defends the importance of each.

Team stability and size has been a personal battle of mine; losing/adding a team member makes a new team. In addition, the importance of limiting WiP (to decrease cycle time) and need for effective Retrospectives is fundamental to harvesting the true value of what it means to be Agile.