How Consulting 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 can also be used for an entire organization, like in the case of a consulting firm. This article will highlight how Scrum methods can be used very effectively to manage consulting projects.
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’.  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 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^TM)

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

Technical Debt

Technical debt — also referred to as design debt or code debt — refers to the work that teams prioritize lower, omit, or do not complete as they work toward creating the primary deliverables associated with the project’s product. Technical debt accrues and must be paid in the future.
Some causes of technical debt can include the following:

• Quick-fix and building deliverables that do not comply with standards for quality, security, long-term architecture goals, etc.
• Inadequate or incomplete testing
• Improper or incomplete documentation
•  Lack of coordination among different team members, or if different Scrum Teams start working in isolation, with less focus on final integration of components required to make a project or program successful
•  Poor sharing of business knowledge and process knowledge among the stakeholders and project teams
•  Too much focus on short-term project goals instead of the long-term objectives of the company.

This oversight can result in poor-quality Working Deliverables that incur significant maintenance and upgrade costs. In Scrum projects, any technical debt is not carried over beyond a Sprint, because there should be clearly defined Acceptance and Done Criteria. The functionality must satisfy these criteria to be considered done. As the Prioritized Product Backlog is groomed and User Stories are prioritized, the team creates Working Deliverables regularly, preventing the accumulation of significant technical debt. The Scrum Guidance Body may also include documentation and definition of processes which help in decreasing technical debt.
To maintain a minimal amount of technical debt, it is important to define the product required from a Sprint and the project along with the Acceptance Criteria, any development methods to be followed, and the key responsibilities of Scrum Team members in regards to quality. Defining Acceptance Criteria is an important part of quality planning and it allows for effective quality control to be carried out during the project.

Technical debt is a very big challenge with some traditional project management techniques where development, testing, documentation, etc. are done sequentially and often-times by different persons, with no one person being responsible for any particular Working Deliverable. As a result, technical debt accrues, leading to significantly higher maintenance, integration, and product release costs in the final stages of a project’s release. Also, the cost of changes is very high in such circumstances as problems surface in later stages of the project. Scrum framework prevents the issues related to technical debt by ensuring that done deliverables with Acceptance Criteria are defined as part of the Sprint Backlog and key tasks including development, testing, and documentation are done as part of the same Sprint and by the same Scrum Team.

To know more about it kindly visit :http://www.scrumstudy.com/blog/technical-debt/