During the last big project, duration more than a year, we used scrum. But it was a tailored scrum process. The reasons for the tailoring were:

• No scrum/agile experience in the company
• Small team (4 developers)
• Knowledge of tailoring RUP or Hermes
• First project with agile methods

Normally I was the Scrum Master and mostly also the Product owner. The role of the Product owner should be fulfilled by the customer, but in our project, there were several customers with different opinions and interests. So it was our job to play a role like an advocate, in this scenario it means, that I have to be the Product owner for the developers. That wasn’t easy, because you have to understand what your customers want and explain that to them. But that’s daily business for a software engineer, isn’t it?
As an illustration I describe a typical week:

Monday
The first thing what I did as Scrum Master is a review of the last week with the team. We looked at our whiteboard (our sprint-backlog) where we could see all tasks of the last week and which of them were done. I calculated the rate in percent how much of the planed tasks are done. Normally we had a rate between 70% and 90%. If it was lower than 70% I knew that we planned too much. If the rate was 100% I knew we planned too less.

Here is the first tailoring: We used tasks rather than stories. This because we use in the company the term task and everybody knows what that is and which granularity it has. There was no need to introduce the concept of user stories.
And there is another tailoring: As you can see on the picture, the layout on the whiteboard isn’t like a scrum board. We chose a quite simple layout: The tasks have only two states: Not-done or done. Important Tasks are additional marked with an exclamation mark.
After the review meeting, I cleared all tasks on the board which are done. The tasks which weren’t done I asked the team if we would do those tasks this week. If the answer is no, I cleared also those tasks and entered them in our project management tool to not loose them.
Now the planning of the current week began: Every developer had access to our project management tool where he could see, what we had to do. And here is the next tailoring: In our company we have a project management tool, which we have to use. So I decided to use that tool as our product backlog. After the planning meeting you could see on the whiteboard all tasks which the team has committed to do this week. To some of the tasks on the whiteboard I added an exclamation mark to show the team the most important tasks for that week. The whole planning process was very democratic: Every developer could say what he thinks and I try to achieve a consensus.

Tuesday until Thursday
Every morning we did a short meeting (like the scrum daily meeting): I checked with the developers every task on the whiteboard and asked the state of the task. During this process there could happen, that I added new tasks on the whiteboard, but we never delete tasks on the whiteboard (because of the review meeting next Monday).
During the day I went to every developer and asked him if everything is OK or if I could do something for him. And this is another tailoring: In Scrum you have normally one daily meeting. Because our company had no experience in agile methods I decided to increase the communication between the Scrum master and the team members. If you are in a very agile experienced team there is much less need for that much communication, but communication is always a good thing.

Friday
On Friday we delivered the software with most of the tasks, which we planned. The most important tasks were always delivered.

Conclusion
Our sprint duration was one week and it was OK for us. The project was really tough and for that one week was perfectly. I used the project management tool to be transparent to the management and used the tailored scrum process to manage the creation of the software during the project.
The team members were all quite young and interested in learning new things. I enjoyed it very much to work in that team. But because the team members were young I had a big responsibility to coach and lead them.