Last Seen Blogs
v4l3nt1n0
Untitled
the-sharpened-pencil
the-sharpened-pencil
aniwife
Anime Wife
sunnydropownsmywholeheart
moon also owns my heart
shinketsukarasu
You're always on my mind
Text
Role of a Scrum Master
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.
The bottom line here is we have less people doing same amount of work. This is without the need of a dedicated scrum master, as we just need to have a contingent plan altogether.
1 note
·
View note
Text
Role of Quality and Testing Teams in Agile Projects
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.
Regarding Testing, it is an altogether different approach in Agile frameworks. Instead of writing test cases from a requirement document build by a BA, even before any coding has started, the testers will have to write test cases for user stories as per the priority in an iteration just hours before actual coding takes place. It requires a collaborative approach between a business representative and a domain expert and/or programmer. Functional testing, exploratory testing, smoke testing, pair programming and more are done to ensure the quality of the iteration remains on the high side. When tests demonstrating minimum functionality are complete, the team can consider the story Done.
0 notes
Text
Role of Business Stakeholders in Scrum
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.
Hence to be successful in a Scrum project understanding the needs and requirements of the Business stakeholders plays a very critical part and most of the times make or break the project.
0 notes
Text
Role of Scrum of Scrums Meeting in Scaling Scrum
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.
Thus, a SoS is held to coordinate the interdependencies between the related projects. It may then be conducted to coordinate and manage dependencies across all projects.
0 notes
Text
Roles and Responsibilities in Scrum
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
Chief Scrum Master is responsible to coordinate Scrum-related activities in large projects which may require multiple Scrum Teams to work in parallel.
0 notes
Text
Role of the Project Manager on an Agile Project
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.
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 (SBOK) has captured the differences between traditional project management roles and Scrum roles very nicely.
0 notes
Text
Roles of Scrum Developers in Scrum Project
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
Participates in the Retrospect Project Meeting
0 notes
Text
Roles and Responsibilities of a Scrum Master
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.
The bottom line here is we have less people doing same amount of work. This is without the need of a dedicated scrum master, as we just need to have a contingent plan altogether.
1 note
·
View note
Text
SBOK®- The necessary guide for every Scrum Practitioner
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™)
Expert Scrum Master (ESM™)
0 notes
Text
Scalability of Scrum
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.
Scrum of Scrum of Scrums: In organizations that have several Scrum projects happening simultaneously, the Scrum of Scrums Meeting can be scaled up another level to a Scrum of Scrum of Scrums meeting. In this situation, a separate Scrum of Scrums Meeting is held to coordinate each group of projects that are directly related to each other.
0 notes
Text
Scaling Scrum to Program and Portfolio level
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.
In organizations that have several Scrum projects happening simultaneously, the Scrum of Scrums meeting can be scaled up another level to what is referred to as a Scrum of Scrum of Scrums meeting. In this situation, a separate Scrum of Scrums Meeting is held to coordinate each group of projects that are directly related to each other.
0 notes
Text
Scaling Scrum for Enterprises
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.
Retrospect Program or Portfolio Releases—In this process, the Program or Portfolio Product Owner and key business stakeholders get together to retrospect a program or portfolio Release and internalize the lessons learned. Often, these lessons learned lead to agreed actionable improvements to be implemented in future. releases. Sometimes, improvements to the Scrum Guidance Body may be recommended.
0 notes
Text
Scrum – Don’t implement it without being trained in it
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.
Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant business stakeholder(s) are provided a demonstration of the Deliverables.
0 notes
Text
SCRUM – A Boon for Management Consulting Teams
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.
This process continues till all the deliverables and tasks are completed in the consulting project. The high level of involvement and communication involved in the Daily Standup Meetings is the key to an effective implementation of Scrum. Thus, by following the above process, consulting teams can ensure speedy completion of projects with high quality outputs without getting bogged down by a lot of documentation and processes.
0 notes
Text
Scrum and Agile: How different are they?
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.
Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant business stakeholder(s) are provided a demonstration of the Deliverables.
1 note
·
View note
Text
Scrum and Agile: A brief look
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.
Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant business stakeholder(s) are provided a demonstration of the Deliverables.
0 notes
Text
Scrum and High Performance teams
In the field of organization behaviour, the notion of the high-performing team has been discussed. Many of today’s Customers need rapidly adapting development services. High-performing teams are the key to providing that service. A mature high-performing team is a united unit, not merely a throng of individuals. While such teams usually emerge by chance; a high-performing team can also be deliberately molded with an understanding of team member requirements in mind. Scrum framework which brings out the truly necessary essentials, can help with achieving this. While Scrum Framework increases the chances of such a team forming, it is not a necessary or sufficient condition for high-performing teams.
Certain enablers can herald formation of high-performing teams: Some of them come in the form of Human resource practices for the organization. However, they regularly get over-complicated or misapplied. Scrum team is often encumbered with overwhelming info, which cripples the ability to think clearly. The Scrum Core team members become burdened by esoteric language, process, principles or practices that clutter their minds and focus. Great Scrum Masters don’t strictly enforce working hours. What they do enforce is presence on the Daily Standups- everyone on a given team has to be there and there are penalties for being late. Daily Standups” instil discipline by requiring a fifteen-minute daily meeting.
Classic environmental enablers in Scrum include collocated teams, team rooms/war rooms, visible charts, and white boards. By being responsible for this environment, a great Scrum Master can help in creating high-performing teams that effectively address business’ needs. The product backlog is A Great Scrum Master’s best source of reality to give feedback as to whether they are making the right decisions and having the right conversations. With conversations a Great Scrum Masters can help the Scrum Team detect if understanding is there. Scrum advocates that the teams should have the freedom to decide how they will deliver the User Stories they committed to during the sprint planning.
High performing teams collaborate by visibility. With visible product backlog or a Scrumboard, Business Stakeholders see where effort is being applied. When a Product Owner can see where to apply effort, the Scrum Team members work together and do not flounder. In projects, much of the work is not easily visible and therefore self-organization is necessary. With visible work efforts Great Scrum Masters improve the odds that each conversation will be the right one and make reporting on team progress easy.
The Product Owner also has to balance between discipline and freedom, monitoring and separating what is crucial from what is incidental and hence can be delegated to the team. Great Product Owners maintain a disciplined process but allow freedom, both in choice of tools, rules, and in adding project-specific guidelines to the organization’s universal standards. Conversation can be setup by formal or informal processes language agreements, team location, and more. High-performing teams are basic assets that individuals, businesses, and organizations need to help them thrive. This approach; strictly enforces a few key things; be relaxed on others gives the discipline Scrum needs but allows the freedom Scrum members crave. Achieving this balance should be part of good practice on any Scrum team.
0 notes