Completing eXtreme programming with ScrumIn­depth study in Coaching of programming teams 2014

Lund, 140303

Joakim Ahle, ada09jah@student.lu.seJesper Lekland, ada09jle@student.lu.se

1

Abstract

This report will cover our conclusions from applying Scrum on a small software development team that uses eXtreme programming. XP and Scrum covers different aspects of the development process and we want to investigate how Scrum can address some of XP’s limitation. The report will, besides our conclusions, explain the methods we have used and how we have modified those to suite our needs. Our roles in the team is a mix of Scrum Master / Project Owner / XP Coach.

2

Table of contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Background

2.1 What is Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 What is XP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3. Sprints

3.1 The planning session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 The programming session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4. The role of the coach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3

1. Introduction

Coaching of programming teams (EDA270) is a course for master students at the computer science program at LTH. The course cooperates with another course, Software developing in teams (EDA260), which is mandatory for all students in the second year. The layup is simple, the older students team up in pairs and coach the younger ones in teams of 8­10 students. The coaching students write an in­depth study (the one you are currently reading) in parallel with coaching the teams. The coaching students chooses an aspect of agile development methodologies for the in­depth study and then experiment with their team.

If companies decide to go agile, most of them choose to use Scrum. Scrum is mostly focused on the managerial part of agile development and many companies disregard the other agile methodologies completely because of Scrums popularity. However, if a company decides to use XP instead, they face the problem with the “on­site customer” and the fact that this is almost never possible. In scrum, this is circumvented since the ‘Product Owner’ represents the customer. This paper strives to determine, for each release, if the productivity of the team increases without compromising the quality of the system, when we have a full time member of the team who handles the customer contact instead of a drop­in customer. The team is presented with real ­time SCRUM statistics to examine how this affects the teams morale and productivity.

Our hypothesis is that the productivity of the team is greatly increased when having a customer representative instead of a drop­in customer and that the team will benefit from seeing, for example, the finish projection from the burndown chart in real time, this can be seen in appendix figure 1 & 2.

In this particular setup, changes are made to both XP and Scrum to fit the workflow of the course EDA260. Every monday, the team spends 8 hours developing their product, and the planning session is held every wednesday for two hours. The changes will be presented in the Sprints section.

4

2. Background

2.1. What is Scrum?

The following explanation of Scrum is taken from Ken Schwaber’s “The Scrum guide”.

Scrum can be described as an agile method, like XP and Lean, but focuses more on the administrative part of development. Scrum aims to deliver products of the highest possible value.

In Scrum, the team works in sprints, which is a fixed period for time, where stories to be implemented can be found in the sprint backlog.

In a Scrum team, there are three different roles to play: Product Owner, the Development Team, and a Scrum Master. How these are used in our experiment is described in the role of the coach section.

The Product owner’s most important job is to maintain the product backlog. The product backlog consists of every story that should be included in the product, in other words, a combination of all the sprint backlogs.

The Scrum master is a (certified) member of the team who has a lot of experience with Scrum who teaches and makes sure the Scrum practices are followed. The Scrum master can also be part of the development team.

A scrum consists of four events: Sprint Planning Daily Scrum Sprint Review Sprint Retrospective

During the sprint planning, a number of stories is added to the backlog of the next sprint. Which stories should be in the backlog, is determined by estimation and prioritization.

The Daily scrum is a meeting held in the beginning of every day and is meant to synchronize the teams work in terms of what have been done since the last daily scrum.

The sprint review is held after each sprint and aims to revise the product backlog with the result of the sprint.

5

The Sprint retrospective is an event where the team reflects on how they can improve in terms of collaboration and productivity and presents an improvement plan.

A core artifact in Scrum is the definition of done. The purpose of defining done is so that every member of the team agrees of when a story is really done. This definition may vary between different teams. [1]

There are a few reasons why we think that Scrum is the most used method for companies. First, it’s possible to get a certified Scrum master and/or product owner and large companies like certifications. Secondly, Scrum is very agile from a customer’s point of view, which is the most important part. Also, it’s a lot harder for a company to implement full XP than full Scrum, since XP requires pair programming. A few companies use Lean, but it requires a very different attitude from team members, managers and directors.

6

2.1. What is XP?

eXtreme programming, hereby referenced to as XP, is the original agile method for software development. It was designed for small teams who deliver products with ever­changing requirements. The following facts about XP comes from Extreme programming explained, by Kent Beck.

Extreme programming aims to aid the team with five values: Communication, respect, feedback, courage and simplicity. These are achieved through several practices, here we choose to list the most important ones for our team:

Pair programming. Programming is always performed in pairs. One developer writes the code (the driver) and the other (navigator) inspects and help the driver.

Continuous integration. Releases are made every day and it should always be possible to build the system directly from the repository.

Simple design. Simple design refers to that the solution should always be the simplest and easiest to understand solution.

Planning game. In the planning game, the stories that should be implemented during an iteration is estimated and prioritized by the customer.

Test driven development. Test driven development helps the developers design their system by writing simple unit tests that explains how the system should work. The tests are written before the actual code.

Clean repository. Clean repository aids the continuous integration, since it’s not possible to build the system if the code in the repository don’t work.

Collective code ownership. Collective code ownership refers to that no one is alone responsible for a piece of code. If it’s in the repository, the whole team has agreed that it works as expected.

Iteration 0. Before the iterative process of XP can begin, a 0’th iteration needs to be created. This is typically a stable ground that is hard to implement by several pairs in parallel.

Refactoring. When the code has become a mess, it must be cleaned up. Refactoring helps maintaining a simple design for the system. If the customer approves, whole stories can be just for refactoring old code.

7

On site customer. The customer should always be on site so that the developers can ask him question about the stories.

Team in the same room. To help the team communicating, they should all sit in the same room, at the same time.

In XP, you try to share a knowledge base with the whole team, so there should be no specialist in for example sockets, who writes all the code regarding network communication. Instead, he pairs with other team members to spread his knowledge.

To ensure that XP is followed, XP teams have a coach. The coach may or may not be part of the development team. [2]

8

3. Sprints

3.1 The planning session

During the sprint planning meeting, the team has to decide which stories in the product backlog should go into the sprint backlog. [3]

The process for our team is slightly different, since there is no complete product backlog to choose stories from. Instead, we are given new stories every week. Although, this makes it easier since we know that the new stories are added to the product backlog and the set of stories to choose for each sprint is more limited.

Each team member gets a small spike to read up on the new stories before every sprint planning meeting and make a pre estimate on how long they think it should take to implement. On the meeting, their estimations are discussed until they have derived a final estimate. This is to shorten the time of the meeting.

A sprint is usually at the very least two days and at most six weeks. Here we have also made small changes with one day sprints.

9

3.2 The programming session

The typical programming session starts with a Daily Scrum. Since we use XP’s pair programming, each pair is given a story from the sprint backlog to work on in the daily scrum meeting. Since each sprint is only a day long, and that the XP practice “team in the same room” is used, there is no need for a long synchronization of what everyone is doing. We assume that this is used mostly when the team members don’t work with XP as well.

To aid the team, we present real time statistics from Scrum, the Burndown chart, which projects the time at which all stories in the iteration are done.

During the session, XP takes over as the mainly used method, this because XP dictates how the team should implement the stories, not how to structure the planning. The team practices TDD, continuous integration, team in the same room and all the other practices listed in the “what is XP” section. A nice picture of the development room is shown in figure 1 below.

Figure 1. Team in the same room, Kanban board, public computer

10

4. The role of the coach

As coaches for the development team our role is quite apparent. Our main purpose is to structure the work at hand and make sure that the team is always on track and that they adhere to the practices mentioned in both the Scrum and XP part previously. We do however take a more extensive coaching role in this particular project since we declared ourselves ‘Product Owner’. This means that we are the “voice of the customer”. Contrary to XP’s ‘customer on­site’ where a representative from the customer is available for feedback and questions throughout the development process a ‘Product Owner’ is often a part of the development team. The product owner has the knowledge to know what the stakeholders are asking for and is always available to the team for questioning and direction. [4]

As we enter the role of product owner we give ourselves the tools for a more fluid development process without the need for a customer on­site. This however was not our initial thought.

We started out as “normal” XP coaches, leading the planning meetings and making sure that the programming sessions went along according to plan. To ensure that the team always got the ever so important feedback a burndown chart was placed on a constant­on monitor in the room.

This monitor displayed real­time information about what stories were under development, the prioritization and estimation of stories, who worked on what and also a burndown chart of the sprint remaining effort, see appendix figure 3 & 4.

Again, since this is is a university course, everything doesn’t work lite at a company. As coaches, we met with the customer once every week, and he gave us a new set of stories to implement. This means that there never were a product backlog. Instead, we can see this as if the inclusion decisions were made then and there and not on the sprint planning meeting.

11

5. Conclusion

After a couple of weeks a few things became apparent to both us and our team. Everything about the development is customer centric. It’s what the customer wants that drives the entire project from start to finish. How is it then possible to know what the customer really wants, when he/she is not there to answer questions whenever they may arise? The agile way of developing needs constant feedback and therefore demands someone with the knowledge of the customer to be available on site.

The sprint review and sprint retrospective became more or less the same thing during this project, for obvious reasons. What became apparent was that all data is good data. As coaches, we kept track of everything that happened during the programming sessions from who implemented what, how long it actually took to implemented, test coverage, number of pair switches, pretty much everything. A excerpt of this can be seen in appendix ­ figure 3 and 4.

This data was presented during the beginning of the planning meeting, a.k.a the sprint review. The team started of questioning why all this data was needed but quickly came to terms with the importance of knowing as much as possible ­ knowledge is power .1

Much of the teams success can be credited to the fact that we managed to jell extremely quickly. We, as coaches, decided to have a very laid­back and friendly attitude to all of our team members, make friends with them and they will make friends with eachother. In the later part of the projects the team became like a small family and everyone was comfortable to make jokes, start a conversation and even sing out loud in pure joy on completing a difficult story. This made it extremely pleasant for our team to work together, even as problems arose.

We made sure that no individual was blamed for a malfunction. Even when certain members of the team pointed out that it was somebody’s fault we made sure to point out that collective code ownership makes sure that everybody holds the same responsibility to keep the repository green and up and running.

When problems did happen and stories began to jump up on down on the kanban board [5] we made sure to address these problems as quickly as possible. We did however decide to address all problems with a good attitude, a friendly nudge in the right direction, to make sure that no team members felt discouraged.

As concluded from our sprint retrospectives, our hypothesis was right: The productivity of the team was greatly increased when there was a product owner, always on site instead of the customer. Before we

1 Knowledge is power is a quote by Sir Francis Bacon, it is from Religious Meditations, Of Heresies, 1597. Sir Frances Baconwas an English author, courtier and philosopher(1561­1626)

12

switched roles, the customer appeared in the development room about five times a day. At many of these occasions, the team’s questions were already forgotten.

As for the real time statistics part, we noticed that the team did not benefit as much from it as we had hoped for. This is possibly due to that the sprint length is only one work day. If we had sprint lengths of 2­6 weeks, the team could change their pace and actually make a difference in the implemented stories. It was also hard for us to push their productivity with statistics on implemented stories, since we knew this is a learning oriented project. The number of stories in the final product is not as important as learning how to work as a team.

Of course, this could also be a problem with Lencioni’s five dysfunctions of a team. One of the dysfunctions are “inattention to results”, which could be the case for our team. If this is actually a problem, it could mean we have a problem in the foundation, “absence of trust”. Although, we think that the inattention to results is more a question of bad presentation of the results. [6]

However, the use of a Kanban board provided both good statistics and excellent feedback for the team. It’s a fantastic feeling to move a story from “Todo” to “reviewing” or from “reviewing” to “done”.

As questions arose regarding the stories a need for quick feedback from the customer became apparent. The customer on the other hand had other matters to attend to and seeing how we, as only coaches, did not know what the customer wanted the teams work stagnated as they did not know how to proceed. Once the customer actually showed up the questions were often forgotten or an ill fated attempt at guessing what the customer wanted had wasted the teams time and effort.

Not being able to tell the team what we knew the customer wanted (simulating the XP coach) quickly became frustrating and we knew that this would have to change. After exchanging a few words with the customer, explaining how he should now take the role of a stakeholder instead, we became the new voice of the customer. We could now quickly answer the teams questions, providing quick and correct feedback. If we did not know the answer to the question we could quickly contact the customer to find out, without distracting the team from the work at hand. This greatly increased the workflow of our team and kept their spirit high.

From the Sprint retrospectives, we got a few comments from our team on how they reacted to the change of their coaches to product owners (in swedish):

13

“Kundsamarbetet blev mycket bättre när våra coacher tog över. Oftast hade man många små frågor som behövdes just då, men som tog lång tid ifall man behövde den riktiga kunden.”

“Kundsamarbetet är medelmåttigt. Vi pratade med kunden endast då vi verkligen, verkligen har något som vi inte kunde besluta oss om. Det är också en svaghet då kunden kommer in ytterst sällan i vanliga fall så hinner man glömma bort frågorna vi haft till kunden kommer.”

”Coacherna som mellanhänder till kunden gjorde även att det blev mycket lättare att direkt få feedback på projektet.”

As more traditional programming coaches we did our best to support the team and make them independent of us as much as possible. After a few weeks our involvement grew less and less and the team did everything we could possibly wish for. Stand­up meetings occurred a lot more frequent than we originally expected and communication was never a problem.

Iteration Hours of completed work

1 32

2 13

3 15

4 28

5 26

6 28Figure 2. Completed work per iteration

From the fourth iteration, we took the role as product owners in the projects. The hours of work completed is shown in figure 2 shown above. We can see that after iteration four, the work rate of the team increased. The exceptions are iteration 1 and 6. In iteration 1, the story had extremely low complexity and the team’s estimations were very high. During iteration 6, a lot of focus were on the final release and stories had to be compromised. Despite that, we had the highest productivity during the project.

14

6. Appendix

In this section, we present charts and tables showing the team’s work.

Burndown charts:

Figure 1

Figure 2

15

Story Tracker:

Figure 3 ­ What stories to be implemented, who works on them and current status

Team pairing sheet:

Figure 4 ­ Amount of times the pairs have worked together

16

7. References

[1] The Scrum Guide; Schwaber, Sutherland 2013

[2] Extreme programming explained; Beck, first edition, 1999

[3] Scrum and XP from the trenches; Kniberg, 2007

[4] Agile project management with scrum; Schwaber, 2004

[5] Kanban and Scrum making the most of both, Kniberg, Skarin, 2010

[6] The Five Dysfunctions of a Team; Lencioni, 2002

17