SCRUMstudy: Lead, Follow, Scrum!

When something goes wrong with a project, who gets blamed?

If you are the Product Owner, Scrum Master or Project Manager, you’re probably saying that the leader gets the blame. If you’re a Scrum Team or development team member, you’re probably saying, “We always get blamed.”

What if the reality of the situation is it’s a bit of both, and both failures could be solved by a purposeful application of skilled follower-ship?

Rob Asghar wrote about this recently in his Forbes article “Why Followership Is Now More Important Than Leadership.” He makes a strong point that “Good, skilled followers are able to nurture good leadership.” He adds that “It’s a lost art in our narcissistic times.”

The article, which is worth reading, provides enough information to see that following Scrum principles and practices can—and already do—produce skilled followers who nurture their fellow coworkers and even their bosses.

The first of Asghar’s “five steps that you can take to nurture better leaders in your workplace” is “Stop being a consumer, and start being a producer” and includes this direction: “See yourself as a scout, producer and nurturer of talent that others might overlook.”

Scrum focuses on “today’s workers, who deliver significantly greater value when self-organized and this results in better team buy-in and shared ownership,” according to A Guide to the Scrum Body of Knowledge (SBOK™). Team buy-in and ownership encourage team members to see themselves as producers and not spectators with the right to criticize.  Self-organized teams foster an “innovative and creative environment, which is more conducive for growth.”

The Scrum Master certification course provided by SCRUMstudy Authorized Training Partners adds, “When selecting teams, another important aspect is to create backups for every person. Every member of the team will back up a ‘specialist’ member, which enhances the skill sets of team members.” Each specialist becomes responsible for teaching and nurturing the team member who is going to be his or her backup. Being a leader—even to just one other—begins to build an understanding of what issues managers and Product Owners face.

“Stop to listen attentively when a normally reserved member of the staff speaks up at a meeting” is another of Asghar’s steps. For Scrum Team members, learning this skill begins and is reinforced in the Daily Standup Meeting. Each member answers three questions, one of which is “What impediments am I facing in finishing my task?” When this is answered, the other team members take note and then meet with that coworker after the Standup to help find solutions. Listening without interrupting becomes very important in this setting, and it occurs in a group with no anonymity. The group knows who listens and helps and who does not.

Asghar says, “See yourself as a craftsperson, with each head-nod and each moment of applause helping polish a jewel or blossom a bud.” Opportunities for such leadership molding craftsmen come in the Retrospect Sprint and Retrospect Project meetings during a Scrum project. During the Retrospect Sprint meeting, “the Scrum Team gets together to review and reflect on the previous Sprint in terms of the processes followed, tools employed, collaboration and communication mechanisms, and other aspects relevant to the project. The team discusses what went well during the previous Sprint and what did not go well, the goal being to learn and make improvements in the Sprints to follow,” says the SBOK™. Notice the emphasis is on “what went well”—some head nodding—and then on “what did not go well” —some head shaking, perhaps.

During the retrospect meetings, members have the opportunity and onus of evaluating everything that happened in the Sprint and project. In the Retrospect Sprint meetings, any concerns with a leader can be discussed freely and passed onto that leader through the Scrum Master, who can put the most appropriate and effective spin on it. During the Retrospect Project meeting, which requires the Product Owner’s presence, the team members get to interact with leadership in an open meeting designed to face problems and find solutions. The lessons learned part of these meetings is a training school for both workers and leaders.

The ability to nurture leaders—and workers—to avoid things that go wrong in a project and make continual improvements is possible through Scrum and SCRUMstudy.

For interesting articles about Scrum and Agile, visit


How does Scrum treat risk differently?

Scrum and most of the traditional project management methods define risk as ‘uncertain event(s) that could positively or negatively affect the achievement of project objectives.’ Also, risks are identified, assessed, planned for, and communicated continually.


In Traditional project management models, there is emphasis on detailed upfront planning to identify, assess and determine risk responses for all project risks. During project execution, any project team member can identify risks and the project manager or the project management office/project support staff can update them in the risk log/register. The project manager regularly monitors and controls all risks, and usually identifies specific individuals in the team to take responsibility for different aspects of risks. In Scrum, any Scrum Team member can identify risks and the Product Owner can update the identified risks in the Risk Adjusted Prioritized Product Backlog. The Scrum principles of Empirical Process Control and Iterative Development enable the Scrum Team to constantly keep identifying risks and adding them to the Prioritized Product Backlog, where such risks are prioritized with other existing User Stories in backlog, to be mitigated in subsequent sprints. The Scrum Team has collective responsibilities for managing all risks for the Sprint.

Note: The Scrum specific terms used in this article are as per the Guide to the Scrum Body of Knowledge (SBOKTM) for more visit:

Risk mitigation in Scrum

Scrum is a light-weight framework for project management which is used for complex product development in volatile market conditions. With high competition, companies have to develop products fast and innovatively always adding value and greater customer satisfaction. Quick decision-making and prioritization help mitigate risks in a project. The constant flow of new information changes requirements which Scrum is tailored to handle well and risks are turned into valuable deliverables.
The Product Owner starts the Scrum cycle with identifying requirements of the client through a Stakeholder Meeting. It is up to the Product Owner to clearly outline the customer needs and place them in a Prioritized Product Backlog. Here risk plays a crucial role as it becomes essential to determine high risk elements and place them high in the backlog. The sooner these elements are identified and dealt with in early Sprints the better for the success of the project as the possibility of mitigating larger risks diminish with the progress of the project. Here the Product Owner plays a significant role in discussing various elements with the Scrum team and clarifying doubts. Thus the Product Owner gets a great deal of help from the Scrum Team in prioritizing requirements which the team in turn breaks down into definite User Stories and further into tasks.
The involvement of various stakeholders in the project with the technical personnel makes a mark in risk mitigation in Scrum. The “input-development-feedback” mechanism which is continuous in Scrum keeps everything transparent and pitfalls are readily visible. The Prioritized Product backlog is constantly groomed, i.e. it is analyzed and revaluated all the time as requirements change and/or issues crop up as development of a feature leads to finding a new element which demands immediate attention. Scrum as an Agile framework lets you do exactly that – be agile and incorporate changes in short notices. Scrum’s core principle of Empirical Process Control is thus practiced and upheld. In Scrum, planning is seen as an ongoing process and is represented by grooming of the Product Backlog and the Sprint Planning Meeting at the beginning of every Sprint. Unlike traditional waterfall methodologies where planning is detailed and upfront, this Scrum practice zeroes in on the risk factor. Yet, it is not to be taken for granted as active participation is required by the Product Owner, the Scrum master, and the Scrum Team to keep the mechanism running smoothly. Issues not addressed for long durations may turn into potential risks and take up more time and effort to resolve as time passes.
Some of the Scrum practices which help in mitigating risks are:
1. Flexibility of adding and modifying requirements
2. Regular feedback through the iterative nature of Scrum
3. Team ownership of Sprint Backlog items
4. Transparency ensures detection of risks and early communication
5. Iterative delivery reduces investment risk
In Scrum, it is important to learn and practice its basic principles which collectively and naturally help in effective management of risk.

Acknowledgement: The content has been borrowed from Original URL:

So, What am I Supposed to do?

When implementing Scrum, sooner or later steam members ask, “So, what am I supposed to do?” Understanding defined roles and responsibilities in a Scrum project is extremely important for helping the team implement the framework successfully.

Scrum roles fall into two broad categories, core and non-core:

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.  Those filling these roles are often referred to as the Scrum Core Team.

These roles include:

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 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 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—Non-core roles are those that are not mandatorily required for the Scrum project and may include team members who are interested in the project. They usually have no formal role or function in the project team, itself, but may interface with the team and may not be directly responsible for the success of the project. The non-core roles should be taken into account in any Scrum project.

Non-core roles include the following:

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

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

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 is responsible to coordinate Scrum-related activities in large projects which may require multiple Scrum Teams to work in parallel.

The SBOK™ Guide also suggests establishing a Scrum Guidance Body (SGB) as an optional role that 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. The SGB guides the work carried out by the Product Owner, Scrum Master, and Scrum Team.


This figure illustrates a typical interaction between the Scrum Core Team members and one type of Stakeholder, the customer.

The Scrum Core Team roles are essential for all Scrum projects, while the non-core roles will vary according the individuality of each company, project and group of stakeholders.

Acknowledgement: The content is borrowed from blog url: )