Code Library

While Scrum is the project management and process side of a project, eXtreme Programming (XP) is the process or methodology for developing features and is a tool for doing the work. Let's look at XP's five values and discuss how they were played out among the case study.

• Communication: The success or failure of a team largely depends on communication. As was determined early in the case study, Sarah became a bottleneck in the process due to her domain knowledge. This was communicated by Tyler since he spoke up and informed the group he couldn't finish a story due to waiting on Sarah. This proved to be constructive criticism as they needed to share domain knowledge. The spreading of domain knowledge across the team was accomplished through pair programming. The daily stand-ups also served to bridge this communication gap between the team. By facilitating the flow of communication among and outside the team, they could determine issues and roadblocks early, move them out of the way, and continue on the path of developing value-added software to the customer.

• Simplicity: Since both Sarah and Tyler, and even Joe later on, were good software developers, they were able to communicate and brainstorm together; the outcome resulted in a simple solution. Good solutions evolve and are typically not the result of the first thought. With pair programming, programmers can consult each other instantaneously to quickly produce a simpler solution. Simplicity makes a product more maintainable in the future. You noticed that code was written only when it was needed. The team started with a framework architecture (MVC, NHibernate, etc.) that the team decided upon based on the known, high-level requirements. The first few features were spent proving and building confidence that the architecture the team built worked. Over time, the architecture emerged from the team to become an architecture that was used when needed, not a “plan” for something that didn’t even happen. The Agile Manifesto says "Simplicity—the art of maximizing the amount of work not done—is essential.”

• Feedback: Feedback came from the time and effort the developers spent writing tests so as not to break anything. The feedback loop from a code perspective using a CI server can save countless hours by providing you quick feedback as opposed to trying to fix a build a week after five developers checked different things in over the course of time.

• Courage: The team needed courage to communicate that some of the customer’s ideas on features that were out of scope. Instead of quietly going back and developing these features or gold-plating some functionality, the team had the courage to communicate to the customer that the new ideas were fantastic, but needed to be worked in because they were not part of the story. This proved the importance of determining the definition of “done” before a feature is written, so that everyone has the same expectation.

• Respect: While respect can come in many different ways, one example comes from team members breaking the build. Tyler had an issue with that early on; and while the team did not yell at him, they did bring it to his attention. Tyler began to pay closer attention, broke fewer builds, and became more respectful of the team. This openness and willingness to accept constructive criticism lead to a respectful team that could focus on work and not drama.

We started the case study with Sarah and Tyler in silos, each developing on their own. We soon discovered through daily stand-ups and retrospectives that this was not a sustainable path to continue; their different domain knowledge became roadblocks. But, through XP, two great minds came together and worked through the fear of using new tools and newly spelled-out features. This ended the selfmade silos and the team began to work more efficiently. Sarah and Tyler worked with other team members to implement features and write scenarios. XP served to improve both their skill sets as they learned new tools, and also created a greater sense of team camaraderie and trust, which ultimately contributed to a more solid and efficient team.

XP also encourages automated testing. As this case study has shown, with behavior driven development (BDD) there is a large amount of work that can be done through automated tests. Developing from the outside-in aligns the developers more closely with the business. BDD aids in bridging the communication gap between developers and the business by using SpecFlow; in this case, a business person could read the feature and the scenarios and understand what that feature is doing. That's what we want! We want to develop a code base that will stand the test of business time and not the test of code-smell/code-rot time. We can ensure this by bringing the language closer to the business, as we have through BDD and SpecFlow and, from this create automated tests so we know that when we change something, it doesn't break something else. Simplicity and reliability are attributes of code maintainability. We know that with pair programming, our process evolves to a simpler state than with a single developer. Code is more reliable due to automated tests. The cost of later adding a feature is dramatically reduced because the next developer can be confident that when he changes an existing feature or adds a new feature, he won’t break existing functionality.

Source of Information : Pro Agile .NET Development with SCRUM