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.
