Scrum © royskeane@flickr
We are agile. We do Scrum. We do daily Stand-ups.
A couple of weeks ago we changed our daily stand-up meeting. Our Scrum master came up with the idea to not go around the whole team and everybody talks about what he has done, what he will do and what the impediments are but to make it story based.
Usually after a break down everybody was working on one story, saw the task cards and made sure he did the things he was supposed to do. But this is not enough. You need to have an overview of the whole story (and the sprint). Only with that knowledge you can make sure you will meet the commitment.
So what we started to do is a stand-up meeting based on stories. Every story has a story owner. This is either the person who first started on this story or somebody who is expert in the field worked on. Every morning he is giving a review of how ‘his’ story is progressing, where the problems are and how he could need help. Depending on the priority he gets everything he needs. After presenting the status to the whole team every team member involved gives a smiley on how he feels about the story and the sprint. This way everybody knows what the situation is and how the sprint is progressing.
We found this very effective and it gives every team member a much better feeling about our commitment.
You should try it too.
You are doing scrum, your story is big, you really don’t know much about it and the feature does not get implemented in time.
Sounds familiar ?
I had this a couple of times.
What turned out to be a real problem is that, tech nerds as we are, we spent most of the time coding up a nice solution (and we were almost always convinced that this was the minimum we should have done). What we underestimated was the time we would need to integrate it with the rest of the system. When we broke new ground integrating new technologies it turned out is is very easy to miss that point.
In theory ‘just’ code against a defined interface and you are all set up. In practice you will find the interface not working as intended or web services returning everything wrapped in CDATA. This is the point where you start to panic. This integration was supposed to be easy. Everything else is already working and only a couple of hours where allocated to integrate the new functionality (and sprint review is tomorrow). So it is crunch time, again.
What did we learn ?
If possible (and this is not always the case) start implementing one small feature from top to bottom all the way through your application, e.g. selling green cars through you web site. If this works you can go on and sell blue and red cars. It also helps to organize teams along user stories. This way everybody is responsible for the story.
If you have teams organized along responsibilities like database or GUI, the communication between the team members will suffer (since they usually sit in different rooms). Everybody tries to code up against the defined interface and the integration usually happens pretty late in the sprint. Each team claims that his stuff works against the agreed contract (but still some things do not function as they should). Just hours before the integration should be finished, it turns out the specification was not correct and other things are needed. Back to the drawing board. Overtime. Feature not implemented.
After you got the integration running make sure an automated test is covering it. These need to be expanded over time and you make sure from the beginning that it will always work. It would be very nice to have the integration test running before writing any actual code (read: test driven development) but this never went to well for me since the two sides are very fuzzy in the beginning.
My hope is that next time we come to a situation like this I remember a couple of things I wrote down here 
.
For the last couple of month our scrum master always drew our daily burn down chart. Nice and fine and it always happened automagically. It came to the point that we (the developers) only occasionally paid attention to it (a little less then we should). One day our scrum master stopped doing it and forced us to do by ourselves. While it seemed a bit strange at first it turns out it was a brilliant idea.
We are now reminded every day how much hours we burned (in contrast to we just complete cards but nobody calculates the sum and tells that everybody). If the result is far below the theoretical number of developers x 8 hours a day we quickly analyze the problem and try to solve it. We are more aware that we might be in trouble. This was not so much the case in the last sprints.
Self made burn down chart
It could be that it just works because it is new but I think it is worth a short. I certainly like how everybody stands around the burn down chart and tries to do mental arithmetic.
So just in the last sprint we (re) discovered that we need an owner of each story. A person who makes sure things are going smoothly and takes care that everything is done in a way so we can fulfill all acceptance tests. At sprint start the person which feels the strongest about the first story will be owner and he will drive the story.
Very often we do operate in a king and servant model. The king (story owner) calls as many servants he needs to get ‘his’ story (with the highest priority) done. If this story does not scale to the full team the others are starting on the next story. Again, a story owner (king) is chosen (or whoever wants to drive the story). Of course story priority is always determining the order of allocating resources to finish the job.
To formalize the story owner a little bit we do write down the name of the person in the upper right corner of the story card. I updated the scrum board cheat sheet.
Get version 1.1 of the Scrum Board Cheat Sheet.
We do have our Sprint Review tomorrow. We will not meet our commitment. Bummer.
What happened?
After the planning we did the breakdown of almost all stories. We had 5 Stories and another epic. As we did the epic breakdown we knew that we could not nail down every task since it was clear that some refactoring along the user story would be needed. So we marked one card in that story to remind us that we need to break things further down and refine the tasks.
The first couple of stories went very well (although we still suffer from estimating small stories too big and big stories too small). In the third week we got to our reminder card and our domain experts began to really think about the tasks needed and designed a much more useable and better architecture. This took a couple of hours and could not have been done at breakdown time (or could it?). It turned out it was quite some work to be done but we still could meet the deadline.
Some of us started to implement the new design and things seemed well. What we not did is a detailed planning of the tasks. It was more like we do see what is needed and write down task cards as we see the need for it. This was mostly done on ‘unplanned task cards’ (see earlier post on Scrumboard Cheat Sheet).
Due to the complexity that team could not check in their changes for some days (Remember? Never check in code which does not pass all tests). The only problem was that without that part of code most members of the team could not proceed very effectively on the epic. We found ourselves in a classic deadlock. I was part of those who could not work as intensive on the sprint goal as they would have liked to. It was a frustrating experience. In the end I think we could have been somewhat closer to the goal if we would have seen the warning signs like we just do write the task cards at the stand up (and acting on them). This goes down in my book under ‘Lessons learned’.
I’m not sure how we could have made it better. Doing a better task planning at the breakdown? We usually spent about two hours to define the tasks. Going over that time with the whole team seemed always to stress this a bit and it got less effective .
Should we have spent earlier on more time in designing the refactoring? Two people could have started right after that on that topic. But that epic had a lower priority and everything else should have been done before that if we do follow agile ideas.
However since our Product Owners saw that coming (there were usually at our daily standup) there were not shocked about it as they would have never heard of that problem before. But I guess they are not too happy with us.
Three more days and we are done. Promised.
In the last couple of month we continuously improved our scrum task board. After a sprint planning we usually do a story breakdown into tasks. All tasks for one story get ordered and a time for each will be estimated. We do try do make sure every task is smaller than 8 hours so it can be completed in one day.Our ScrumBoard is a magnetic whiteboard with hand drawn lines.
We do use color coded cards for the tasks we do. We do shuffle the colors each sprint but we have different colors for:
- The Story itself
- A Task
- Unplanned Task (like a thing we forgot at breakdown)
- High Priority Bugs which need to be fixed right away
- Non Sprint Tasks
Different colors make it easy to see if we were good at estimating the work which needs to be done. It shows us very easily that we might be in trouble with our commitment because we got of external tasks. The burndown chart shows this as well, but the colors show us why (as well as the bars, more on that later).
The top row is reserved for unplanned tasks, bugs and time boxed events such as workshops with the solution owner or support for the product owner. Four rows are for stories we are working on.
As soon as somebody starts a task he writes his name on the task card and puts it in the ‘work’ column. He usually takes as many cards until the added hours of the tasks equal the time he is available to the sprint today.
Each card has a specific order in which it needs to be executed to complete the story. Some tasks could be executed in parallel and some have to wait. If we find one card blocking and somebody is working on it, the rest of the team sometimes starts with a new story or helps finishing the blocker. Right next to it we draw a small bar for each day we are working on this task. When we see that a task which should take e.g. 4 hours is now in the ‘work’ column for 2 or more days then this needs to be addressed in a way that we brake this card further down or assign more people to it so this can be finished. Bar code cards are not cool.
If a task is done, we put them at the end of the row in the ‘work’ column in 90 degree angle. This card will be moved the next morning during the 15 minute daily scrum to the ‘done’ column. If something comes up during the daily scrum which needs to be discussed by the team we write this down in the Standup Backlog at the board.
To get a better impression have a look at the ScrumBoard Cheat Sheet of my team.
Update:
This is our current sprint overview:
Our current scrum board
What is Extreme visibility?
Extreme visibility is all about providing information about the code to every team in near real time. We show several metrics such as complexity of the code (xs), todo’s, deprecated methods, number of broken builds, open tickets and their priority and so on. These are distributed over a couple of screens which our software is rotating through. Every team member can easily see if his or her commits effecting the code quality in a good or bad way and makes the members aware of certain quality standards we try to keep in our code base. A typical screen looks like this (mockup):
Extreme Visibility
We discovered that showing these kind of statistics to the team has the effect that everybody in the team room cares about the numbers (and therefore the code quality). Without this display you just don’t know how your changes will effect the overall quality of the code. It might seem a bit threatening to individual team members at first (like we do show who checks in without a commit message) it turns out this is not really a problem.
While we did provide very detailed information in the past about the trunk and every branch (every user story is on it’s on branch), we found out that too many screens are counter productive and results in not caring about the values displayed too much anymore. We also do believe that showing time line and progression information on several metrics are very motivating to the team. We are planning of tweaking the information this way in the near future.
The software we use is written by ourselves in Grails. On the front end we simply have Firefox running a full screen mode. Every team has a big screen TV connected to a computer (turns out I could connect my Sega Dreamcast too). We did collect some good feedback and learned a lot about the usage in the last couple of months. The next step now is to enable the teams to write their own modules to provide the information which is the most useful to them.
I’m not aware of any open source (or other) software doing the same kind of thing. Writing it by ourselves we could tailor it to our specific needs like showing svn information, showing Teamcity build statistics or information about the code using Structure 101.
Overall the team I’m working in is very happy with the information we get from our extreme visibility monitor. XV makes sure we all can see how the quality of our code develops and we get warning signs to take counter measures to bring it back on track. And that’s what we want after all 
.
