Untitled

The first thing that we need to figure out while dealing with Scrum master is whether they are full time Scrum masters, and the second question tends to what exactly their task is.

We usually don’t find a full time scrum master.  Scrum master, as described by scrum guide is the one who teaches, facilitates and removes impediments. When the team is relatively new it takes time and the team follows scrum religiously. This is when the team needs a scrum master who can teach scrum full time.

Facilitating is necessary, though it takes only 20 to 30 % of the time. The issues tend to lessen as the team learns to resolve them.

If a person puts 100% of his efforts being a scrum master, i.e. if he is training, facilitating that takes up only 20 to 25% of his time. Henec, he has to devote himself in helping the team with their work.

The first step is to train the project managers in Agile which is trying to get them to be certified scrum masters, and agile project managers, preferably from Project Management Institute.

Thus the project managers become the first scrum masters.  At first the scrum master shouldn’t be assigned to one team.

Probably assign two to three teams to one project managers. Their role is to train the team in Scrum.

This has to be followed for the initial six months, until the team gets used to the concept of Scrum.

Then once you are past the first 6 to 9 months have one of the team members to be a scrum master, it would be ideal if the team was allowed to select the scrum master from their team.

Then elevate the project manager to the level of program manager. This would enable them to become accountable for cross team initiatives,

Rearrange management structure, now as the roles have been altered. Instead of a functional manager we have a delivery manager.

The delivery manager is now accountable for training agile.

Thus Scrum Masters was underway as a position and evolved to be a role as the team becomes more mature in adapting Agile.

In Agile, Quality and Testing teams’ roles and responsibilities often overlap. That is because ideally, matrices are not required in Agile Projects. So, Quality teams are often merged into Testing teams for the sake of convenience, though it depends on a lot of factors. Also, as customers are closely involved in providing feedback after every Sprint, even they can be considered as a part of Quality team.

In Agile projects, “Quality should be baked in.” What this means is that since coding, integration and testing happens in parallel, there is no need for quality being checked at a later phase, which in turn means that it has to be maintained from beginning till end, by the combined efforts of all the business stakeholders. In other words, quality has to be fed into a product from the beginning, rather than trying to test it in later. Hence, even a Project Manager conducts a functionality testing if required. Even a BA conducts smoke testing if needed. And even the clients chip in with their random testing during demo and walk through. All of these efforts ensure that “Quality” is not a phase as such in Agile, it is an everyday activity.

Another thing to realize is that in traditional methods, quality should be allocated as much time as coding based on the relative importance, but more often than not this is not the case. What happens is that coding takes longer than allocated, and that is taken from the quality check/testing phase. But in Agile, each increment of coding is tested as soon as it is done, and in the immediate iteration after rectifying bugs. Developers can never actually get ahead of the testers, because according to Definition of Done, a code is not done till it is tested. This fundamental difference between these management frameworks is what makes Agile so much more Quality Conscious.

The term Business stakeholder creates a lot of confusion in Scrum. Usually the term creates confusion with the responsibilities of a Product Owner. Let us now clear all the confusion around it.

Best definition of Business stakeholders is that they have legitimate interest in the project and another important point to be noted is that Business stakeholders are not always product owners but product owners are always Business stakeholders.

Product owners help define the backlog the Scrum team and also help in prioritizing the work units of the Scrum Team and continually communicate the progress to the Business stakeholders.

Business Stakeholders are the purpose for which a Product or service is created in the first place. They are the people who have certain necessities, wants and desires; thus in business terms they have certain requirements which needs to be fulfilled. It is the responsibility of the Scrum Team to fulfil the requirements of the Business Stakeholders. Usually Business stakeholders do not have clear understanding of what they need and even if they do they keep changing their minds very often. Usually figuring out the actual needs of a Business stakeholder is achieved through a lot of meetings with them and also after a lot of trial and error.

The Business stakeholders are very vital to the success of the Scrum team as they keep reviewing the team’s products and progress and keep providing continual feedback. There could be many people, who have genuine interest in the Product, but not everyone should be taken in to account as Business Business Stakeholders – some are purely engrossed bystanders. Clear identification of the Business stakeholders who have requirements is as important as determining the exact market segment you need to target for your products.

So, now we get another important question. Who or what qualities make a good Business stakeholder in Scrum?

Good Business stakeholders are those who provide constant and constructive feedback to the Scrum team and help in improving the product. One big challenge is to manage other Business stakeholders who don’t support or just become part of the scene. Good teams need strong leadership that can facilitate positive discussion and create better services or products.

One of the major misconceptions or criticisms about Scrum is that it cannot be used to deliver large scale projects that have multiple large teams which are not collocated. And for Scrum to be effective, the teams should ideally be collocated and have six to ten members. However, this is not valid as Scrum can easily be scaled for effective use in large projects. In situations where the Scrum Team size exceeds ten people, multiple Scrum Teams can be formed to work on the project.

Complex projects with numerous large teams working in parallel make it necessary to synchronize and facilitate the flow of information and enhance communication for the project to be successful. Scrum uses one of its events or ceremonies to overcome this barrier, i.e., Scrum of Scrums (SoS) meeting. This meeting is usually facilitated by the Chief Scrum Master and is intended to focus on areas of coordination and integration between the different Scrum Teams.

SoS is a review meeting for all the Scrum teams involved in the project. The main purpose of this meeting is to communicate progress among multiple teams. Scrum Master from all teams attend this meet. The meeting is most effective when the Chief Scrum Master announces the agenda prior to the meeting. This prepares the participants to gather appropriate information and issues to be discussed.

Any impediments being faced by a team which may also affect other teams are brought up in this meeting. Teams get an overall view of the development of the project and redirect their efforts meaningfully. This review meeting plays a crucial role in identifying risks and change requirements of each team which in turn affects other teams’ line of work. This also brings to the forefront any production duplications that may occur because of the scale of the project. An impediment log is created stating internal and external impediments. This log helps in resolving issues systematically.

The Chief Scrum Master (or another Scrum Master who facilitates the Scrum of Scrum Meetings) is responsible for ensuring that all representatives have an environment conducive to openly and honestly sharing information, including feedback to other team representatives. This conducive environment plays a vital role in better communication and identification of important issues. It contributes greatly to the success of the project as a whole. The Chief Scrum Master should take care that all representatives speak their minds and do not reserve their issues and concerns which may later turn out to be costly. Updates are provided in the form of answers to four specific questions:

What has my team been working on since the last meeting?

What will my team do until the next meeting?

What were other teams counting on our team to finish that remains undone?

What is our team planning on doing that might affect other teams?

When these four questions are answered, following outcomes are achieved leading to successful project delivery: reduction in non-detection of risks, enhanced coordination among teams, continuous improvement, maintaining of team’s focus on achievement of project objectives, and reduction in need for redesign and rework.

Understanding defined roles and responsibilities in a Scrum project is very important for ensuring the successful implementation of Scrum. Scrum principles can be applied to any type of project in any organization and must be adhered to in order to ensure effective implementation of the Scrum framework. Organization in Scrum can be understood by defining the scrum roles. The scrum roles are basically divided into two broad categories, Core Roles and Non-core Roles.

Core Roles

Core roles are those roles which are mandatorily required for producing the project’s product or service. Individuals who are assigned core roles are fully committed to the project and are ultimately responsible for the success of each project iteration and of the project as a whole.

Non-core Roles

Non-core roles are those roles which are not mandatorily required for the Scrum project and may include team members who are interested in the project. They have no formal role in the project team and may interface with the team, but may not be responsible for the success of the project. The non-core roles should be taken into account in any Scrum project.

Core roles include:

The Product Owner

The Product Owner is the person responsible for achieving maximum business value for the project. He or she is also responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer.

The Scrum Master

The Scrum Master is a facilitator who ensures that the Scrum Team is provided with an environment conducive to complete the project successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project; clears impediments for the team; and, ensures that Scrum processes are being followed.

The Scrum Team

The Scrum Team is the group or team of people who are responsible for understanding the requirements specified by the Product Owner and creating the Deliverables of the project.

Non-core roles include:

Business Stakeholder(s)

Business Stakeholder(s) is a collective term that includes customers, users, and sponsors, frequently interface with the Scrum Core Team, and influence the project throughout the project’s development. Most importantly, it is for the business stakeholders that the project produces the collaborative benefits.

Scrum Guidance Body (SGB)

It is an optional role, which generally consists of a set of documents and/or a group of experts who are typically involved with defining objectives related to quality, government regulations, security, and other key organizational parameters. This SGB guides the work carried out by the Product Owner, Scrum Master, and Scrum Team.

Vendors

Vendors include external individuals or organizations, provide products and/or services that are not within the core competencies of the project organization.

Chief Product Owner

Chief Product Owner is a role in bigger projects with multiple Scrum Teams. This role is responsible for facilitating the work of multiple Product Owners, and maintaining business justification for the larger project.

Chief Scrum Master

As companies progressively adopt Scrum as the preferred project management method over the traditional waterfall method, the subject of ‘role-mapping’ becomes more critical. Perhaps, one of the biggest challenges that organizations face when they move to Scrum is where does a Project Manager fit in Scrum?

We are so used to the role of a Project Manager that we often forget that it is merely a role and does not necessarily specify a position in an organizational hierarchy. The term ‘Project Manager’ has become so obvious that in many organizational set ups people are permanently designated as Project Managers. We have to understand the fact that project manager is not a permanently held designation in an organization; rather it’s a role that a person plays in a particular project when he manages that project.

A person may have the necessary skill set to manage a project but is not a project manager in that project until he plays the role of the same. The role of a project manager is defined by the responsibilities performed in that project and a named individual (Project Manager) just plays the role.

While transitioning to Scrum from Waterfall, we often do the mistake of trying to fit in a named individual (the Project Manager) into different Scrum Roles. Do not try to fit a Project Manager in a Scrum project management setup; rather you should map the roles and responsibilities of a traditional project manager with Scrum roles and responsibilities and accordingly a named individual will play the role as per his skillset.

People often try to find synergy between the roles of a traditional Project Manager with that of a Scrum Master. In practice, both are very different.

A traditional Waterfall Project Manager works as a manager or leader for the project. He plans, makes decisions, and manages the project and is accountable for accomplishing the project objectives. On the other hand, the Scrum Master only works as a facilitator and he or she is at the same hierarchical level as anyone else in the Scrum team. Any person who learns to facilitate Scrum projects can become the Scrum Master for a project or for a sprint.

Scrum developers, also referred to as the development team or Scrum team, are responsible for developing the product and they possess all the essential skills required to carry out the work of the project. They have a high level of collaboration to maximize productivity, so that minimal coordination is required to get things done. To minimize dependency, team members are experts in chosen domain, but also possess basic knowledge and skills about other domains.

Some of the key responsibilities of Scrum developers which they are required to fulfill in any Scrum project are:

Provides inputs for creation of the Collaboration Plan and the Team Building Plan

Ensures a clear understanding of Epic(s) and Personas

Understands the User Stories in the Prioritized Product Backlog

Agrees with other Scrum Core Team members on the Length of Sprint

Seeks clarification on new products or changes in the existing products, if any, in the Refined Prioritized Product Backlog

Provides inputs to the Product Owner on creation of User Stories

Estimates User Stories approved by the Product Owner

Commit User Stories to be done in a Sprint

Develops Task List based on agreed User Stories and dependencies

Estimates effort for tasks identified and if necessary, updates the Task List

Develops the Sprint Backlog and the Sprint Burndown Chart

Creates Deliverables

Identifies risks and implements risk mitigation actions, if any

Updates Impediment Log and dependencies

Updates Burndown Chart, Scrumboard, and Impediment Log

Discusses issues faced by individual members and seeks solutions to motivate the team

Identifies risks, if any

Submits Change Requests, if required

Participates in Prioritized Product Backlog Review Meetings

Provides inputs to Scrum Master for Scrum of Scrums Meetings

Demonstrates completed deliverables to the Product Owner for approval

Identifies improvement opportunities, if any, from the current Sprint and agrees on any actionable improvements for the next Sprint

The first thing that we need to figure out while dealing with Scrum master is whether they are full time Scrum masters, and the second question tends to what exactly their task is.

We usually don’t find a full time scrum master.  Scrum master, as described by scrum guide is the one who teaches, facilitates and removes impediments. When the team is relatively new it takes time and the team follows scrum religiously. This is when the team needs a scrum master who can teach scrum full time.

Facilitating is necessary, though it takes only 20 to 30 % of the time. The issues tend to lessen as the team learns to resolve them.

If a person puts 100% of his efforts being a scrum master, i.e. if he is training, facilitating that takes up only 20 to 25% of his time. Henec, he has to devote himself in helping the team with their work.

The first step is to train the project managers in Agile which is trying to get them to be certified scrum masters, and agile project managers, preferably from Project Management Institute.

Thus the project managers become the first scrum masters.  At first the scrum master shouldn’t be assigned to one team.

Probably assign two to three teams to one project managers. Their role is to train the team in Scrum.

This has to be followed for the initial six months, until the team gets used to the concept of Scrum.

Then once you are past the first 6 to 9 months have one of the team members to be a scrum master, it would be ideal if the team was allowed to select the scrum master from their team.

Then elevate the project manager to the level of program manager. This would enable them to become accountable for cross team initiatives,

Rearrange management structure, now as the roles have been altered. Instead of a functional manager we have a delivery manager.

The delivery manager is now accountable for training agile.

Thus Scrum Masters was underway as a position and evolved to be a role as the team becomes more mature in adapting Agile.

Ken Schwaber and Jeff Sutherland elaborated on the Scrum concept and its applicability to software development in a presentation at the Object-Oriented Programming Systems Languages & Applications (OOPSLA) conference held in 1995 in Austin, Texas. Since then, several Scrum practitioners, experts and authors have continued to refine the Scrum conceptualization and framework. In recent years, Scrum has increased in popularity and is now the preferred project development framework for many organizations globally.

In recent years, it has become evident that organizations which use Scrum as their preferred project delivery framework consistently deliver very high Returns on Investment. The focus of Scrum on value-driven delivery helps Scrum Teams deliver results as early in the project as possible.

The SBOK™ was developed as a means to create a necessary guide for organizations and project management practitioners who want to implement Scrum, as well as those already doing so who want to make needed improvements to their processes. It is based on experience drawn from thousands of projects across a variety of organizations and industries. The contributions of many Scrum experts and project management practitioners have been considered in its development.

The SBOK™ is especially valuable:

to Scrum Core Team members including:

°      Product Owners who want to fully understand the Scrum framework and particularly the customer/business stakeholder-related concerns involving business justification, quality, change, and risk aspects associated with Scrum projects.

°      Scrum Masters who want to learn their specific role in overseeing the application of Scrum framework to Scrum projects.

°      Scrum Team members who want to better understand Scrum processes and the associated tools that may be used to create the project’s product or service.

as a comprehensive guide for all Scrum practitioners working on Scrum projects in any organization or industry.

as a reference source for anyone interacting with the Scrum Core Team, including but not limited to the Portfolio Product Owner, Portfolio Scrum Master, Program Product Owner, Program Scrum Master, Scrum Guidance Body, and Business Stakeholders (i.e., sponsor, customer, and users).

as a knowledge source for any persons who have no prior experience or knowledge of Scrum framework but wants to learn detail about the subject.

The content of the SBOK™ is also helpful for individuals preparing to write the following Scrumstudy™ Agile and Scrum certification exams:

Scrum Developer Certified (SDC™)

Scrum Master Certified (SMC™)

Agile Expert Certified (AEC™)

Scrum Product Owner Certified (SPOC™)

Scalability of a process, network, or unit is its ability to adjust or adapt to any expansion. For example a central server is said to be scalable if it performs similarly when attending on either five clients or fifty clients. In Scrum, it means that the scaling mechanisms applicable for a single Scrum Team can also be used for larger projects with multiple teams.

Is Scrum scalable? Initially, Agile authors believed that Agile methodologies including Scrum was predominantly for small scale projects. This opinion was based on the fact that Scrum had not yet been applied on large scale projects. The Guide to the Scrum Body of Knowledge (SBOK™ Guide) gives comprehensive directions through which Agile methodologies including Scrum, can be scaled and applied on larger projects

When to scale? In small Scrum projects there is adequate scope for the self-organizing Scrum Team members to collaborate among themselves. The problem starts when team size expands and when there is coordination required between multiple teams. Scalability in Scrum can occur at three levels – Projects, Programs and Portfolios

How to scale? Scalability in Scrum is achieved primarily through the Scrum of Scrum (SoS) Meetings. Scrum recommends small teams; however if teams are larger it is recommended that they are divided into smaller teams who can meet occasionally to discuss their status.

What makes Scrum scalable? It is recommended that Scrum Teams should ideally have six to ten members. This does not mean that Scrum can be used only in small projects – it can be scaled to be used effectively in larger projects. If the size of the Scrum Team exceeds ten members, then multiple teams can be formed to work on the project simultaneously.

Scrum of Scrums facilitates synchronization between multiple Scrum Teams in larger projects. Team representatives update each other about team’s progress, challenges faced and coordination activities. Frequency of Scrum of Scrums (SoS) Meetings is determined by inter-team dependency, size of the project, recommendations by Scrum Guidance Body (SGB) and complexity level.

Scaling in Distributed Teams:

Scrum recommends collocated teams and face-to-face communication between team members. This is often not possible, as companies have distributed teams working in parallel across geographies and time zones. For the purpose of scaling, in larger projects employing distributed teams, the Scrum of Scrum Meeting can be held using video conferencing, chats, social media etc.

The ‘Convene Scrum of Scrums’ Process is facilitated by the Chief Scrum Master (or another Scrum Master). Representatives of various teams, usually the Scrum Master of individual teams or any other designated team member. For larger projects, involving a significant number of teams, multiple levels of these meetings may be convened. In larger projects, as it is difficult to have all participants together at one time, all important matters should be discussed.

The Scrum of Scrums meeting is usually held at predetermined intervals or when required, to collaborate and track progress, address impediments and dependencies across projects. An agenda for the meeting can be announced in advance by the Chief Scrum Master, allowing individual teams to consider the items for discussion. Impediments faced by individual teams, likely to affect other teams should also be indicated. Issues, risks and changes likely to affect multiple teams should also be communicated during this meeting.

Achieving Scalability:

Each team representative is expected to update other teams, usually in the form of four questions. (i) What has my team been working on since the last meeting?, (ii) What will my team do until the next meeting?, (iii) What were other teams counting on our team to finish that remains undone?, (iv) What is our team planning on doing that might affect other teams?

Result of Scrum of Scrums Meetings include Better Team Coordination facilitated coordination of work across multiple Scrum Teams, especially when there are tasks involving inter-team dependencies (as future tasks of one team may depend on the timely delivery of a task by another team). Discrepancies between work and deliverables are quickly exposed. The Scrum of Scrums is a forum where team members can transparently discuss issues and resolve them.

There is a common misconception that the Scrum framework can only be used for small projects. However, it can easily be scaled for effective use in large projects. Large or complex projects are often implemented as part of a program or portfolio. The Scrum framework can easily be applied to manage even programs and portfolios. The logical approach of the guidelines and principles in this framework can be used to manage projects of any size, spanning geographies and organizations. Large projects may have multiple Scrum Teams working in parallel making it necessary to synchronize and facilitate the flow of information and enhance communication. The Convene Scrum of Scrums is the process ensuring this synchronization. The various Scrum Teams are represented in this meeting and the objectives are to provide updates about progress, discuss challenges faced during the project, and coordinate activities. There are no set rules regarding the frequency of these meetings. The factors determining the frequency are the amount of inter-team dependency, size of the project, Scrum Guidance Body recommendations and the level of complexity.

In programs, important roles to manage Scrum programs are:

1. Program Product Owner—Defines the strategic objectives and priorities for the program

2. Program Scrum Master—Solves problems, removes impediments, facilitates, and conducts meetings for the program

These roles are similar to those of the Product Owner and Scrum Master, except that they meet the needs of their program or business unit rather than those of a single Scrum Team.

Similarly, in portfolios, important roles to manage Scrum portfolios are:

1. Portfolio Product Owner—Defines the strategic objectives and priorities for the portfolio

2. Portfolio Scrum Master—Solves problems, removes impediments, facilitates, and conducts meetings for the portfolio

The needs and structure of each organization are different. It is the responsibility of the Scrum Guidance Body to scrutinize the organization at different levels to understand and define appropriate application of Scrum and to act as a consulting body for everyone working on a project, program, or portfolio.

When applying Scrum to manage projects within the context of a program or portfolio, it is strongly recommended that the general principles of Scrum presented in the SBOK™ are adhered to. It is understood, though, that in order to accommodate the overall program or portfolio activities and interdependencies, minor adjustments to the set of tools, as well as to the organizational structure may be required.

Portfolios and programs have separate teams with different sets of objectives. Program management teams aim to deliver capabilities and to realize certain goals that contribute toward the achievement of specific program objectives. In contrast, the portfolio team has to balance the objectives of various programs to achieve the strategic objectives of the organization as a whole.

The problems and issues faced when using Scrum within a program or portfolio primarily involve coordination across numerous teams. This can lead to failure if not carefully managed. Tools used for communication need to be scaled to match the requirements of the many teams involved in a program or portfolio. Each Scrum Team must address not only internal communications, but also external communications with other teams and the relevant business stakeholders of the program or portfolio.

A Scrum of Scrums Meeting is an important element when scaling Scrum to large projects. Typically, there is one representative in the meeting from each Scrum Team—usually the Scrum Master—but it is also common for anyone from the Scrum Team to attend the meeting if required. This meeting is usually facilitated by the Chief Scrum Master and is intended to focus on areas of coordination and integration between the different Scrum Teams. This meeting is conducted at pre-determined intervals or when required by the Scrum Teams.

Scaling Scrum for the Enterprise is usually applicable to the following:

Portfolios, programs, and/or projects in any industry

Products, services, or any other results to be delivered to business stakeholders.

The term “product” may refer to a product, service, or other deliverable. Scrum can be applied effectively to any project in any industry—from small projects or teams with as few as six team members to large, complex projects with up to several hundred team members.

For Scaling Scrum for Enterprise, the following processes need to be followed:

Create Program or Portfolio Components—In this process, the Program or Portfolio Product Owner and key business stakeholders identify common components and resources required for the program or portfolio. The Minimum Done Criteria are defined and all business stakeholders are identified.

Review and Update Scrum Guidance Body—In this process, the Scrum Guidance Body recommendations are regularly reviewed by the members of the Scrum Guidance Body and are updated when and if necessary. In this process, changes in the membership of the Scrum Guidance Body are also handled.

Create and Refine Program or Portfolio Backlog—In this process, the Program or Portfolio Backlog is created, updated, and maintained. Recommendations for improvements of the Scrum Guidance Body Recommendations may be made and implementation deadlines may be adjusted based on changed requirements and/or progress of the projects in the program or portfolio.

Coordinate Program or Portfolio Components—In this process, components of the program or portfolio are coordinated. Dependencies between projects are addressed, common impediments are discussed, and best practices are shared. Sometimes, recommendations for improvements of the Scrum Guidance Body are made.

Many organizations all over the world are finding it hard to keep up with the fast-changing business scenarios, using the traditional project management methods. These scenarios may include periodic customer demands, fast-changing project requirements, and issues relating to support activities and so on. Increasingly, project managers and software developers have started to prefer Agile software development methods. Even the US Department of Defense, in a recent update to its procurement rules has made known its non-preference for ‘Waterfall model’-based project management solutions. Some of the most popular methods include Rational Unified Process, Scrum, Extreme Programming and Dynamic Systems Development Method.

An overview of the Agile methodology

The year 2001 saw the ‘Agile Manifesto’ being formulated by seventeen software programmers at Snowbird Resort in Utah, USA. The Agile Manifesto gives us twelve important principles, which include customer satisfaction, communication, co-operation, the importance of working software, and welcoming change.

Agile methods break-up complex tasks into small increments with nominal planning. Iterations are short time frames that may last between one to four weeks. The iteration involves a team with cross-functional skills. Planning, requirements analysis, designing, coding, unit testing, and acceptance testing are all taken care of by the same team. At the end of the iteration, a working product is presented to business stakeholders. This reduces overall risk and allows the project to adapt to changes swiftly.

An overview of the Scrum Framework

Scrum is one of the most popular Agile methodologies. As per the Scrum Book of Knowledge, Scrum is an adaptive, iterative, fast and flexible framework designed to quickly deliver significant value during a project. It ensures transparency in communication and creates an environment of collective accountability and continuous progress.

The typical Scrum project will include the below-mentioned steps:

The Project Vision is created during Business Stakeholder Meeting, following which the Product Owner develops a Prioritized Product Backlog. This includes a ranked list of business requirements written in the form of User Stories).

The Product Owner consents about the Deliverables only if they meet the previously agreed Acceptance Criteria.The Sprint comes to an end with a Retrospect Sprint Meeting where the Scrum team deliberates ways to develop processes as they move ahead into succeeding Sprints.

A Sprint Planning Meeting is the first activity within a Sprint, during which high priority User Stories in the Prioritized Product Backlog are considered to be included within the Sprint.

A Sprint usually lasts between one and six weeks, where the Scrum Team works to create theoretically shippable Deliverables or product increments.

During the Sprint, short yet extremely focused Daily Standup Meetings are coordinated by the Scrum Master where the Scrum Team discusses progress.

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 business 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.

Many organizations all over the world are finding it hard to keep up with the fast-changing business scenarios, using the traditional project management methods. These scenarios may include periodic customer demands, fast-changing project requirements, and issues relating to support activities and so on. Increasingly, project managers and software developers have started to prefer Agile software development methods. Even the US Department of Defense, in a recent update to its procurement rules has made known its non-preference for ‘Waterfall model’-based project management solutions. Some of the most popular methods include Rational Unified Process, Scrum, Extreme Programming and Dynamic Systems Development Method.

An overview of the Agile methodology

The year 2001 saw the ‘Agile Manifesto’ being formulated by seventeen software programmers at Snowbird Resort in Utah, USA. The Agile Manifesto gives us twelve important principles, which include customer satisfaction, communication, co-operation, the importance of working software, and welcoming change.

Agile methods break-up complex tasks into small increments with nominal planning. Iterations are short time frames that may last between one to four weeks. The iteration involves a team with cross-functional skills. Planning, requirements analysis, designing, coding, unit testing, and acceptance testing are all taken care of by the same team. At the end of the iteration, a working product is presented to business stakeholders. This reduces overall risk and allows the project to adapt to changes swiftly.

An overview of the Scrum Framework

Scrum is one of the most popular Agile methodologies. As per the Scrum Book of Knowledge, Scrum is an adaptive, iterative, fast and flexible framework designed to quickly deliver significant value during a project. It ensures transparency in communication and creates an environment of collective accountability and continuous progress.

The typical Scrum project will include the below-mentioned steps:

The Project Vision is created during Business Stakeholder Meeting, following which the Product Owner develops a Prioritized Product Backlog. This includes a ranked list of business requirements written in the form of User Stories).

The Product Owner consents about the Deliverables only if they meet the previously agreed Acceptance Criteria.The Sprint comes to an end with a Retrospect Sprint Meeting where the Scrum team deliberates ways to develop processes as they move ahead into succeeding Sprints.

A Sprint Planning Meeting is the first activity within a Sprint, during which high priority User Stories in the Prioritized Product Backlog are considered to be included within the Sprint.

A Sprint usually lasts between one and six weeks, where the Scrum Team works to create theoretically shippable Deliverables or product increments.

During the Sprint, short yet extremely focused Daily Standup Meetings are coordinated by the Scrum Master where the Scrum Team discusses progress.

Many organizations all over the world are finding it hard to keep up with the fast-changing business scenarios, using the traditional project management methods. These scenarios may include periodic customer demands, fast-changing project requirements, and issues relating to support activities and so on. Increasingly, project managers and software developers have started to prefer Agile software development methods. Even the US Department of Defense, in a recent update to its procurement rules has made known its non-preference for ‘Waterfall model’-based project management solutions. Some of the most popular methods include Rational Unified Process, Scrum, Extreme Programming and Dynamic Systems Development Method.

An overview of the Agile methodology

The year 2001 saw the ‘Agile Manifesto’ being formulated by seventeen software programmers at Snowbird Resort in Utah, USA. The Agile Manifesto gives us twelve important principles, which include customer satisfaction, communication, co-operation, the importance of working software, and welcoming change.

Agile methods break-up complex tasks into small increments with nominal planning. Iterations are short time frames that may last between one to four weeks. The iteration involves a team with cross-functional skills. Planning, requirements analysis, designing, coding, unit testing, and acceptance testing are all taken care of by the same team. At the end of the iteration, a working product is presented to business stakeholders. This reduces overall risk and allows the project to adapt to changes swiftly.

An overview of the Scrum Framework

Scrum is one of the most popular Agile methodologies. As per the Scrum Book of Knowledge, Scrum is an adaptive, iterative, fast and flexible framework designed to quickly deliver significant value during a project. It ensures transparency in communication and creates an environment of collective accountability and continuous progress.

The typical Scrum project will include the below-mentioned steps:

The Project Vision is created during Business Stakeholder Meeting, following which the Product Owner develops a Prioritized Product Backlog. This includes a ranked list of business requirements written in the form of User Stories).

The Product Owner consents about the Deliverables only if they meet the previously agreed Acceptance Criteria.The Sprint comes to an end with a Retrospect Sprint Meeting where the Scrum team deliberates ways to develop processes as they move ahead into succeeding Sprints.

A Sprint Planning Meeting is the first activity within a Sprint, during which high priority User Stories in the Prioritized Product Backlog are considered to be included within the Sprint.

A Sprint usually lasts between one and six weeks, where the Scrum Team works to create theoretically shippable Deliverables or product increments.

During the Sprint, short yet extremely focused Daily Standup Meetings are coordinated by the Scrum Master where the Scrum Team discusses progress.