How we do this - process

I get a lot of questions about how we do this project. I’m going to start with describing the process in this post and am already preparing a follow up about the actual development. Comments and questions about our process are most welcome, but if it’s something about the development you might be better off wait for that post. That being said, here’s how we do it, the process part.

Our cycle (re)starts on Thursdays. Each Thursday before lunch we meet our customer to make sure we're on the right track. Since we have decided on two week iterations, every second Thursday we first have a sprint demo and then (re)prioritize all remaining stories in the backlog. The other Thursday we just discuss issues from the first half of the iteration and status of other ongoing tasks - i.e. stuff that people outside the team are doing. That may be setting up the production servers in the customers’ environment for example.

On the sprint ends we have a retrospective where the whole team, except the customer, get together and discuss the sprint. At first we had it before the customer meeting with the demo, but we always had to rush it in the end to get done before the customer came. Once we invited the customer to join or retrospective, but since the involvement during sprints is so low the customer didn't have much to say. Hence we decided we'd keep doing without and moved the retrospective to after lunch. The time before the customer arrives we now use to prepare for the demo.

The next step in the process is the task breakdown of the top prioritized stories. We get the whole team together and the Interaction Designer, who has somewhat the role of the on-site customer, will walk us through the stories and show the prototype. We take the the stories one-by-one and after the walkthrough we break down the story to tasks. When the breakdown is complete we play Planning Poker to estimate each task in measure of days, with half a day being the lowest estimate. Tasks a lot smaller than that we try to merge together.

When we had the retrospective before lunch we had task breakdown after lunch. I felt we needed some more slack to really end the first sprint before starting a new one though, so that was another reason for changing the meeting calendar. As we moved the retrospective to the after lunch slot, we now break down the stories on Friday after our daily standup meeting. I feel that it gives us a lot better rhythm. That also leaves some air on Thursdays to execute some ideas from the retrospective and deal with some technical debt.

Speaking of the daily standup we have it each morning at 9.15 except for Mondays, when we have a general meeting for the entire company at that time, and have our standup after that. We have all done Scrum before and have learned to value the daily standup meeting a lot. That’s about all we took from Scrum that doesn’t exist in XP though, except maybe the role Board Master that we invented to have some responsibility for our Kanban board.

We have the standup meeting in front of the Kanban board. Our board now has the columns Selected, Development, Test and Done, where the Development column is split into three sub columns - In progress, Trash and Ready for Test. The trash column is the only addition from our original board. It is used for collecting all tasks before they are all done. When all tasks are done we will move the story card to Ready for Test and the trashcan can be emptied.

Merry Christmas!

Christmas is closing in and the Whole Team will be gone until 7 january. We're leaving mid-sprint, one week done and one week to be done 7 january and forward. It was either that or having slack time for a week working freely. Having a four day sprint didn't feel like an option. Any way I think it will work fine with a two-session sprint. And certainly better than unplanned time.

On another topic I received a Christmas gift today as I finally got the book I ordered three weeks ago. It should have been delivered in 3-6 days, but I guess it was busy times for the book shop... The book is The Art of Unit Testing by Roy Osherove. I've heard a lot of good things about the book so I hope it will be an interesting read. I'll try to post a review when we're back.

Merry Christmas to all of you, and a Happy New Year. See you in the next decade!

Presenting XP - our XP

I just held my fourth presentation of XP this month. The first was on the startup meeting, the second with the team, the third was for the customer and today it was for the entire tech department of Creuna Sweden.

The first occation was alot about selling the idea to the company. That presentation was based on the article What is XP by Ron Jefferies along with a couple of slides I added about why this was good for us, both in this project and in the long run. On the rest of the presentations I have just had one slide, One Page XP by Bill Wake, and talked freely about XP from upper left to lower right, adding things as I pass the different stages.

The second occation was to get the team started, trying to figure our the roles and responsibilities among us. What are the Interaction Designer, the Test Leader and the Project Manager supposed to do? We've decided on having the Interaction Designed being in charge of the user stories, and coordinating them with the customer. Along with the Test Leader she then writes proposed Acceptance Tests for each story. The Test Leader is then in charge of implementing the Automated Acceptance Test using Selenium and also doing the manual testing where Selenium can't be used. The Project Manager mainly do XP while playing The Planning Game and keeping the Overall Schedule. Other than that she keeps track of how we're doing with time and estimates and arrange everything around to let the rest of the team focus on producing - she's somewhat like a Scrum Master.

The third was more of a introduction where we wanted the customer to know what to expect and to get to know how much the customer wanted to be involved. We got the customer to agree on sitting one day every week at our office, and also got to know that more involvment in the story creation was wanted. We settled for a process where Angelina will produce the stories and then walk the customer through them in a separate meeting before we plan. It's a solution we all think will work really good.

This last one was more educational to let everyone else at the company know what XP is, what it can do for us and what pros and cons we've found so far. About half of the group knew briefly what XP is on before hand, but only a few had more than shallow knowledge. The most discussion was when I came to the Design Philosophy box in the lower left where we talked about Good Design versus Simple Design. I stated that all Design Principles still are valid and that Simple Design just states that you shouldn't make your design "future proof". An example that came up was that you might not want to use a Factory for creating objects if you only can see need for one implementation, which I agreed to but added that you'd anyway would make that class implement an Interface that others use to access it - making it easy to add a Factory later on if needed while it isn't adding code that isn't needed. I found it peculiar that no discussion at all was raised around Pair Programming - except our thought about how to deal with new developers added to the team.

Planning Poker

Today Tommy brought his Planning Poker deck to our Planning Game session (see previous post). I've only read about planning poker before but never used it in practice.

The Deck:

The Planning Poker deck is like an ordinary deck of cards but instead of clubs, diamonds, hearts and spades with different values there are only numbers representing days. On the back of each card there is a color to group them. Each color consists of thirteen cards numbered 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100. It also have two "wildcards", one coffeecup meaning take a break and one question mark meaning we have to discuss this.

Planning Poker Deck

Game play:

We were four players. Each player picked a pile of cards with the same color. As in most card games you are not supposed to show you cards face to your competitors. Then we read one of our User Stories and each player played the card representing the number of days they believed it would take to finish it. Estimates included automated acceptance tests as this is the definition of done in our case. The card you played was placed at the table with face down, and then turned by all players simultaneously so you wouldn't cheat:) If all players played the same estimate this estimate was written down on the User Story. If all players played different estimates we discussed back and fourth until we all felt comfortable with the estimate. Equally if some player played a much higher or lower value than the rest of us. The coffeecup or the question mark was not used, maybe next time.

Even though there's no real competition as there are no winner, except the whole team if the estimates are good, it was much more fun than just sit down and do estimates. I really recommend you to try it.

The Planning Game

Today we played our first Planning Game. We started this morning with playing Planning Poker to estimate all the stories we've come up with. It turned out really good, but we didn't manage to estimate all the stories on the hour we had before the customer arrived for the Release Planning and Iteration Planning. A small pile of assumed low priority stories remained, but we probably managed to estimate more stories this way than would have been the case if we had estimated the usual way.

Simon, Tommy and Angelina playing Planning Poker

When the customer arrived we first prioritized all the stories we had, including the ones that we didn't have time to estimate. Once the priorities were in place it was a no-brainer to choose what to include in the first iteration. We simply calculated how much time we would be able to spend during the iteration and then selected stories from the top until we reached the available time. The stories with high priority were all estimated by the morning session. We also created a release plan with some set dates for different parts of the project.

Moving on to Iteration Planning we had a bunch of proposed Acceptance Tests prepared to define each story. These were discussed by the Whole Team, including the customer. We slightly redefined a few of the stories by changing details in the proposed tests, and also came up with some extra tests needed to prove the function. Along with the definition of Acceptance Tests we also performed the Task Breakdown of each story. Here it seemed that the developers were the only ones really needed though, so in the future we might do that after the Iteration Planning.