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/

How product design teams can benefit from Scrum

Scrum as an Agile methodology is currently most popular in IT development teams. However, that does not mean that it cannot be effectively used in other domains. In fact, as an Agile methodology of managing projects, it can be used wherever people work on projects on a regular basis. It can be used in a particular division of a company – like new product development in an automobile company, and even within a particular division, like the product design team. This article will highlight how Scrum methods can be used very effectively to manage product design projects.
Product design as a function revolves around ideas. Ideas which need to be defined and brought to life. For small or less complex products, sometimes a single product designer is enough to generate the product design. But in the case of a complex product, say an automobile, there will be multiple product designers involved. Some will be experts in interior design, some in exterior design etc. It’s important that the different product designers work as a cohesive unit and know what the others are doing so everyone is on the same page and the work gets completed faster. Let’s see how.
Let’s say the product design team is tasked with the project of designing a new car model. How can it use Scrum? Well, it actually is quite simple (one of the basic objectives of Scrum – to keep it simple). You start off with stating the project vision – designing a sedan within certain dimensions and which needs to look sporty and elegant. Then you need someone to spearhead the whole project – the Scrum Master. He/she will decide who all will be part of the Scrum team. These have to be people who will actually be doing the various tasks in the project and not the ones who simply have an interest in the project.
So now you have the people who will be working on the Scrum project. What next? The team needs to understand the customer requirements. These are defined in the form of User Stories. In our case, two of the user stories might be ‘I would like to have a car which looks fast’ and ‘I need enough boot space for 3 suitcases’.
The User Stories are approved and entered into what is called the Prioritized Product Backlog. It is the master document which guides the team in the project. It contains the User Stories and the tasks which are required to fulfill the requirements for each of the user stories. So in our example, the first User Story about looks will include tasks like ‘Collect existing sporty car designs’, ‘Create 5 different high level sporty car outlines’, ‘Develop the feedback metrics’, ‘Test the 5 designs’, etc. It then decides on a Release Planning Schedule which lays out the schedule of shipping out completed deliverables to the customers. The team then estimates the time required for the various tasks. Based on the above, a collective decision is taken on which all tasks will be taken up in the first round – called Sprint in Scrum. A Sprint duration can vary from a week to a few weeks.
The team then works on completing the tasks in a particular Sprint. To ensure that things are on track, the Scrum team has a Daily Standup Meeting which is time-boxed to normally 15 minutes to half an hour, in which all the members stand around and discuss the status of the different tasks. Given that product design teams generally don’t have rigid hierarchies and would need to interact on a daily basis, the Daily Standup Meetings would be a more structured way to conduct their daily interactions. Tasks are entered in post-it notes and stuck on to a whiteboard with 3 columns – ‘To be done’, ‘In Process’ and ‘Completed’. As the team works on the tasks, the tasks from the first column to the third column. At the end of a Sprint, when the team has hopefully completed all the tasks, a Sprint Review Meeting takes place where the team discusses what went right and what are the improvement opportunities. At designated points in time as laid out in the Release Planning Schedule, the team ships out completed deliverables to the client, which, in the case of the product design teams would mean the completed design for the prototype as well as the final technical designs.
This process continues till all the deliverables and tasks are completed in the product design project. The high level of involvement and communication involved in the Daily Standup Meetings is the key to an effective implementation of Scrum. Thus, by following the above process, product design teams can ensure speedy completion of projects with high quality outputs without getting bogged down by a lot of documentation and processes.

Note: The Scrum specific terms used in this article are as per the Guide to the Scrum Body of Knowledge (SBOK)
to know more visit-http://www.scrumstudy.com/blog/how-product-design-teams-can-benefit-from-scrum/