The Best in Scrum Master Certification and Agile Certification - SCRUMstudy provides High Quality Training and Certification for Agile and Scrum Master. We provide Interactive Training which covers all Project Management Roles and Core Principles.
If an entire project or portions of it are being completed under a contract, the contract defines the scope of work and the specific terms of the contract. The type of contract used influences project risk.
Some of the most common types of contracts used in Scrum projects are as follows:
Incremental Delivery Contract—This contract includes inspection points at regular intervals. It helps the customer or stakeholders make decisions regarding product development periodically throughout the project at each inspection point. The customer can either accept the development of the product, decide to stop the development of the product or request product modifications.
Joint Venture Contract—This contract is generally used when two or more parties partner to accomplish the work of a project. The parties involved in the project will both achieve some Return on Investment because the revenues or benefits generated will be shared between the parties.
Development in Phases Contract—This contract makes funding available each month or each quarter after a release is successfully completed. It gives incentive to both customer and supplier and ensures that the monetary risk for the customer is limited to that particular time period since unsuccessful releases are not funded.
Incentive and Penalty Contract—These contracts are based on the agreement that the supplier will be rewarded with a financial incentive if the project’s products are delivered on time, but will incur financial penalties if the delivery is late.
Other popular contract types include paying by features contract, time and materials contract, fixed price and fixed scope contract, and fixed profit contract.
As an Agile approach, Scrum is a highly flexible process tool and can be stretched and bent to fit any project’s requirements. It is best suited for projects that require breaking down a huge and an unplanned project into manageable chunks of work based on business priorities. As such, it can be used for any project system and by any team.
Scrum really shows its agility in projects that exhibit one or all of the following characteristics:
When one is working on a project where the scope is changing rapidly and new requirements are emerging every other day, Scrum’s iterative and incremental model of development permits modifications to be made to the project system rapidly and responsively.
When there is no consensus on a particular project management approach, the team can adopt Scrum, because its combination of some of the best and most pliable project management principles will help everyone be comfortable.
When there is marked ambiguity and indecisiveness on how to get software developed per industry requirements, the increased productivity and decreased risk rate that comes with Scrum makes it the logical choice.
It can certainly be said that Scrum is an ideal project management approach for software development projects. When being swept off your feet with its attractiveness it is good to keep certain points in mind before zeroing in on Scrum as the project management approach for a particular project.
First, Scrum is not a method, but an approach, a process tool, for managing the software development activity. Secondly, there are certain core values that must be observed in letter and spirit so that using Scrum can optimize results in better teamwork, enhanced communication, and quicker results.
For any project to be successful it is important to select appropriate Scrum Master(s) and identify relevant Stakeholders. In some projects, there may have been pre-conditions stipulating certain team members and their roles.
When there is flexibility in choosing the Scrum Masters, the following are important Selection Criteria:
Problem-solving skills—This is one of the key criteria to be considered while selecting Scrum Masters. The Scrum Masters should have the necessary skills and experience to help remove any impediments for the Scrum Team.
Availability—The Scrum Master should be available to schedule, oversee, and facilitate various meetings, including the Release Planning Meeting, Daily Standup Meeting, and other Sprint-related meetings.
Commitment—The Scrum Master should be highly committed to ensure that the Scrum Team is provided with a conducive work environment to ensure successful delivery of Scrum projects.
Servant Leadership Style— The servant-leader is servant first. It begins with the natural feeling that one wants to serve, to serve first. 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.
When identifying the Stakeholders, it is important to remember that stakeholders are all the customers, users, and sponsors, who frequently interface with the Product Owner, Scrum Master, and Scrum Team to provide inputs and facilitate creation of the project’s products. The stakeholders influence the project throughout its lifecycle.
Understanding what Scrum of Scrums is and how it works in the product development process is very important. The first thing to know about Scrum of Scrums is that it acquires relevance only for large projects where several Scrum Teams are involved. In this process Scrum Team representatives convene for Scrum of Scrums Meetings at predetermined intervals or whenever required, to collaborate and track their respective progress, impediments, and dependencies across teams.
Normally, one member from each Scrum Team will represent his or her team in the Scrum of Scrums Meeting. In most cases, this is the Scrum Master, but at times someone else may represent the team. A single person may be nominated by the team to represent them in every Scrum of Scrums Meeting, or the representative may change over time, based on who can best fulfill the role depending on current issues and circumstances. Each person involved in the meeting should have the technical understanding to be able to identify instances in which teams could cause each other impediments or delays. Other important participants of Scrum of Scrums meeting include Chief Scrum Master and Chief Product Owner.
The main purpose of the Scrum of Scrums Meeting is to communicate progress between multiple teams. The Chief Scrum Master (or any Scrum Master who would facilitate the Scrum of Scrums Meeting), can announce an agenda prior to the meeting. This allows individual teams to consider the agenda items in preparation for the Scrum of Scrums Meeting.
Any impediments being faced by a team, which may also affect other teams, should be indicated so they can be conveyed at the Scrum of Scrums Meeting. In addition, if a team becomes aware of a large scale issue, change or risk that may affect other teams that should be communicated at the Scrum of Scrums Meeting. Outputs from the process Retrospect Sprint may have issues that could impact multiple Scrum Teams and could be used as an input for effective Scrum of Scrums Meeting. These meetings are preferably short (but usually not Time-boxed to allow for more sharing of information between teams) where a representative from each Scrum team meets to share status of the respective teams.
The Scrum of Scrums Meeting is held at pre-determined intervals or when required by Scrum Teams, and these meetings facilitate the face-to-face sharing of information among different Scrum Teams through the Scrum of Scrums, issues, dependencies, and risks impacting multiple Scrum Teams can be closely monitored, which helps the various teams working on a large project better coordinate and integrate their work. It is the responsibility of the Chief Scrum Master (or another Scrum Master who facilitates the Scrum of Scrum Meetings) to ensure that all representatives have an environment conducive to openly and honestly sharing information, including feedback to other team representatives.
For larger projects, involving a significant number of teams, multiple levels of these meetings may be convened. Each Scrum Team representative will provide updates from his/her team in turn. These updates are usually 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?
The answers to these four questions provide information that allows each team to clearly understand the work status of all other teams. It is recommended that a dedicated conference room be made available for the Scrum of Scrums Meeting, where all the Scrum Team Representatives are comfortable.
In Convene Scrum of Scrums process, Scrum Guidance Body Expertise could relate to documented best practices about how to conduct Scrum of Scrum Meetings, and incorporate suggestions from such meetings in project work of individual Scrum Teams. There may also be a team of subject matter experts who may help the Chief Scrum Master facilitate the Scrum of Scrum Meeting. Some of the important outputs of the Scrum of Scrums meetings are: Coordination of work across multiple Scrum Teams. This is especially important when there are tasks involving inter-team dependencies. Incompatibilities and discrepancies between the work and deliverables of different teams are quickly exposed. This forum also gives teams the opportunity to showcase their achievements and give feedback to other teams.
By using Scrum of Scrums Meeting, there is collaboration across the organization as opposed to people working in closed teams concerned primarily with their individual responsibilities. The Scrum of Scrums Meeting is a forum where Scrum Team members have the opportunity to transparently discuss issues, impacting their project. The need to deliver every Sprint on time forces the teams to actively confront such issues early instead of postponing seeking resolution. This timely discussion and resolution of issues in the Scrum of Scrums Meeting greatly improve coordination between different Scrum Teams and also reduces the need for redesign and rework. Risks related to dependencies and delivery time tables are mitigated as well.
As companies progressively adopt Scrum as the preferred project management method over 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 Manager. 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 skillset 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 fit in a Project Manager in 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.
The duties and responsibilities of a traditional Project Manager have been divided among all the three core roles in a Scrum project. The Guide to the Scrum Body of Knowledge (SBOKTM) has captured the differences of traditional project management roles and Scrum roles very nicely.
Any change that arises in either the programs or portfolios may have a cascading effect on all dependent projects and Sprints. Therefore, it is advisable to minimize changes at these higher levels. If a change is required and all stakeholders are in agreement to make the change at these levels, the following should be kept in mind.
At Portfolio Level
It is not recommended to make changes in between two Portfolio Backlog Meetings.
If the change is minor, the Portfolio Product Owner should secure approval from the relevant stakeholders (e.g., sponsor, customer, and end user) and then add the requirements to the Portfolio Backlog. Product Owners of the program and project will consider those requirements for inclusion in future Sprints.
If the change is major, the portfolio efforts along with associated programs, projects, and Sprints need to stop, and a Portfolio Backlog Meeting should be conducted to determine next steps.
Portfolio Prioritized Product Backlog Meetings (also referred to as Portfolio Backlog Meetings), should be conducted at 4 – 12-month intervals. The frequency and impact of changes to a portfolio largely determine the time duration between two Portfolio Backlog Meetings. If there are several expected changes in portfolio, it is preferable to conduct Portfolio Backlog Meetings at more regular intervals (e.g., 4 – 6 months); but if there are fewer expected changes and if requirements are stable, the duration between two Portfolio Backlog Meetings could be increased (e.g., 9 to 12 months).
At Program Level
It is not recommended to make changes in between two Program Backlog Meetings.
If the change is minor, the Program Product Owner should secure approval from the relevant stakeholders (e.g., sponsor, customer, and end user) and the Portfolio Product Owner and then add the requirements to the Program Backlog. Product Owners for the project will consider those requirements for inclusion in future Sprints.
If the change is major, the program efforts along with associated projects and Sprints need to stop, and a Prioritized Product Backlog Meeting should be conducted to determine next steps.
Program Prioritized Product Backlog Meetings (also referred to as Program Backlog Meetings), should preferably be conducted at 2- to 6-month intervals. The frequency and impact of changes to a program largely determine the time duration between two Program Backlog Meetings. If there are several expected changes in program, it is preferable to conduct Program Backlog Meetings at more regular intervals (e.g., 2 to 3 months); but if there are fewer expected changes and if requirements are stable, the duration between two Program Backlog Meetings could be increased (e.g., 5 to 6 months).
The following figure demonstrates how changes can be managed within the Scrum flow for both portfolios and programs.
Familiarizing the feasibility team with known requirements:
While working on an agile project, especially one with volatile requirements or one that has a strict deadline, you won’t have deep requirements when you begin the Feasibility phase. A request or idea has been approved for a feasibility investigation, and no one has documented detailed requirements to this point. Your idea is relatively new, and you’re working rapidly to either start the project or dismiss it.
The information that is available is presented to the feasibility team. The idea usually has a champion or author who can meet with the team and go over the concept. This person brings in all the information they have at this point, whether it’s a diagram on a cocktail napkin, a detailed flowchart, or a mini functional specification. The following items can be analyzed during the Feasibility phase:
Rough sketches of process flow
A website where a competitor is already using the idea
If your idea comes from within, you may have a white paper created by someone to outline the idea.
What does a feasibility investigation look like?
When you present your idea to the feasibility team, they will provide initial feedback and subsequent commentary after performing their offline feasibility work. The initial review can provide positive feedback or identify issues immediately.
You should inform the feasibility team that candid conversation is not only desired but critical to the process—you don’t want to go forward with more extensive feasibility analysis if you don’t think the idea is viable. You should also prepare the idea owner for candid feedback. Encourage the owner to demonstrate their passion for the idea, but at the same time prepare them for frank conversation and a thorough review of the proposal.
The time you spend on feasibility analysis will depend on various factors such as the idea’s complexity, the availability of the feasibility team, and dependency on third parties to provide information. An average feasibility analysis begins with a 1- or 2- hour meeting that kicks off the process; at this meeting, one person discusses the known requirements with the feasibility team.
The feasibility team reviews the idea with the presenter, and team members ask questions about the customer, the project’s value, and potential technology needs. This first meeting may provide enough information to make the go/no go decision, but usually, a few questions remain that require team members to work offline to get the answers. This offline work may include the following:
Looking at existing code to see how it can support the request
Consulting with a vendor about a possible solution for the request
Doing deeper statistical analysis
Reviewing competitor functionality to see if they’ve addressed the same idea
Usually, the team regroups after 2 or 3 days to review their offline work. At this point, they generally have ample information to make the call about whether to continue to the Planning phase.
Scrum teams often referred to as development teams, responsible for the development of products and services, consist of a group of individuals who work on the customer requirements to create deliverables for the project. It is important for the team to possess all the essential skills to carry out the work in the project.
The optimum size for a Scrum team is six to ten members – large enough to ensure adequate skill sets and small enough to collaborate easily. However, a Scrum team can be organized differently depending on the type of project and the type of organization. We are going to look at some of the most common ways in which a Scrum team could be organized within a Scrum project.
Product Team – This is the easiest segregation of teams based on product or market. The team members have skill sets to match and develop the product. This team is particularly suited for the small feature set. Most start-ups use this team setup, as new products do not necessarily need complex features, to begin with, and could be developed and released with fewer features and more features added with a better understanding of the market. As the product develops, feature-based teams come into play.
Feature Team –When the focus is on the feature set of a product, a Scrum team could be structured as a feature team. This team is required if the product is too large for a single team to enhance or when a single product base is divided into multiple market segments. A good example is custom cell-phones from supercar manufacturers.
Component Team – A Scrum team could be structured as a component team when the focus is to improve components in a business. Components as a standalone feature do not deliver customer value. These components might require specialized members and expertise to work. An example would be apps developed for a specific phone which caters to a specific group of people.
Customer Centric Teams –A single core product may have variants that different users might be using. A customer-centric team can help in focusing how different features can be integrated into the existing product helping differentiate a product from its competition.
No Teams – One of the core principles of Scrum is Self-Organization. A Scrum team should be told what needs to be delivered but is not told how it should be delivered. That is why traditional team structures are no longer relevant for a self-organized Scrum team. A self-organized group will be best suited in a highly competitive and volatile market where constant changes are the norm.
These are the five different ways in which teams can be organized based on specific requirements.
“We are uncovering better ways of developing software by doing it and helping others do it.” This is how the Agile Manifesto starts. In simple words, the way people have learnt better ways of implementing Agile is by doing it and trying out things. As such practitioners have tried out multiple things and some of those have worked and some didn’t. However, with time, a few misconceptions started getting associated with Scrum. We will look at some of the most common ones.
a)Documentation – There is this belief in certain quarters that there is no documentation in Scrum. Obviously, not correct. Compared to traditional project management, there is less documentation in Scrum Documentation in Scrum is as per the requirement of the project and stakeholders and is kept to a minimum.
b)Planning –This is another misconception where people believe that there is no planning in Scrum. The reality is that unlike traditional project Management which involves a lot of upfront planning, Scrum believes in iterative planning because remember scope and priorities keep on changing in Scrum. As such there is no use planning for everything at the beginning of the project.
c)Only meant for collocated teams –Although it is true that the principles behind Agile manifesto state that, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”, still with teams working from all around the world, it is not possible to always have collocated teams. With globalization, you have companies with offices around the world and teams working together. Even with distributed teams, you could still have face-to-face conversations with the help of web conferencing tools. These are as good as being in the same room.
d)Only meant for Software Development – Since the Agile Manifesto was meant for Software Development and it started with Software Development, there is this misconception that Scrum cannot be applied in any other industry. That is actually not the case. With time Scrum framework also evolved and is currently being used in almost every industry. Scrum is best suited for projects where the domain is exploratory/unpredictable and a lot of change is expected.
e)Only meant for Small projects: Since Scrum recommends a team size of 6-10 people with some research showing the productivity of Scrum teams going down with anything more than 6 people in a team, it is erroneously believed that Scrum is meant only for small projects. It is true that Scrum recommends small teams but one Scrum project could have multiple Scrum teams. As such, you could easily scale up and deliver bigger projects. The 3rd edition of Scrum Body of Knowledge (SBOK Guide) has two additional chapters detailing Scaling Scrum for Large projects and Scaling Scrum for Enterprise.
These were some of the most common misconceptions about Scrum. Do let us know if you found the article useful. If you liked this article, do join our Linkedin Group for more such articles.
One of the Agile principles is, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” This is taken by most practitioners as the rationale for collocated teams. There have been several debates around the possibility of teams which are distributed and how that would work in an Agile specifically Scrum environment. You can read some very strong opinions on both sides of the divide. Agile manifesto makes it very clear that, it values “responding to change over following a plan” and probably that is what should be done. The way teams work, has been changing constantly and distributed teams are a reality in a globalized world. You have Scrum Masters in the US managing development teams working out of China or India on a daily basis. It cannot be avoided. What can be done is to follow the spirit of the Agile Manifesto which takes “face-to-face” conversation to be the most effective. Now a days, there are so many tools at our disposal that could give the same experience of face-to-face conversation even when the teams are thousands of miles away. Apart from the tools being used, there are few pointers that could help distributed teams coordinate work effectively.
Scrum Meetings – Once the team is set to function virtually, it is essential that all the meetings recommended by Scrum framework (refer to Scrum Body of Knowledge SBOK Guide) actually happen as scheduled. This would include for example, a Daily Stand-up but conducted virtually. One could use tools such as Skype or other web-conferencing tools (Webex or GotoMeeting) to attend these meetings. These meetings can also function as team-building sessions within a multicultural and multilingual team. Scrum master is required to take pro-active steps to ensure all team members attend these meetings and participate as required.
Communication – Distributed Scrum teams working from around the world might vary in terms of work ethics, office culture and language. So a common platform and language is required to deal with the differences. Factors such as different time zones, work timings and mode of communication should be clearly laid out to help establish clear and transparent communication channels.
Colocation – Sometimes as the work nears completion or if the project requires one or more teams to closely work together, the teams might need to be present at the same location temporarily. This will help in increasing team building efforts as the team members get to know each other and in turn will increase efficiency in delivering the project.
With globalization, evolution of distributed Scrum teams working in a virtual environment is an expected change and addition to how we deliver Scrum projects.
Read Full Article
Read for later
Articles marked as Favorite are saved for later viewing.
Scroll to Top
Separate tags by commas
To access this feature, please upgrade your account.