Collaboration in Scrum

Collaboration in Scrum refers to the Scrum Core Team working together and interfacing with the stakeholders to create and validate the deliverables of the project to meet the goals outlined in the Project Vision. It is important to note the difference between cooperation and collaboration here. Cooperation occurs when the work product consists of the sum of the work efforts of various people on a team. Collaboration occurs when a team works together to play off each other’s inputs to produce something greater.

The core dimensions of collaborative work are as follows:

• Awareness—Individuals working together need to be aware of each other’s work.
• Articulation—Collaborating individuals must partition work into units, divide the units among team members, and then after the work is done, reintegrate it.
• Appropriation—Adapting technology to one’s own situation; the technology may be used in a manner completely different than expected by the designers.

Collaboration ensures that the following project benefits are realized:

1. The need for changes due to poorly clarified requirements is minimized.
2. Risks are identified and dealt with efficiently. For example, risks to the project are identified and assessed in the Develop Epic(s), Create Deliverables, and Conduct Daily Standup processes by the Scrum Core Team members. The Scrum meeting tools such as the Daily Standup Meeting, Sprint Planning Meeting, Prioritized Product Backlog Review Meeting, and so on provide opportunities to the team to not only identify and assess risks, but also to implement risk responses to high-priority risks.
3. True potential of the team is realized. For example, the Conduct Daily Standup process provides scope for the Scrum Team to collaborate and understand the strengths and weaknesses of its members. If a team member has missed a task deadline, the Scrum Team members align themselves collaboratively to complete the task and meet the targets agreed to for completing the Sprint.

Continuous improvement is ensured through lessons learned. For example, the Scrum Team uses the Retrospect Sprint process to identify what went well and what did not go well in the previous Sprint. This provides an opportunity to the Scrum Master to work with the team to rework and improve the team for the next scheduled Sprint. This will also ensure that collaboration is even more effective in the next Sprint.

To Know More,Please Visit www.scrumstudy.com

Why Empirical Process Control is Important in SCRUM?

In today’s rapidly changing market trends, the customer may imagine an ‘apple’ and the finished product made by the project team may be an ‘orange’. This though is not the main problem. If the customer is aware of what’s cooking from the start he can steer the team to the ‘apple’ side. But in actuality the customer finds out about the ‘orange’ only too late. In other words if inputs and processes are in control and are reliable, we can get reliable outputs (which are generally the case with Waterfall model). The problem arises when inputs and processes cannot be controlled rigidly which generally means that the outputs would be unreliable (the Agile/Scrum scenario). In such circumstances we need to look beyond the waterfall model and focus on Empirical Process Control which simply means you need to look at the outputs more frequently and if it is not as per your liking you go back to inputs and processes and tweak it accordingly.

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum we have a Project Vision Statement which can be viewed by all stakeholders and the Scrum Team; an open Product Backlog with prioritized User Stories, both within and outside the Scrum Team; clearly visible Scrumboards, Burndown Charts, and other information radiators; Daily Standup Meetings conducted making sure everyone’s aware of everything; and Sprint Review Meetings in which the Scrum Team demonstrates the potentially shippable Deliverables.

The following figure summarizes the concept of transparency in Scrum

Inspection in Scrum is depicted through the use of a common Scrumboard; collection of feedback from the customer and other stakeholders; review and approval of the Deliverables by the Product Owner and the customer.

The following figure summarizes the concept of inspection in Scrum:

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. Risk identification is performed and iterated throughout the project. Improvements can also result in Change Requests, which are discussed and approved. The Scrum Guidance Body interacts with Scrum Team members during many processes to offer guidance and also provide expertise as required. During the Sprint Retrospective, agreed actionable improvements are determined.

The following figure summarizes the concept of adaptation in ScruT

To Know More, Please visit www.scrumstudy.com

The Daily Scrum Update Using Scrumboard

The Daily Scrum is one of the most important aspects of the Scrum framework. Scrum’s transparency comes from openly viewable information tools such as the Scrumboard, which shows the progress of the team. The team uses a Scrumboard to plan and track progress during each Sprint.

The Scrumboard usually contains four to five columns to indicate the progress of the estimated tasks for the Sprint:

1. A ‘Stories’ column for the list of tasks (optional, usually a part of the Prioritized Product Backlog)
2. A ‘To Do’ column for tasks not yet started
3. An ‘In Progress’ column for the tasks started but not yet completed
4. A ‘Testing’ column for tasks completed but in the process of being tested, and
5. A ‘Done’ column for the tasks that have been completed and successfully tested.

At the beginning of a Sprint, all tasks for that Sprint are placed in the ‘To Do’ column and are subsequently moved forward according to their progress.

The Scrumboard should preferably be maintained manually on paper or a white board, but can also be maintained electronically in a spreadsheet.

The Scrum Team should change or add to the Scrumboard as required so that the board provides visual information and control about the work going on as agreed and committed by the team. Updating or referring to the Scrumboard during the Daily Scrum keeps the team focused on the tasks that remain and their priorities.

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

To Know More Please Visit www.scrumstudy.com

Importance of Sprint Backlog in a Scrum Project

What is a Sprint Backlog? Is it a baseline, a record or a report? Baseline is a project document, which, defines aspects of the project and, once approved, is subject to change control. It is used to measure project’s actual performance as against planned targets. A record maintains information on the progress of the project. A report provides snapshots of the status of different aspects of a project at a given point of time or for a given duration.

To answer this question, we need to understand what a Sprint Backlog is, its purpose and composition. The Scrum Team creates the Sprint Backlog and Sprint Burndown Chart using the User Stories and the Effort Estimated Task List during Sprint Planning Meeting. During Sprint Planning Meeting, the User Stories, which are approved, estimated, and committed during the Approve, Estimate, and Commit User Stories process, are taken up for discussion by the Scrum Team. Each Scrum Team member also uses Effort Estimated Task List to select the tasks they plan to work on in the Sprint, based on their skills and experience. The list of the tasks to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog.

It is common practice in Scrum that the Sprint Backlog is represented on a Scrumboard or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog. Once the Sprint Backlog is finalized and committed to by the Scrum Team, new user stories should not be added – however, tasks that might have been missed or overlooked from the committed user stories may need to be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future Sprint.

Another tool associated with the Sprint Backlog is the Sprint Burndown Chart. It is a graph that depicts the amount of work remaining in the ongoing Sprint. The initial Sprint Burndown Chart is accompanied by a planned burndown. The Sprint Burndown Chart should be updated at the end of each day as work is completed. This chart shows the progress that has been made by the Scrum Team and also allows for the detection of estimates that may have been incorrect. If the Sprint Burndown Chart shows that the Scrum Team is not on track to finish the tasks in the Sprint on time, the Scrum Master should identify any obstacles or impediments to successful completion, and try to remove them. A related chart is a Sprint Burnup Chart. Unlike the Sprint Burndown Chart which shows the amount of work remaining, the Sprint Burnup Chart depicts the work completed as part of the Sprint.

So, it is difficult to categorize the Sprint Backlog as a baseline, record or a report. And as Scrum professes minimum documentation, Sprint Backlog fulfills purposes of more than one project document. For more information on Scrum framework, you can read the Scrum Body of Knowledge (SBOK Guide). It can be downloaded for free in SCRUMstudy website: http://www.scrumstudy.com/download-free-buy-SBOK.asp

To Know More Please Visit www.scrumstudy.com

Agile vs Waterfall?

Agile and Waterfall are two different methods used in managing a project. Both the methods have their own pros and cons and choosing one model is based on many project-centric factors.

The Waterfall model is a progressive design process which in the software development industry goes through stages such as Conception, Initiation, Analysis, Design, Construction, Testing, Implementation, and Maintenance and steadily moves downwards similar to a waterfall flowing down. After one stage is completed it moves to another and every stage has its own goals. This model is based on the standard workflow process which is followed in manufacturing and construction industries.

The benefit of using this model is that a project is divided into separate compartments which in turn decrease the dependency on individuals of a team. Any team member who leaves the project during the transition stages would not affect the execution of the project. This method also requires concrete documentation.

The cons of this method is that it is inflexible. In this method it is not possible to go back to a previous stage to alter the design in anyway. Hence it is very important to collect the requirements at the initial stage. This method is based on the logic that once we spend considerable amount of time in gathering the comprehensive requirements at the start of the project helps in saving time and effort later on.

• Agile Method
  On the other hand Agile method is incremental approach. The team works on small modules and then responds to user’s altered requirements rather than following a pre-determined plan. The design is simple and changes can be made as work progresses.

When compared to Waterfall method, here the testing and responding to user change requirements can happen during the same time in the course of the project. Here interactions among stakeholders is prioritized as compared to tools and processes.

This method became popular in 1990s after the many found the drawbacks of traditional Waterfall methods.

Conclusion

As you can see both the methods have their own advantages. Though Agile was developed to combat the disadvantages found in Waterfall method, Waterfall method still is considered in environments which is stable

Agile is considered to be a lightweight approach. The team focuses on smaller areas of work and hence overhead becomes less. The cost of the project also becomes less. Agile is more suitable when the user requirements are not clear and where the business environment is not stable. Also successful implementation of Agile requires skilled developers and also stakeholders who know what they exactly want.

To Know More Please Visit www.scrumstudy.com

All about Time-boxing in SCRUM

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

• Efficient development process
• Less overheads
• High velocity for teams

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to avoid excessive improvement of an item (i.e., gold-plating).

Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing can lead to de-motivation of the team and may have the consequence of creating an apprehensive environment, so it should be used appropriately.

To Know More Please Visit www.scrumstudy.com

Release Planning Sessions in SCRUM

Release Planning Sessions are conducted to develop a Release Plan. The plan defines when various sets of usable functionality or products will be delivered to the customer. In Scrum, the major objective of a Release Planning Meeting is to enable the Scrum Team to have an overview of the releases and delivery schedule for the product they are developing so that they can align with the expectations of the Product Owner and relevant stakeholders (primarily the project sponsor).

Many organizations have a strategy regarding release of products. Some organizations prefer continuous deployment, where there is a release after creation of specified usable functionality. Other organizations prefer phased deployment, where releases are made at predefined intervals. Depending on the organization’s strategy, Release Planning Sessions in projects may be driven by functionality, in which the objective is to deliver a release once a predetermined set of functionality has been developed; or the planning may be driven by date, in which the release happens on a predefined date.

Since Scrum framework promotes information based, iterative decision making over the detailed upfront planning practiced in traditional waterfall style project management, Release Planning Sessions need not produce a detailed Release Plan for the entire project. The Release Plan can be updated continually as relevant information is available.

To know more please visit www.scrumstudy.com

All About Prioritized Program Backlog

The Prioritized Program Backlog plays a very similar role at the program level as the Prioritized Product Backlog does on project level. It identifies the requirements for the program and their priorities.

The items in the Prioritized Portfolio Backlog provide inputs to the various Prioritized Program Backlogs and, through Prioritized Program Backlogs, to Prioritized Product Backlogs of individual projects. As described for Prioritized Program Backlogs only minimal, if any, refinement of User Stories is done at this level, because the refinement is done in the projects and their specific Prioritized Product Backlogs.

There are a few differences, though:

The creation of the respective deliverables and their acceptance is done in the projects of the program. The done or acceptance criteria for each Product Backlog Item / User story may be defined on the program level.  Projects have to adhere to them but can add their own criteria.

The length of a Sprint is project specific and, generally, varies from project to project in a program. In addition, the velocity of different teams is, normally, not the same. Therefore, it is not necessary to have very granular User Stories at the program level. The refinement of User Stories at the program level goes only far enough to ensure that the respective story is clearly understood and tangible acceptance criteria for the program can be defined.

To know more, Please visit www.scrumstudy.com

What is Servant Leadership?

The preferred leadership style for Scrum projects is Servant Leadership. This term was first described by Robert K. Greenleaf in an essay entitled The Servant as Leader. Below is an excerpt where he explains the concept:






















The servant-leader is servant first…It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature….

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society? Will they benefit or at least not be further deprived? (Greenleaf 1970, 6)

Elaborating on the writings of Greenleaf, Larry Spears identifies ten traits that every effective servant-leader should possess:

1.  Listening—Servant leaders are expected to listen intently and receptively to what is being said, or not said. They are able to get in touch with their inner voice to understand and reflect on their own feelings.
2.  Empathy—Good servant leaders accept and recognize individuals for their special and unique skills and abilities. They assume workers have good intentions and accept them as individuals, even when there are behavioral or performance issues.
3.  Healing—The motivation and potential to heal oneself and one’s relationship with others is a strong trait of servant leaders. Servant leaders recognize and take the opportunity to help their colleagues who are experiencing emotional pain.
4.  Awareness—Awareness and particularly self-awareness is a trait of servant leaders. This allows them to better understand and integrate issues such as those related to ethics, power, and values.
5.  Persuasion—Servant leaders use persuasion, rather than their positional authority to gain group consensus and make decisions. Rather than forcing compliance and coercion as is typical in some authoritarian management styles, servant leaders practice persuasion.
6.  Conceptualization—The ability to view and analyze problems (in an organization) from a broader conceptual and visionary perspective, rather than focusing on merely the immediate short-term goals, is a unique skill of good servant leaders.
7.  Foresight—Their intuitive minds allow servant leaders to use and apply past lessons and present realities to foresee the outcome of current situations and decisions.
8.  Stewardship—Stewardship demands a commitment to serving others. Servant leaders prefer persuasion over control to ensure that they gain the trust of others in the organization.
9.  Commitment to the growth of others—Servant leaders have a deep commitment to the growth of people within their organization. They take on the responsibility of nurturing the personal, professional, and spiritual growth of others (e.g., providing access to resources for personal and professional development, encouraging workers to participate in decision making).
10.  Building community—Servant leaders are interested in building communities within a working environment, particularly given the shift in societies away from smaller communities to large institutions shaping and controlling human lives.

Scrum believes that all leaders of Scrum projects (including the Scrum Master and Product Owner) should be servant-leaders who have the above traits.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com

What is Servant Leadership?

The preferred leadership style for Scrum projects is Servant Leadership. This term was first described by Robert K. Greenleaf in an essay entitled The Servant as Leader. Below is an excerpt where he explains the concept:

The servant-leader is servant first…It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature….

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society? Will they benefit or at least not be further deprived? (Greenleaf 1970, 6)

Elaborating on the writings of Greenleaf, Larry Spears identifies ten traits that every effective servant-leader should possess:

1.  Listening—Servant leaders are expected to listen intently and receptively to what is being said, or not said. They are able to get in touch with their inner voice to understand and reflect on their own feelings.
2.  Empathy—Good servant leaders accept and recognize individuals for their special and unique skills and abilities. They assume workers have good intentions and accept them as individuals, even when there are behavioral or performance issues.
3.  Healing—The motivation and potential to heal oneself and one’s relationship with others is a strong trait of servant leaders. Servant leaders recognize and take the opportunity to help their colleagues who are experiencing emotional pain.
4.  Awareness—Awareness and particularly self-awareness is a trait of servant leaders. This allows them to better understand and integrate issues such as those related to ethics, power, and values.
5.  Persuasion—Servant leaders use persuasion, rather than their positional authority to gain group consensus and make decisions. Rather than forcing compliance and coercion as is typical in some authoritarian management styles, servant leaders practice persuasion.
6.  Conceptualization—The ability to view and analyze problems (in an organization) from a broader conceptual and visionary perspective, rather than focusing on merely the immediate short-term goals, is a unique skill of good servant leaders.
7.  Foresight—Their intuitive minds allow servant leaders to use and apply past lessons and present realities to foresee the outcome of current situations and decisions.
8.  Stewardship—Stewardship demands a commitment to serving others. Servant leaders prefer persuasion over control to ensure that they gain the trust of others in the organization.
9.  Commitment to the growth of others—Servant leaders have a deep commitment to the growth of people within their organization. They take on the responsibility of nurturing the personal, professional, and spiritual growth of others (e.g., providing access to resources for personal and professional development, encouraging workers to participate in decision making).
10.  Building community—Servant leaders are interested in building communities within a working environment, particularly given the shift in societies away from smaller communities to large institutions shaping and controlling human lives.

Scrum believes that all leaders of Scrum projects (including the Scrum Master and Product Owner) should be servant-leaders who have the above traits.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com
Follow us on twitter - @SCRUMstudy_

Determining Size of a Scrum Team

It is important for the Scrum Team to possess all the essential skills required to carry out the work of the project. It is also necessary to have a high level of collaboration to maximize productivity, so that minimal coordination is required to get things done.

The optimum size for a Scrum Team is six to ten members—large enough to ensure adequate skill sets, but small enough to collaborate easily. A key benefit of a six to ten member team is that communication and management are typically simple and require minimal effort.

However, there may also be drawbacks. One major drawback is that smaller teams are more significantly impacted by the loss of a team member than larger teams, even for a short period of time. To address this problem, it may be possible for team members to have expert knowledge and skills outside their own specific role. However, this may be difficult and depends on the type of project, industry, and size of the organization. It is also recommended to have back-up persons to replace any person who may have to leave the Scrum Team.

In situations where the Scrum Team size exceeds ten people, multiple Scrum Teams can be formed to work on the project. Large or complex projects are often implemented as part of a program or portfolio. The Scrum framework can also 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.

To know more, please visit www.scrumstudy.com