To help some peers advocate for agile adoption, I prepared an experience report to demonstrate how my old team benefited from XP and Scrum practices. This is an extension and refinement of an earlier post on the benefits of XP.
Team Cohesion
Before and during our agile adoption, I informally administered the Gallup Q12 employee engagement survey. It is composed of twelve simple questions. Agreement correlates to retention, customer loyalty, safety records, productivity, and profitability.
From the beginning to the mid-point of our adoption, staff went from a response rate of 70% agreement 30% disagreement to 80% agreement, 15% neutral and 4% disagreement.
The most improvement was in daily opportunities “to do my best” and daily feedback on performance and expectations.
I’m convinced if I had administered the Q12 late in our adoption, we would have had even better results. The key un-addressed concerns were about having a best friend at work and feeling connected to the mission of the company. By 2007 our team grew to include people brought in by personal recommendation of other members of the team and our portfolio included consumer facing work directly for our CEO.
Rather than re-take the Q12, we undertook a 360° performance review. That we did this on our own initiative shows just how much trust we had built with each other.
Test Coverage/Code Quality
XP practices enforced methodical unit test coverage, mutually arrived at coding conventions, and real-time code inspection by multiple members of the team. The team went from no unit test practice to comprehensive coverage over the business logic and controller layers. (Unit tests against data access and gui were less comprehensive. I don’t intend to get in the middle of that debate here.)
XP and Scrum force conversations between the development team and product owner that incentivize all to build quality into the software rather than allowing technical debt to accumulate and relying on downstream QA process to fix the application.
In 2006-2007 there were no business impacting failures of our internally authored software. We were able to function as a project team with no dedicated developer maintenance staff. Change requests were minimal enough that we were able to prioritize them into our project sprints as overhead.
Reduced Risk
While any team has experts, “Agile” practices reduced our reliance on “specialists”. The entire team was capable of working on and maintaining any aspect of the code base. We passed the “bus test”; despite our small size, no project was at risk if any given member of the team became unavailable.
Leadership
Our team raised our skills and began contributing to our field. We write, present and teach at conferences on topics of scrum, XP and platform as well as contributing to open source projects and developer knowledge bases.
Recruiting and Retention
After establishing “Agile” practices we recruited skilled candidates from higher paying positions who desired to work in our culture and with our practices. We received inquiries from as far away as South America and Europe. Despite the reputation of our team and market demand we retained staff.
An additional benefit is that pairing provided an efficient on-boarding process for new hires. Developers joining the team provided immediate contribution. A metrics-based way to demonstrate this is to show that sprint commitments weren’t affected new hires first weeks. I observed that but mainly base this on comments from the team lead and existing members of the team.
Workplace Diversity
Agile values and practices support a collaborative, empowering and sustainable work place. Such environments support diversity and take advantage of the breadth of experience each worker represents.
Client Satisfaction
We asked for quotes from our clients, vendors and even competitors which we included in our budget presentations (I’ve pretty aggressively scrubbed them):
“Working with the agile Software Development team has been rewarding on many levels…it’s a team that celebrates creativity, organization, listening, feedback, openness, honesty…and is proof positive that a great process results in great product. I look forward to our very regular meetings (I even readjust my travel schedule as much as possible to not miss anything) and am never disappointed. They are an engaging and engaged group of individuals.” – CEO
“[____ saved] half a head in [another team] and a full head in my team.” – VP
“The _______ written by our development team are the guiding-light to our decisions. [third party solution] has a vast wealth of information but no good reporting and our in-house [solution] enables us to divine meaning from the mountain of data.” – VP Traffic Operations
“We also use [third party solution] for all of our broadcast networks but I have heard about your software technology for ____. We currently do that through manual operators but I’d like to understand how you do that more sometime and how it works…” – Senior Executive, Competitor
“Given the complexities of ____ that includes the combined limitations of automation, graphic and traffic systems I believe [the team] has created a solution that has proven to be much more capable than most systems than I’ve worked with.” – Vendor
Frequent Delivery, Adaptability
Throughout 2006-2007 our team of 3-8 developers balanced two simultaneous lines of work on diverse projects built in Microsoft Windows Forms, ASP.NET to SQL Data Analysis Services Data Warehouses, Vista compatible Windows Presentation Foundation and XAML, open source .NET MVC frameworks and Ruby on Rails including a rich windows application built on beta Microsoft Technology.
The team completed eight IT and three consumer projects while doubling head count from 5 to 10 (+2 contractors). We initiated our consumer product initiative and achieved our first release of a rich windows application with a six month allocation of effectively 1.5 – 2.5 developers.
Invention/Innovation
Agile practices evolved from Lean management and associated knowledge creation theory. In this, it shares ancestry with Six Sigma.
Agile is based on empirical not plan-driven process control. It is closer to lean product development than lean industrial manufacturing.
Our consumer product was recognized for its design and implementation by Microsoft’s platform and developer evangelist team as well as by the WPF team. It achieved high ratings in usability testing with end users (avg rating 8 of 10) and showed potential to deliver on its revenue targets.
In my business context, I can’t cost-justify the kind of measurement Jeff Sutherland illustrates in his 
The types of people who seek out a pairing environment are social, take initiative and want to engage in the big picture. These types of developers create a vital workplace and contribute more fully to product development. I’ve written several papers getting at the relationship between collaboration and innovation.