I recently joined Boost after spending over a decade in the UK. Having worked within a traditional project management process over the last 5 years, I was very keen to learn about the benefits of Agile project management, specifically the benefits of Scrum and the comparison with my previous experience of web development projects.
What I found after a week of observation was that unlike my previous experience of web development projects, an ‘us and them’ (supplier v client) situation causing conflict and resentment is less likely to arise under Scrum. This is due to the scrum itself - both supplier and client are team members with clearly defined roles and responsibilities.
I was asked to observe a number of Scrum meetings in my first week; a stand-up, story sizing meeting and a retrospective.
The stand up
The stand up occurs daily and is a chance for the team to confirm what they are working on and to communicate progress from the previous day. I was immediately struck by the fact that each team member contributed to the stand up in the same way – developers are not asked what they are working on, they tell the team what they are working on and have the opportunity to identify any blockers to their progress. Although brief and straightforward this meeting immediately appears to be beneficial for a number of reasons.
- the entire team knows exactly where in the sprint each person is
- issues or blockers are raised early
- progress is seen as it happens, stories are closed out each day throughout the sprint
Story sizing
Story sizing consists of all team members sitting around a table with a hand of sizing cards (numbered 1, 2, 3, 5, 8). A member of the team reads out a story, team members are then asked to ‘play’ a sizing card. The card indicates a measurement of effort that is not classified in time but by a proportional comparison. For example if the first story is sized as a 3 (or medium) then a story that is larger and will consist of more tasks may be sized as a 5 or 8. If a team member’s sizing differs dramatically from other team members the team member will then explain why they consider the story to be larger or smaller and after a discussion a consensus is reached. Sizing of stories informs the decision as to how many stories will be undertaken during the upcoming sprint.
The advantage of the entire team sitting down to size work as opposed to a more traditional method of having the developer who will undertake the work provide a time estimate is that each and every team member has a chance to input to the sizing of the story therefore the team takes responsibility for the timing of the story, as opposed to an individual. It is a transparent process that ensures the commitment of all team members to the delivery of each story.
The retrospective
The retrospective is a feedback meeting in which each team member is asked to focus on particular aspects of the previous sprint and to record both positive and negative feedback on these. The aims of a retrospective are for the team to communicate, review and improve on previous sprints. Retrospectives may be run in any number of ways in order to get the best out of the team.
During my observation of a retrospective I was immediately struck by the difference between this meeting and that of a traditional lessons learned meeting (held at the end of a traditionally managed project). The retrospective encouraged all team members to communicate openly. Contributions from team members are presented as statements, and are constructive rather than obstructive or defensive. The advantage of holding retrospectives regularly (at the end of each sprint) is that points are raised early and the project goes into a cycle of continuous improvement – as opposed to a traditional lessons learned meeting where any constructive conclusions are beneficial only to the next project the team works on.
My conclusions from my first week of observing Scrum in practice are very positive;
- Developers are encouraged to fully participate in all meetings demonstrating work completed and inputting to decision points as required. As a direct result of their commitment to the project developers take a great degree of responsibility for project outcomes, they are very obviously accountable for tasks, while also having the benefit of the entire team’s support. All too often in non scrum projects the developer is asked to take responsibility for tasks in isolation and are therefore reluctant to commit to timescales and successful outcomes.
- Clients are fully immersed and committed to the process and as such are very much a part of the team. Unlike projects I have worked on previously there is less expectation that the supplier will drive the project in isolation, instead the client is fully involved in all aspects of the project and always aware of exactly what work is taking place and when it will be delivered.
- Processes are consistently reviewed for effectiveness and all team members input to the review process. There are opportunities for both positive and constructive feedback and actions are undertaken as a result. In comparison with the traditional ‘lessons learned’ aspect of a project this seems far more beneficial in terms of continuous improvement rather than undertaking process improvement at project conclusion.
- Project tasks are broken down into explicit finite tasks and the acceptance criteria are clearly defined and agreed at the outset rather than development task estimates taking place at the outset of a project in isolation from other team members.
My overall impression in this early stage of exposure to Agile project management and Scrum is that Scrum builds a happier, closer team and minimises risk by ensuring frequent and open communication between all team members.
