Agile Coaching


Software teams all want to be agile. Who wouldn’t? Everyone seems to know and like the Scrum methodology. However, teams that implement Scrum often don’t see the performance improvement they hoped for. This is because Scrum does not speak to some of the most important development practices that high performing teams employ:

  • Continuous Integration
  • Test-Driven Development
  • Refactoring
  • Pair Programming
  • Collective Code Ownership

These engineering practices are a big part of what makes agile software development effective. However, they are difficult to implement, especially if the team does not have that experience already. An Agile Coach works with the team and shows them how to do it.


Eric began developing software in an iterative, incremental manner in 2000. He began using eXtreme Programing techniques of story identification and Test-Driven Development in 2004. He experimented with team rooms and pair programming in 2005. In 2007, Eric transitioned from a being user ofVersionOne to joining the VersionOne development team (one of the best agile teams developing one of the best agile management tools).

Case Study: Introduction

In 2008, Eric took on the challenge at his current company. The company’s current technology platform was in need of a replacement. The development organization’s only experience was with a proprietary, non-object-oriented language. The team had been introduced to the Scrum methodology but had not been able to implement it effectively, lacking the engineering practices listed above.

Eric’s primary role was to provide technical direction in the development of the new product. However, a key to the company’s success would be the transformation of the development organization. The organization would not be able to effectively build the required enterprise-class product without a significant shift in skills and approach.

Case Study: Training

With some help from another senior developer, Eric designed and led C# training class, emphasizing object-orientation and TDD. Through the training, in workshop format, the developers iteratively and incrementally built an application by expressing the stories I provided in tests and made them pass. At the end of the eight weeks of training, not only did they have a solid foundation in TDD, everyone on the team made above average scores on the BrainBench C# exam.

Case Study: Building the Team

The new product team would be built up from some existing developers who had experience with the older platform and few developers hired from the outside. As i interviewed potential developers, we looked for people who were well established in the agile practices we were trying to implement and could pass those skills on to the developers who were new to them. The key component of the interview process was the ‘audition’ where they did some pair programming to solve a problem. This allows us to assess how they would work within a team and with the other developers.

Early on, we made sure the developers who were new to C#, object-orientation, and agile practices were always paired up with myself or one of the other developers who were more practiced in these areas. As these developers faced various problems in their day-to-day work, they learned how we solve them, applying the various principles we want them to learn (SOLIDDRYYAGNITell-Don’t Ask, write the  failing test first, etc.).

Case Study: The Product

The product we built had its own unique demands. The most daunting was fact that it had to be a fully functioning application (and not a toolkit or framework), but that the actual functionality would differ with the various clients who purchased and deployed it. In the past the company would build each solution from the ground-up to meet the needs of each client. This didn’t scale well.

To accommodate these requirements, we built a loosely coupled, composite application. This allows the various components that make up the application to be replaced. This was accomplished with patterns such as an Inversion of Control (IoC) container that binds implementation at run-time and an Event Aggregator that allows events within the application to  be responded to in different ways in different applications.  This modular approach also isolates dependencies and makes for code that easy to test with unit tests.

The goal for the first implementation of the product was to have 70% core product code and 30% customer-specific code. We were able to go live with 95% product code and only 5% customer-specific code.