Our way of introducing Scrum

| 2 Comments

Over 2 years already passed since we started to use Scrum processes at software development here, at Fortess. I guess, it is already enough to make judgments on its effectiveness.

How it started to us: we had quite a difficult fixed price project, with significant project scope (involving about 20 developers from Java and C++ departments) and tight schedule. The project has already started, and we faced a lot of communication and interaction gaps. To minimize these problems, we decided to take a risk and to try Scrum, inspired by "Scrum and XP from the Trenches" book.

Starting from basic Scrum practices, we spitted up people on functional teams, moved every team to one room, organized daily meetings and scheduled sprints and retrospectives. In every team there was also assigned an internal tester for continuous testing, and a group of testers for acceptance testing at the end of each sprint. We have designed and printed cute cards for team to estimate tasks. It worked out. Analyzing results of this first attempt, we concluded, that Scrum:

  • increased team spirit and people involvement into project
  • increased quality of results
  • the first working version of application was provided earlier than expected

In general, the team accepted new process positively. They saw better the goal of their work; due to tester in team errors were found on the earlier stages, not causing big works on later stages; at daily meetings with the whole team all issues were detected and solved much faster, then through email exchanges or not-organized meetings.

What was difficult to organize?

  • Make the whole team gather exactly at one and the same time daily. At the meeting was scheduled for 15 minutes only, 5 minutes delay of a few members was a significant waste of time for the rest. We solved it with pineapple penalty. Every latecomer should have brought a pineapple. With a number of fruits gathered, the discipline improved.
  • Move team members to one room. Here we met barriers as people get used to their work places, and didn't want to move somewhere else, and move frequently with every new project. To solve this problem, on one hand, we tried to equip all rooms identically: tables, comfortable chairs, even wallpaper's color. On the other hand, we concentrated on team building activities for people to feel comfortable with any Fortess staff.

When Scrum doesn't work

When application was almost complete, the support and bug fixing tasks start taking most of the time. Sprint planning become useless and scrum does not work anymore, people were demotivated. On retrospective meeting we decided to try Kanban. To make it more interesting we introduced weekly KPIs, so team was passionate to improve KPIs every week.

Evolution of Scrum at Fortess

In 2-3 months after introducing of Scrum in first teams, all Fortess was speaking about this new process, and project managers started to introduce Scrum practices in their own projects.

Tools

Inside Fortess, teams use task board, real or virtual. The last ones help to eliminate common problems such as manual entry errors and lost cards. Some teams work with commercial tools like Rally; while others prefers open source like Agilo for Trac which gives more control and ability to plug in.

But more than tools, or following any written processes, Scrum is about people's culture: to learn how to communicate, how to make the process visible and understandable for all, self-discipline. To continue with, we started considering lean development techniques, oriented on continuous self improvement and avoiding waste of time at production.

RetrospectiveMeeting.jpg

2 Comments

As a sitedisigner I can say that your page was pretty informative.Thanks for the information.

Very use full information. thank you.

Leave a comment