Monday, 22 September 2014

Scrum – Don’t implement it without being trained in it

Imagine you are just about to start on a very important project – big budget, all eyes on the team, the kind of project you dreamed of. The whole team is all geared up and ready to get on with the work. When on the first day of the project, the project manager walks in with a lot of enthusiasm and says – ‘Guys, I just read this article about this really cool methodology called Scrum. Everyone has these daily standup meetings every day, decide what they will be working on, do it, and then meet again the following day. I think we should give it a shot.’
It just got better, didn’t it? A big project and a cool new methodology! Not quite, as is often revealed on so many projects. Admittedly, the dialogue of the project manager was simplified, but essentially, this is how a great methodology is set up for failure. Cut to a week later:
Team member 1: ‘Why do we need to stand around? There are chairs around. We can just sit, right?’
Project manager: ‘That is what the methodology says.”
TM 1: ‘But why?’
Project manager: ‘Something to do about if people stand, meetings are shorter’
TM2: ‘But our meetings typically last for an hour or so and it is so tiring.’
Project manager: ‘We have to discuss so many issues. Obviously it will take time. If it is such a big deal, then you can sit.’
Thus begins a slow, but steady twisting of the tenets of Scrum and the team embarks on a slippery slope. As the team now begins to sit during ‘Daily Stand Ups’, the meetings increase in length from 1 hour to 1.5 hours, and sometimes stretching to 2 hours. With less time available for actual work, tensions increase. Team members start questioning the need to meet on a daily basis when on earlier projects they met once a week and things were more or less fine. Then from ‘Daily Stand Ups’, the format changes to ‘Alternate Day Sit Downs’. This affects coordination and as the gap increases between meetings, the meetings start taking a bit longer, or issues increase.
Slowly, other changes start taking place – the whiteboard where tasks were updated in the first week stop being used by team members. Instead, they revert to sending email updates. The project manager, not realizing the critical importance of each of these tenets of Scrum, not trained in Scrum methods and never having practiced Scrum, also starts questioning himself and accepts these changes. He keeps a track of ‘To be done, In Process and Completed’, but only at his desk. Other team members start to become more confused.
Now as the team had dedicated itself to Scrum in the beginning, switching to alternate traditional project management methods in the middle of the project leads to an even bigger mess. End result – a poorly managed project which started off with good intentions of using Scrum as a methodology, but failed because of lack of understanding of Scrum.
Scrum is a simple methodology but needs training in Scrum and guidance for first time users. Without it, critical elements end up getting twisted and the project heads towards failure.
Moral of the story – Scrum training is not optional. If you want to get the best out of it, get expert help in the beginning and only after thorough training, should you use it at work.

 To know more click on: http://www.scrumstudy.com/blog/

Thursday, 4 September 2014

Length of a Sprint (Part-1)

One of the most often asked questions in Scrum is  “What should be an optimum sprint length?” . If you search on this topic you are more likely to find articles/blogs/posts stating that a sprint can be anywhere between week to a month
The inevitable question now that is posed is, how will you decide what is right for your team and your project?
In reality there are many reasons to attempt for a short sprint and there are many hurdles in attempting the same. As we are moving towards a world which is demanding a shorter sprint lets look into the advantages and disadvantages of this.
Organisations are adopting agile methodologies as it is considered to be more receptive to changing needs of customer. Hence a team that meets with its stakeholders twice a month has the opportunity to be more receptive as a team than those who meet less often
A short sprint also provides more visibility to all stakeholders which helps in diminishing risks as more clarifications are sought in sprints.
The advantage of having a shorter sprint does not just involve a productive relationship with stakeholders. The other advantage of having shorter sprint is that team will work hard towards improving their methods. This is done so because Scrum processes highlights the team’s ineffective processes in order for the team to take effective measures to improve their efficiency.
The team is considered to have the greatest potential to improve their processes is in the Sprint Retrospective when the group deliberates the productive and unproductive traits of the previous sprint. Hence when the retrospective is conducted often then it provides more occasions to evaluate the team’s efficiency.
A shorter sprint also helps the team to focus. This is because the team member’s have a sense of urgency to complete the tasks and to be more effective.
Having a shorter sprint does not mean that the team should be pressurised to achieve targets. Rather the team should maintain a productive level of motivation.
The above mentioned are few reasons of why a shorter sprint is beneficial.

Every sprint begins with a sprint planning meeting and concludes with a sprint review meeting. In this review meeting the team presents its completed work to the Product Owner. Product Owner then decides if the team has achieved its acceptance criteria.