Exercising Test-Driven-Development with a Scrum team

I quite recently exercised TDD with a Scrum team and blogged about it to Huitale blog.

There is on-going controversy about Test-Driven-Development (1, 2) but instead of reading about it I suggest everybody to try it out and then judge if it is good for you or not .. and then share your experience with rest of us :)

A Kickstart on Scrum

You probably have tried to implement new processes before. Scrum is not a new process or methodology, but instead a workout procedure, set of rules or game to improve the enterprise. Furthermore, Scrum is simple enough to understand from books (this text is a summary from Ken Schwaber's book The Enterprise and Scrum).

The initial adoption of Scrum may not be perfect, but it is self-correcting. You teach everyone how to play the game of product development using Scrum. This means teaching them how to work together in small teams. This first stage takes six to twelve months. The second stage is when everyone in the enterprise improves their game. To get really, really good requires three to five years of continued improvement through using Scrum in an enterprise.When Scrum projects get going, conflicts occur as people and organizations disagree on the best ways to do their work. If not rapidly solved, conflicts become conflagrations that destroy productivity. The Scrum paradigm embraces change, unpredictability, and complexity as inescapable constants in all product development. While Scrum perfects itself, the problems are being addressed. You will clearly know the progress of the project and Scrum affords complete transparency. Everything is visible. In addition, you will see increased productivity.

Example Case

Adventure Works, a game producer in San Diego, was the first in its industry to benefit from Scrum. Joris Kalz, Adventure Works' CTO, attended one of the very first Scrum certification sessions in 2003. Enthusiastically, he went back to Adventure Works and adopted the Scrum paradigm. His story is one of insight, persistence, and hard work. The Adventure Works story is one of culture shock and then redemption.

The product that was developed using Scrum was Vosod. It began to emerge in high-quality, regular increments. Joris adopted a sustainable pace of work, one of Scrum's practices. Everyone worked eight-hour days. Some people might look at that practice and think, "Oh, that means developers get out of working hard for the company!" Quite the contrary—a sustainable pace yields higher productivity and quality products.

Adventure Works was owned by a Japanese company. The Scrum practice of eight-hour workdays was unacceptable to the senior members of the Japanese management. They demanded longer hours, and the 12-hour work days that were normal prior to Scrum were restored. Defects rose 60 percent over the next several Sprints, more than offsetting the delivery of increased functionality. Joris restored Scrum's eight-hour workdays. When the Japanese managers in San Diego drove by the offices night after night, they again saw empty parking lots and darkened offices. This was intolerable to them. They reported to headquarters that employees at Adventure Works were indifferent and lazy. They recommended selling the company. The delivery of increments of high-quality software was good, but that was insignificant compared to the perceived sloth and cultural conflict.

The Japanese parent company sold Adventure Works to its American management in a management buyout. The parent company was glad to get rid of it. Two months later, Vosod was completed and ready to ship. Adventure Works sold Vosod to a game publisher for twice the price of the buyout. Did it make sense for the Japanese owners to sell the company when they did? Of course not, but the twisting paths of change often don't make sense. People and culture are involved—people who have feelings, beliefs, perceptions, and vested interests that cloud their perceptions.

Players of Scrum

The Product Owner is the most senior executive in the enterprise. A Scrum Product Owner is responsible for directing the work of a Scrum team.

The ScrumMaster holds the team together and keeps it going using Scrum. He or she is the person responsible for the Scrum process being used correctly.

The Scrum team commits to a goal every iteration, or Sprint. The team members work with each other and do whatever is necessary to reach that goal. The team is a single entity and manages itself – all Scrum teams are self-managing. The teams manage themselves to build the Product Backlog and reach the goals. Team members need to trust each other to effect change, and they need to be ready to openly have conflict to reach the best solutions possible. Focus on proggress – even though there are always many things to improve, look back and savor the accomplishments already being made.

Scrum Tools

Product Backlog is a prioritized list of work that needs to be done, controlled by the Product Owner (i.e. Customer).

A Sprint is a block of time (usually 10-30 days) in which development of software is completed.

Sprint Planning Meeting The sprint planning meeting is time boxed to 8 hours and consists of two segments that are time boxed to 4 hours each.

Daily Scrum A daily meeting at which the Scrum Development Team gathers to inspect its progress toward the Sprint Goal to adapt its work and optimize its chances of building everything committed to. The meeting is time-boxed to 15 minutes, during which each team member answers the following three questions: ”What have you done since the previous daily scrum?”, ”What am I going to do today?”, and ”If there is anything impeding my work, what is it?”

Daily Scrum of Scrum When multiple levels of scrum teams exist, the lowest level Daily Scrum is called S1. The next levels are called Daily Scrum of Scrum S2, S3, and so forth. At the component level (S1) and activity level (S2), the Daily Scrum of Scrums are indeed held daily. On higher levels the meetings are held less often; twice a month or once a month.

Sprint Review Meeting The purpose of the sprint review is for the team to present to the product owner and the stakeholders functionality that is done.