Consulting as a function revolves around projects. Consultants work
on a variety of projects – sometimes even concurrently. In addition,
they invariably have to deliver very high quality deliverables in tight
deadlines. When such consulting assignments are not managed well, they
invariably results in late nights for consultants, giving rise to
numerous stories about how consultants get burned out soon. With Scrum,
consultants can complete high quality deliverables on time without
burning the midnight oil. Let’s see how.
Let’s say the consulting team is tasked with the project of designing a launch strategy for 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 – developing the strategy to launch the car in a defined area, say, the state of California. 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. However, the client, who is a key stakeholder in the project, needs to be involved in developing the project vision.
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 need customers to test drive our car’ and ‘I need to inform our customers in an easy to understand manner, the various performance specifications of the car’.
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 test drives will include tasks like ‘Design the showroom layout to highlight the test drives’, ‘Decide the communication strategy for the client’s customers’, ‘Develop the feedback metrics’, ‘Decide on the tasks to be performed by the salesperson before the test drive’, 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 consulting teams generally don’t have rigid hierarchies and do 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’. The team works on 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 generally includes a call with, or a presentation to the client.
This process continues till all the deliverables and tasks are completed in the consulting 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, consulting 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™ Guide)
To know more click on: http://www.scrumstudy.com/blog/
Let’s say the consulting team is tasked with the project of designing a launch strategy for 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 – developing the strategy to launch the car in a defined area, say, the state of California. 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. However, the client, who is a key stakeholder in the project, needs to be involved in developing the project vision.
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 need customers to test drive our car’ and ‘I need to inform our customers in an easy to understand manner, the various performance specifications of the car’.
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 test drives will include tasks like ‘Design the showroom layout to highlight the test drives’, ‘Decide the communication strategy for the client’s customers’, ‘Develop the feedback metrics’, ‘Decide on the tasks to be performed by the salesperson before the test drive’, 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 consulting teams generally don’t have rigid hierarchies and do 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’. The team works on 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 generally includes a call with, or a presentation to the client.
This process continues till all the deliverables and tasks are completed in the consulting 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, consulting 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™ Guide)
To know more click on: http://www.scrumstudy.com/blog/
