Lessons learned working in SCRUM methodology

I have been involved in many ‘Agile” projects with different organizations and amazingly each project was different from another in term of management style, how each team member ‘collaborate’ with each other and documentation style. If you are about to start a new SCRUM team or already implementing SCRUM this article might give you some ideas of potential issues to address sooner than later. Refer to Wikipedia on SCRUM for more details but in general SCRUM shares similar characteristics with Agile methodology emphasizing on the following:

  • Working software is valued more than documentation
  • Team collaboration is more important over contract negotiation
  • Responding to change is more important than following a plan

The first week of the first first sprint was to work out high level requirements such as system architecture and business needs with business owner, operators and/or subject matter expert (SME). We managed to produce product backlog and sprint backlog i.e. project scope by the end of the week. We also covered team responsibilities and expectations from each other as well as operational activities such as daily stand up meeting, user story format and acceptance criteria.

At the end of the first sprint (4th week of 4 week cycle) some things did not turn the way as planned and we had to push some of the user stories for the next sprint due to changes on requirements i.e. scope creep. However, this wasn’t 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.

The following table summarizes some key issues that could be prevented:

Issues Solutions
Developers experienced difficulty trying to complete

tasks with changing functional requirements.

Scrum master will liaise with developers and

better manage the change request from users.

Testers did not get incremental builds in Test

environment because of user story interdependency

from one to another.

Will aim for smaller and shorter user story so

that Testers will get weekly build and also

clearly defined the exit criteria/acceptance

for each user story.

Developers need better functional specification

before they can start coding to avoid changes

and loss of time.

Project Manager suggested that business users

together with Business Analyst should have

daily catch up with developer.

The aim for delivery and time estimate were

very optimistic and should include time for

meeting, research and ‘collaboration’

into sprint backlog.

Scrum master will reduce the ‘optimal’ working

hours down from 6 to 5 hours per day and try

to aim less user stories (at least for the first sprint)

In summary, it is important to keep business owner informed on the progress on weekly or even daily basis depending on the situation. Any impediments should be prioritized accordingly to minimize delay, hence reduce project risks and costs.

Related Posts Plugin for WordPress, Blogger...