Into Scrum

My first Scrum project was an upgrade of an IT system with a system interface implementation and the implementation of some new features.

It was an experimental project from point of view of methodology. We wanted to try how we could work in Scrum. Of course, the tasks were real and we had to keep the budget.

We were self-confident after successful agile projects. Two developers joined the team. Our optimism infected them. It was why they waited to new methodology with excitement.

We solved our tasks in four two-week long sprints. The project itself was a great success. Of course we met challenges during the work. We discussed them on the Sprint Retrospectives, fairly successfully. I think they may be interesting to you, as well.

I was afraid of dividing stories among sprints. I just did not want the team have idling issues. In order to avoid it, everybody got an out-of-project task. In case of idling, they could work on these tasks.

The project was successful yet the first sprint failed because of the following reasons:

At this time, we did not have a tester; developers had to test their work. It was the first problem we met, nobody include test in the estimation of tasks. Developers forgot of the upgrading manuals and code commenting.

The spirit of the Daily Scrum also had to be changed after the first sprint. If any of developers had a problem during the preceding day and solved it, then he did not mention this problem on the following Daily Scrum. Such way, two or more developers got over the same problem. We agreed with informing each other about all solved problem. Also, developers were afraid of mentioning problems. They were fighting the problem until the last drops of blood, wasting their time.

The second sprint was successful, but we did not have any reserved time. During the sprint the team had to support an IT system and in case of urgent incident some of the team members had to go to work on the incident. These support activities were very frequent during the second sprint. The team was still shy to inform each other about the problem or to ask help from me. I did not mention I was the Product Owner and the Scrum Master at the same time. We were discussion about the individuals and the team and I thought that everybody understood that if one of us had a problem then all of us had the same problem.

After solving the problems of the first two sprints, the third sprint offered other challenges.

One of us, the new team member, was a night person. He was unable to arrive on time to the Daily Scrums. The team was waiting for 10 – 15 minutes each day. We decided to start Daily Scrums an hour later.

We met an interesting cascade effect problem. The tasks were built on each other. So, if the one of the tasks was late, then the whole story must have been late. The team suggested putting one task in one story, and according to their opinion the stories had to be independent. I refused this suggestion. First, such solution would have an effect on the Product Backlog. Second, it is impossible to have so many independent stories in a project. And last but not least, they still were thinking as individuals not a team. During the next sprint, everybody got a half-day off and we went to play an adult game (escape from the room) in order to be a team.

The last sprint was real success. The team had only remarks regarding the testing. The subject of the discussion was how to handle if the other developer’s tasks caused problems during the testing. Our proposal was that the developer who had written the erroneous code had to correct his code as soon as possible in order to avoid his mate’s idling.

In summary, the customer and our boss were content. The team was proud of their work, too. However, the team had a small problem, which would grow fast during the next common work. The team member, who was unable to come the morning meeting on time, earned other’s displeasure.