SCRUM Methodolgy – Is it right for your business?Posted in: Blog, Latest News | October 9, 2012 at 3:38 pm, by

Here at Analysis Express, we have been involved in many self-proclaimed “Agile” projects with many different organizations. Each project was different from the other in regards to management style, degrees of team collaboration, and documentation style. If your team or your organization have considered beginning a new SCRUM team, or have already implemented SCRUM methodology, then this article may prove useful in helping to generate some ideas of potential problem areas to address. Generally speaking, SCRUM shares similar characteristics with Agile methodology with the emphasis on the following items:

  • Software is valued more than documentation
  • Team collaboration is more important than contract negotiations
  • Responding and adapting to change is more important than following a set plan

When using SCRUM techniques, the project is typically broken down into manageable work units, which most people refer to as sprints. The first week of the first sprint is usually to work out high level requirements such as system architecture and business needs with business owner and/or executives, and the operators/users. In the first week of a project, it should be considered a successful week if you have managed to produce product backlog and sprint backlog i.e. project scope within this period. It is helpful during this phase to also cover team responsibilities and expectations as well as operational activities such as daily project team meetings, user format and acceptance criteria.

Even when following the project outline faithfully, you may have noticed that at the end of the first sprint (4th week of 4 week cycle) some things did not turn the way as you and your team had planned (scope creep). This is fairly common and should not be a real issue because we work closely with business owners and they understand the situation. Besides SCRUM / Agile methodology is about responding to changes as it is required.

Frequently, the client may have questions similar to these:

  • How can you accurately estimate a project with an iterative process?
  • How can you determine the delivery date of a project if you re-estimate it after every sprint?
  • How can your customer agree on an analysis and sign off on it if you do not have an analysis phase?
  • Isn’t Scrum just a cowboy development process since we there is no detailed design phase?

NOTE: Never pretend that SCRUM can solve all of your project based problems. Instead, point out to your team what they already know: that their existing waterfall methodology, with its detailed estimates and phases, only gives the illusion that it can deliver a high quality product with all required features on budget and on time. SCRUM, on the other hand, can help mitigate some of these risks.

What are the immediate effects on the work team?

In a majority of enterprises, when we talk about project teams you are actually referring to a set of individuals grouped under the project manager. SCRUM development teams are true teams. The differences between project teams and SCRUM teams are huge. On a waterfall team, the project manager plans the tasks and their precedence. Most of the time, this same Project Manager will then assign tasks to developers according to their skills, which are more or less well known by the PM. These tasks are generally large, taking at least a few days if not a few weeks to complete. In most cases, team members talk to each other only when there is an issue. Everyone on the team does his work on his own and, at the end, delivers what he was asked to do. Can you see a few issues with this approach?

In contrast, a SCRUM team commits to deliver some set of functionality by the end of the sprint (the work period). No single person is accountable for a particular piece of the project; rather, the whole team is accountable for all aspects of the project they engaged and is prepared to deliver results by the end of each sprint. People choose their own tasks (or choose to work together on tasks). The tasks they pick from are relatively small, usually only taking a few hours to a day to complete. At the beginning of each day, the team meets to talk about what they worked on the day before, what they’ll be working on presently, and what kind of help they anticipate they will need in order to complete their work. Throughout each day, SCRUM teams reach out to each other for help or to coordinate tasks. At the end of the sprint, the whole team is accountable for what is delivered. There are no individual superstars. The sprint is not a success unless every promised feature is delivered.
Working on a SCRUM team means that team members will be asked to be accountable to each other. They will be asked to interact with each other daily. They may have to do work outside their comfort zone or help with tasks they wouldn’t normally undertake. This level of communication and coordination is not natural in the IT world where developers are chosen for their autonomy and personal accomplishments. But the beauty of SCRUM is that it really works. I can tell you that it will not take long under SCRUM to raise the level of trust among team members and improve the performance and the communication level of a team. Positive results are bound to follow.