UPDATE FOR 2022 & 2023 with Tanmay’s latest knowledge on Agile Scrum Master Certification!
This course is about learning the latest Agile Scrum Methodology for the Software Development field. In this course, you will learn all other Agile methodologies along with detailed information on Scrum.
This course helps the students in understanding the fundamental principles that form the foundation of Agile. The course also explores the Scrum framework in deep detail and also blends an overview of the key practices for Agile. The course starts off with an introduction to the most frequently used agile framework with over 70% of agile projects using Scrum in one form or another, then it goes on to real-world examples to enable the students to apply the knowledge to solve real problems.
Scrum is the agile development process that allows teams to deliver usable software periodically throughout the life of the project, dynamically absorbing change and new requirements as the project proceeds. The course covers the Agile Scrum Master Certification curriculum in detail and enables the students to clear the exam.
Through this course, experienced project managers can grow in their careers and get the next level of opportunity as an Agile Scrum Master and the junior team members can learn the process of the Agile Scrum methodology.
This course will give the insight necessary to achieve the Agile Scrum Master roles along with the fundamentals of Agile Scrum Master methodology for you to adopt into your organization. Also, you will be able to gain a 100% understanding of how to apply SCRUM by understanding Product Backlog, Epics, Story Points, Sprints, SCRUM lifecycle, Roles of the Scrum Team/Product Owner, and Scrum Master.
Through this course, you will be an effective servant leader and Scrum Master.
The biggest target audience is at any experience level who wants to learn Agile Scrum in detail and apply it in their career to grow or in the organization to grow!!!
Course Value
As a project management professional, you can derive value from this course in multiple ways
-
You learn best practices for Scrum and other Agile methods
-
You will gain deep insight into Scrum and discover new ways of leading project management teams and delivering value to customers
-
You will receive practical guidance on how to implement these practices within your organization and how to maximize their value
-
It positions you well to be an evangelist and champion in the Agile adoption journey for your organization
Topics Covered in this Course
These are the topics covered in the course
-
We will define what Agile is. Review the Agile manifesto and 12 supporting principles in Agile. We will also explore the journey of successful Agile and Scrum adoption.
-
We will cover the Waterfall project management approach as well as become familiar with a number of other agile frameworks including Lean, XP, Kanban, Crystal, and DSDM. We will also cover how DevOps as an engineering discipline compliments Agile by accelerating the delivery and deployment of valuable software. Furthermore, we will review how agile should be linked with IT service management.
-
We will cover scrum value, scrum pillar, scrum lifecycle, and scrum ceremony including sprint planning, daily scrum, sprint reviews, and spring retrospectives. We will also cover various scrum artifacts including the product backlog, sprint backlog, and release backlog.
-
We will cover scrum roles. A product owner, the scrum master, and the development team. We will focus more on the scrum master role including some of the dos and don’ts.
-
We will cover the user stories, epics, and user story parts. We will talk about the product roadmap as well as the release and sprint plan. We will also cover the estimation techniques including story points and ideal time. We discuss planning poker and affinity estimates. Will talk about information radiators and communicating project progress and status including burndown charts, burn-up charts, and other information radiators. We will also talk about a scrum team that stays in control of the project work by making form decisions in a collaborative way with key stakeholders.
-
We are going to explore some of the common challenges and counters while scaling agile for use in large projects. To explain the scrum of scrum works and as well how product coordination teams and feature teams coordinate the work of multiple teams working on a single project. Will explain how scrum is implemented in a distributed environment. We will talk about the SAFe framework and how to scale agile. Will talk about system thinking and determining when agile should be used and when it should not be. Will cover how tools can be used in Scrum to improve performance.
Agile - Thinking
-
1Introduction
-
2Welcome to the Course!!
Welcome to the Agile Scrum Master Workshop
My name is Tanmay Panchal and I am the Agile Scrum Master Professional
I have over 22 years of project management experience in the IT sector, the public sector, and as an Entrepreneur
What is important for you, I have over 15 years of experience in Exam preparation coaching
-
3What you will learn in this course?
To become an effective Scrum Master
and pass the Agile Scrum Master Exam
You will acquire the knowledge and insight necessary to lead an Agile and Scrum Adoption efforts in your organization
You will learn how to be an effective servant leader who can assist your team to adopt and utilize the best practices of Scrum and become a high performing team
You will learn about Agile in terms of project management approach and other methods in addition to Scrum
You will also learn the value DevOps processes brings through the Agile transformation and establish the link between Agile project management and the management of business services they enable
Over 50% of Agile project use Scrum making Scrum the most popular Agile method
Agile is a project management approach that is well suited for the projects that are complex and uncertain
You will learn key concepts
This course will also provide guidance about
How to apply Scrum concepts to your organization?
You will learn how Scrum as value to the development through which you can deliver your high-quality products
This course covers the role, ceremonies, and artifacts of Scrum
As well as best practices of Scrum methodology
Anybody who is looking to update their knowledge of the software development project management approach will be beneficial from this course.
It is advisable that the participant has some background of the project management but it is not mandatory or compulsory.
Course Value
As a project management professional, you can derive value from this course in multiple ways
You learn best practices for Scrum and other Agile methods
You will gain deep insight into Scrum and discover new ways of leading project management teams and delivering values to customers
You will receive practical guidance on how to implement these practices within your organization and how to maximize their value
It positions you well to be an evangelist and champion in the Agile adoption journey for your organization
Topics Covered in this Course
These are the topics covered in the course
We will define what Agile is. Review the Agile manifesto, 12 supporting principles in Agile. We will also explore the journey as a successful Agile and Scrum adoption.
We will cover the Waterfall project management approach as well as becoming familiar with a number of other agile frameworks including Lean, XP, Kanban, Crystal, and DSDM. We will also cover how DevOps as an engineering discipline compliments Agile by accelerating the delivery and deployment of valuable software. Furthermore, we will review how agile should be linked with IT service management.
We will cover scrum value, scrum pillar, scrum lifecycle, and scrum ceremony including sprint planning, daily scrum, sprint reviews, and spring retrospectives. We will also cover various scrum artifacts including the product backlog, sprint backlog, and release backlog.
We will cover scrum roles. A product owner, the scrum master, and the development team. We will focus more on the scrum master role including some of the dos and don’ts.
We will cover the user stories, epics, and user story part. We will talk about the product roadmap as well as the release and sprint plan. We will also cover the estimation techniques including story points and ideal time. We discuss planning poker and affinity estimates. Will talk about information radiator and communicating project progress and status including burndown chart, burn-up charts, and other information radiators. We will also talk about a scrum team that stays in control of the project work by making form decisions in a collaborative way with key stakeholders.
We are going to explore some of the common challenges and counters while scaling agile for use in large projects. To explain the scrum of scrum works and as well how product co-ordination teams and feature teams co-ordinate the work of multiple teams working on a single project. Will explain how scrum is implemented in a distributed environment. We will talk about the SAFe framework and how to scale agile. Will talk about system thinking and determining when agile should be used and when it should not be. Will cover how tools can be used in Scrum to improve performance.
Will deal with how to achieve Agile adoption in our organization. Will learn about different approaches to conduct the transition. We cover the changes necessary to the organization's culture and ecosystem to enable agile for the try. Specifically, we discover how to empower the self-organizing team, a foundational concept in Agile.
Agile - Other Frameworks
-
4Definition of Agile and Scrum
Welcome to this session of Agile Scrum Master Workshop
The purpose of this session is to introduce you to Agile as a Project Management Approach & Scrum as an Agile method.
After completing this session,
You will be able to define what both Agile and Scrum is
You will be able to articulate the benefits of being Agile
You will be familiar with the Agile Manifesto and its supporting 12 guiding principles
Also, you will understand the concept of continuous improvement within the concept of Scrum adoption
There are two main approaches to managing project – There is the Waterfall Approach and the Agile approach.
Will talk about the Waterfall approach later in the workshop but to summarize, it involves the big planning upfront in order to determine the detail scope of the project and establish the project’s performance base lines.
Once executing begins, actual results are compare to the base lines in order to determine the health of the project.
The Agile approach is for the projects that are more complex and uncertain. In Agile, there is no heavy detail planning upfront. Rather in Agile project evolves as short increments are completed.
One of the top leaders in the Agile world – Scott Ambler defines Agile this way:
“Agile is an iterative and incremental evolutionary approach to project development which is performed in highly collaborative manner by self-organizing teams with just enough ceremony that produces high-quality software in a cost effective and a timely manner which meets the changing needs of its stakeholders.”
- Scott Ambler
Agile Definition – Agile software development describes an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end users(s).
It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.
SCRUM Definition – Scrum is a framework for project management that emphasizes teamwork, accountability and iterative progress toward a well-defined goal. The framework begins with a simple premise: Start with what can be seen or known. After that, track the progress and tweak as necessary. The three pillars of Scrum are transparency, inspection and adaptation.
Agile is a family of light weight, quality-driven approaches to software development which evolved in the late 1990’s and response to the burden of heavy documentation and frequent change
In Feb’ 2001, 17 leading software developers signed the Agile Manifesto.
-
5Agile - Manifesto and 12 Guiding Principles
The Agile Manifesto is a foundational document of all Agile methods and it reads like this.
We are in covering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Let’s take a look at the four main points in the Manifesto
1. Individuals and interactions over processes and tools – Means valuing people more highly than processes or tools is easy to understand because it is the people who respond to business needs and drive the development process.
2. Working software over comprehensive documentation – Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in details.
3. Customer collaboration over contract negotiation – Agile has the value of customer collaboration throughout the development process. This meant the customer will be involved at regular intervals for periodic demos, daily part of the team, and attending all meetings.
4. Responding to change over following a plan – With Agile, the shortness of an iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration. Agile’s view is that changes always improve a project; changes provide additional value.
There are also 12 guiding principles that support Agile Manifesto:
Highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity – the art of maximizing the amount of work not done – is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
-
6Advantages of SCRUM
In 1986, the scrum was first introduced by Hirotaka Takeuchi and Ikujiro Nonaka.
They described it as a new approach to commercial product development that will increase speed and flexibility. They actually called it a rugby approach.
And then in early 1990, this method was first referred to the single word – SCRUM
SCRUM is approved as an Agile software development method providing significant benefits over the traditional waterfall approach.
For example,
Higher productivity and lower development costs – this is accomplished by reducing waste and irregularities by only developing what is absolutely essential for the customer.
Improved stakeholder satisfaction – a collaboration between the developers and the customer results in clarity about what is to develop and the ability to respond to changing needs and priorities which leads to actually delivering the value the customer wants.
Higher quality software – using techniques like test-driven development, continuous integration, acceptance test-driven development, and refactoring can lead to nearly defect-free software.
Improved employee engagement and job satisfaction – by empowering a team to be self-organizing, the team is able to determine how it is going to deliver the value to the customer and establish a sustainable pace forever.
Faster time to market and early ROI – By incrementally delivering value or working software to the customer in short iterations, working software can be deployed sooner and the customer can realize an early return on investment.
Scrum is now the leading agile method with more than 50% of agile projects using SCRUM.
Features that make scrum so popular:
It offers simplicity and proven results
Other agile engineering techniques
It emphasize small teams and team empowerment
It welcomes changes to requirements
It allows working from a single source of prioritizing work items
It includes daily status meetings
It offers team commitment to the potentially shippable software at the end of each sprint
The chart illustrates how the agile method delivers value faster. In the traditional approach, the chart on the right - you can see that the customer has to wait until the end of the project for the delivery of the working software and the realization of the return on investment.
Scrum: Delivers value at the end of each Sprint.
Looking at the chart on the left, you can see how value is delivered clearly and incrementally at the beginning of the project.
Adopting Scrum can be an effort that takes some time. There is likely to be some organizational gravity that resists the adoption of Scrum. So it is going to be helpful to ask some key questions:
Has the investment in scrum paid off?
What is our next area of improvement?
Should we continue with Scrum?
Are we better off than before?
Are we reproducing better products?
Do our products have fewer defects?
Are we able to ship faster than before?
The answers to these questions do not need to be necessarily arrived at through a precise or scientific effort. However, testing and measuring the results of any effort is necessary to discover whether or not we have been successful.
-
7Points Covered in this Section
Agile is an iterative, incremental method for developing products
Scrum is the most popular Agile methodology
Scrum provides value to the organization in the form of higher productivity, reduced cost, better quality, and more engaged and satisfied employees
Scrum relies on frequent feedback and experimentation resulting in better predictability and flexibility
The actual results of SCRUM adoption should be tested and measured
-
8Quiz
Scrum - Events and Artifacts
-
9Agile - Other Frameworks
Welcome to this session.
After completing this session, you will be able to explain the features, strengths, and limitations of software development using approaches including the traditional Waterfall as well as various Agile methods including Lean, Extreme programming, Crystal, and DSDM.
You will also be able to describe the role of DevOps as a discipline that is critical to the success of Agile teams
You will also understand how to apply agile methods to IT service management
Any method which is incremental & iterative is inherently Agile. Under the Agile umbrella, is a family of methods including:
Scrum
Extreme Programming
Crystal
Kanban
Lean
Feature-Driven Development
Dynamic System Development Methodology (DSDM)
All of these methods Share Agile practices and values, like
Embracing change
Lightweight or lean documentation
Daily Stakeholder collaboration
Incremental Delivery and
Continuous improvement
-
10Waterfall Approach Challenges
Before we talk about some agile methods, let’s review the traditional software development life cycle when using a Waterfall approach. This approach is called waterfall because of the series of steps to create the final product.
You can see that the initial step is to collect all of the requirements necessary. That’s followed by Design phase which is where the software structure determines then in the Implementation phase the software is actually developed
In the Verification phase, the software is tested both for correctness and acceptance. And then once the software is being deployed, there is the Maintenance phase.
This traditional approach is perfectly suitable and logical for project management. However, when it comes to software development where there is a high level of complexity, uncertainty, challenges
Dealing with change
Change is not only difficult. It’s very expensive. For example, if you discover critical design flow during verification or get the requirements to change during implementation,
The amount of rework needed to correct this can be probative.
The result is a tendency to resist change which intern compromises the spirit of customer collaboration.
If you have a project that is very clear in terms of its requirements and is unlikely to experience too many changes.
The waterfall can be a reasonable and effective approach for projects to simply migrate features or products from one platform to another. Keep in mind that both the problem and the solution must be clear for this approach to be a good choice.
Let’s look at some Agile methods and see how they are likely a better fit for projects that are complex and uncertain. Like software development.
-
11Agile - Extreme Programming (XP)
XP was developed primarily to
Respond to the high cost of changing requirements and
Establish strong engineering practices to improve the quality of software and then take them to the extreme. For example
If testing is good, let’s do unit testing, integration testing, and acceptance testing
If the design is good, let’s do design all the time and make sure we do a retrospective at the end of each iteration
If simplicity is good, let’s eliminate anything that does not add value and make sure we always do the simplest thing.
If the review is good, let’s continuously improve by making sure we do reviews and retrospectives at the end of each iteration.
If communication is good, let’s make sure our team space and tools encourage face to face osmotic communication.
If iterations are good, let’s make sure we give regular stakeholder feedback in order to improve the quality of software and make sure we deliver the value the customer wants by doing the shortest possible iterations.
XP introduces the number of revolutionary concepts to software development and many have become standard practices:
Continuous Integration – this is the practice of regularly integrating new code into the system and using the automated testing to determine the status of the integration
Test-Driven Development – this is where the team writes the test before developing the code
On-site Customer – XP essentially makes the customer part of the team. The customer is expected to be on-site and participate with the team on a daily basis
User Stories – this practice is a quick and effective way to capture customer requirements and make sure there is an agreement between the customer and the developers regarding what should be developed.
Other XP practices include,
Collective Code Ownership
Creating a coding standard for the project
Creating a system metaphor to increase communication effectiveness
Pair programming
Establishing sustainable pace forever
XP team has the following characteristics:
They are self-organizing - Team are empowered to decide for themselves how they are going to execute the project without top-down management and control
They are cross-functional - The idea is to have generalizing specialists as team members. These are team members who specialize in one area but have enough knowledge to participate in the other roles that are part of the XP team.
They compromise and collaborate – Team members including the customer, the coach, the programmers, the trackers, and the testers collaborate in order to reach an agreement on what exactly needs to be developed.
XP roles fall into 3 different categories – Customers, Programmers, and Testers
Customer – Customers are the business experts and can include
Product Managers
Domain Experts
Business Analysts
Interaction Designers
Programmers – Programmers are the
Implementation experts
As we said they are generalizing specialists, meaning programmers can exchange roles as necessary during the execution of the project
Ideally, there are 6 to 10 on a team
Testers – Testers are the
Quality experts and
Focus on Unit testing
Integration testing
Acceptance and
Exploratory testing
-
12Agile - Crystal
-
13Agile - DSDM
-
14Agile - Lean
-
15Agile - Kanban
-
16DevOps as a Discipline
-
17Integration of Agile and ITIL Roles
-
18Points Covered in this Section
-
19Quiz
Scrum Roles
-
20Introduction
This section will have detailed information about the following:
1. Scrum Pillars and Values
2. Scrum Lifecycle
3. Scrum Ceremonies
4. Definition of "Done"
-
21Scrum - Pillars and Values
-
22Scrum - Life-cycle
-
23Scrum - Ceremonies
-
24Definition of Done
-
25Points Covered in this Section
-
26Quiz
Agile – Estimation, Plan, Monitor and Control
Agile on Complex Projects
-
32Introduction
-
33User Stories and Epics
-
34Good User Stories
-
35Story Cards and Splitting Stories
-
36Prioritize User Stories - Three Model Prioritization
-
37Velocity
-
38Planning - Levels
-
39Estimation
-
40Ideal Time
-
41Planning Poker
-
42Affinity Estimation
-
43Tracking Releases and Sprints
-
44Points Covered in this Section
-
45Quiz
Additional Learning Content - Agile - Adoption
-
46Introduction
-
47Agile - Scale is Challenging
-
48Managing The Product Backlog & Planning Large Projects
-
49Scrum of Scrums & Scrum Events
-
50Scaled Agile Framework® (SAFe®)
-
51Disturbed Teams - Things To Do & Cultural Sensitivity
-
52Organizational and Project Related Factors
-
53Agile Tools and Testing Pyramid
-
54Points Covered in this Section
-
55Quiz
What's Next
-
56Why Additional Learning Content Section?
-
57Introduction
After completing this section, you will be
Come up with the transition plan for moving an organization to Agile
Identify the important milestones in the plan
Identify symptoms of resistance to change and be prepared to overcome them
Articulate the principles of self-organization and cross-functionality
Explain the physical and cultural changes needed in the ecosystem in order to enable Agile.
-
58Successful SCRUM Adoption – Five Attributes
Using the ADAPT, there will be five attributes required for successful scrum adoption.
Awareness – the awareness that the current process OR approach is not working. The first step is realizing that change is necessary.
Desire – adopting scrum can require a significant change in an organization’s culture. Therefore, there must be a clear desire to adopt scrum and confidence that will result in the improvements desire.
Ability – the team must be willing the effort necessary to actually implement SCRUM. This effort is going to include coaching, mentoring, and potentially working with senior management to gain their support for the adoption effort.
Promote – is widely that the team will have to share successes and wins as a result of scrum adoption to senior management in order to have their continued support.
Transfer – last but not least is transferring and spreading the advantages of scrum throughout the company.
-
59SCRUM Teams - Balance Scorecard
When considering the outcomes we can categorize the desired results to the four different factors, just like the balanced scorecard
The balanced scorecard concept, originally proposed by doctors Robert Kaplan and David Norton is
A performance measurement framework that adds strategic non-financial performance measures to traditional financial metrics. In order to give managers and executives a more balanced view of organizational performance. This framework has four categories
Financial
Customer
Process
Innovation
Mike Cohn suggests we can benefit by using the balanced scorecard concepts for SCRUM teams, by these four categories
Operational Excellence
User Orientation
Business Value and
Future Orientation
We can define specific measures for each category
Operational Excellence
For example, as a part of operational excellence
We can define predictability metrics, such as did the project end at the desired Sprint, or did it require extra Sprints?
We can also define productivity measures such as functionality delivered per release or features developed per developer
We can measure quality metrics such as defects found in internal tests, continuous integration tests, or those that are tested by customers.
User Orientation
For user orientation, we can
Measure the downtime experienced by users
We can also find measures for user satisfaction through surveys or net promoters scores
Business Value
For business value,
We can measure how frequently incremental value delivered to the customer
We can also measure the substance of releases in terms of user-visible features
Future Orientation
For future orientation
We can measure employee satisfaction in terms of employee complaints or employee satisfaction scores. This would then indicate how the organization is positioned for future success.
We can also measure the understanding and maturity of SCRUM with the key indicator being attendance and participation in scrum ceremonies.
-
60Agile Adoption – Patterns
One of the first decision points is whether
Start Small – we should start small that is picking a few projects to pilot before expanding or
All In – whether we should do a full-blown all-in type of transition
Starting small is
Less risky and
That you pick the team that is most suitable for the transition.
By having the luxury to select the team and having the energy to focus exclusively to one or two teams that are working on pilots
You can almost guarantee that the transition will be successful
This way you can defer the radical change and
Likely encounter the less initial resistance
The all-in approach has the advantage of time. You don’t have to wait for the pilot projects to be completed and then convince everybody that the pilot is successful
The transition will be quicker
The overall cost for the transformation will likely be lower
Seeing other’s experience, the same kind of issues will also let you learn from the other teams
The all-in approach will require more top-down buy-in support and
Having that always assist in making changes
-
61Agile Transformation – Other Approaches
Here are some other approaches conducting an agile transformation
The first one is to make a public display OR
You can keep work in stealth mode. The public display demonstrates commitment and the major facts that you saying it increases the likely hood that you will actually do it. However, the stealth mode reduces the initial resistance and allows you to pick and choose when you want to go public.
With regards to growing the agile tribe, there are two approaches
One is to split the first successful team and assign them to other teams to sow the seeds of Agile and
An alternate approach is to first grow the existing team until it can no longer be just one scrum team and then split that team and grow team members organically.
"Split and Seed" is faster because you get the multiplier effect. "Grow and Split" are likely to give you a deeper in the definition because the entire team is strict in the principles.
The next choice is to do with
The technical practices like pair programming or continuous integration. You can introduce them early to get significant success with early adoption or
You can introduce them in stages. The benefit of starting early with practices as you can almost instantly see the benefits
These practices are so complementary in nature to the incremental and iterative processes that you would increase the chances of success if you start early.
-
62An Iterative Adoption Process
The process of transitioning to agile should be managed like a project itself iteratively and incrementally.
Among the first thing, you should do is to seek an influential sponsor who is committed to the project. If you do not have a strong sponsor, it may not be even good enough to begin the journey.
Another approach is the user steering committee for the transition. You may call it to say the Enterprise Transition Committee or ETC. This consists of the evangelist who initiates the change, assists teams, encourage stakeholders, and so on. They would also identify potential issues and organize the improvement committee that surrounds them.
The ETC should lead the process of the creation of a product backlog for the transition along with identifying specific milestones and then track the progress of the transition project. They should then set up the sprint and commit the closing of these items just like any other agile team would do.
If you are going to choose the pilot approach for adopting scrum, it is important that you select the pilot project carefully. If you select the project that’s too small or too short in duration or unimportant, it might be criticized just being a Miki-mouse pilot. Even if you succeed with the pilot, people will dismiss and say that it can’t be replicated for bigger or more important projects.
On the other hand, if you pick something too large, too long, or too critical, you might end up with more limelight on you than you want.
It is important to set and manage the proper expectations for the transition journey. Don’t promise too big or too less which may impact the transition. If you failed in any scenario, will not be considered seriously.
In terms of managing expectations, say that scrum definitely would be better, also for one that the journey would be difficult and that everyone should be willing to encounter some pitfalls along the way.
Some of the specific things you should be prepared for inclusion in the beginning – most teams have a tendency to overestimate and under deliver. This should actually be okay because the team will need about three or four sprints to establish their baseline velocity and the likely hood is very high that the team will still deliver more value than previously done.
There are some common complaints are likely going to happen
The team will say that they spent all of their time in meetings such as daily scrum, sprint planning, sprint reviews, sprint retrospective. On the positive side, you are now an insider and have a say about what happens in the team.
Testers are likely to complain about having to test intermediate, unfinished stuff even if you have no intension of delivering anything at the end of the sprint. To them, you need to emphasize that the potentially releasable product should be developed at the end of the sprint. It will build quality and prevent the mad rush at the end when you discover issues too late.
The star performers will worry about all of the focus being on the team.
Your old school team members are going to wonder wise on the little documentation is produced and what will happen if there is a system failure.
Customers are going to wonder why they have to spend so much time explaining requirements, discussing approaches, watching them, and giving feedback.
It can be a huge shift in culture for teams as they move to SCRUM and shift the whole team’s responsibility. So even if we want the comfort of having just one person to whole responsible, it’s not often that one person really is responsible for everything and it would be a fallacy to imagine that one person can make everything happen anyway. So, we need to call the way a culture of the whole team’s responsibility and there are many ways that we can shift focus from the individual to the team. For example,
We need to reduce the reliance on specialists.
Everybody should be able to perform a little bit of everything. Also, keep everybody busy by having them to a little bit of everything.
To give time to the testers, we should try and finish before the end date of the sprint.
The concept of team learning should be encouraged then share the knowledge across the team to create more generalists capable of handling everything.
Teams would develop and come together better when they are given a challenge which will motivate them without overwhelming them. So, the team to enjoy the challenge, we must also remove the fear of failure. The team should be open to ideas and when we do accomplish this is to build the team in such a way that there is diversity. The team must allow establishing its own sustainable pace which includes providing time for reflection, introspection, and innovation.
-
63Self-Organization
Self-organization plays a critical role in the success of a team scrum adoption. But it’s very hard to get it right.
There are several ways in which management can ensure influence the team. However, the reason it has to be several is that the team must be encouraged to make these decisions on its own. We can look at three ways in which these several influences can be exercised by encouraging self-organization.
The first structure is the idea of a container. The team is given basic boundaries within which they will self-organized. It is swotted like traffic rules and signs in which every motor is voluntarily followed without the necessity of a traffic cope/policing them all of the time. Where there is a situation that once a changed the container like changing the traffic signs of a busy junction or dealing with persistence violators, management may need to step in. In a team setting, one way is to deal with team composition issues.
If the team is lacking a certain skillset, assist the team and identifying somebody who will bring that knowledge to the team. If they are dealing with a troublesome or non-performing team member, assist them in managing that situation.
The second mechanism is to amplify or damping differences. Some teams are too homogenous and therefore things can turn in conformity. Whatever differences are there in the team must be addressed and come to all teams on the same page.
Thirdly is managing exchanges – Exchanges could be within the members of the organization outside the team. Say talking to the user experience designers or the architecture forum or the agile expert. These exchanges may need to be facilitated to steer the team in the right direction.
Whenever there are people, there are going to be policies. The agile concepts of self-organizing and putting the team before oneself are fundamentally different and require the organization itself to think differently in terms of the way in which it deals with the people issues.
-
64Organizational Factors – Human Resources
Therefore, during the scrum transition, the human resource department is important.
The first sign of change is the likely hood of new titles. While it’s possible that the current project manager becomes the Scrum Master and the current analyst becomes the Product Manager. It strongly advises having titles also change to reflect the role that is been played because it is so fundamentally different. For example, the scrum master should ideally not have the reporting authority over the team. The team must absolutely not report to the product owner because there is expected to be some natural tension between the team and the product owner. The product owner should expect more from the team and the team should expect the product owner to clarify more. This change in roles and structure needs to be explained properly and thoroughly.
The next challenge will come with respect to the performance evaluation process. Up to this point, the organization might have been recognizing individual evaluations. Now, the emphasis is going to be more on team work-related factors. This should be reflected in job description and scorecards of the team members who are not expected to do their work but are expected to pull their weight. Assisting others and completing their work should be valid a lot more in the evaluation process.
Another change that needs to be made to be an evaluation process is increasing the frequency of reviews including input from the broader range of stack holders and not just the line manager. For example, the product owner might say how well the team member is able to demonstrate a feature. A Scrum Master or colleague may provide inside about how much team members assist others.
-
65Career Path for Scrum Master
The whole process for defining the path also needs to be Scrum friendly.
For example, what’s the career path for a Scrum Master?
It could be to become the scrum master for different teams with more challenging projects, join a Scrum Master center for excellence, or something similar. For talented individuals, nothing is more motivating than the opportunity to do challenging work. Another thing to remember though is that the authority to remove a team member can not be given to the team even though it is self-organizing.
Because of all of these differences in a way of working, the HR people are going to need some Scrum training. This will ensure that they are aware of what is changing and why it is changing.
-
66Facilities
The facility is used by a Scrum team may need to be revamped in order to encourage open communication and collaboration. In his book, Agile software development a collaborative game Alister Cockburn provides some excellent advice on how to create good Agile team space. It’s a good idea to create a board room typesetting. This might initially trigger some resistance when you expect team members to give up their private space.
The team space must accommodate information radiators like the product and sprint backlogs, burn-down charts, other feedback devices like LED Screens with useful information. It also helps to have some food and drink available like a minibar and coffee machine. Space should be clean, hygienic, and foster open communication. Some of these changes will be far-reaching and require a considerable expense. It’s also likely that these changes will have to be sold to the team. therefore, as we said before these changes need to have a committed sponsor from senior management.
-
67Project Management Office OR PMO
An organization’s PMO or project management office can be a powerful source of support if it’s involved or be the source of significant resistance if it’s not. Potential roles for the PMO in an agile transition could include:
Developing training plans
Providing coaching
Assist with reporting or compliance
Be a gatekeeper for projects
Provide and maintain tools
Assist in collecting data
Identify and reduce waste
-
68Points Covered In This Section
Let’s summarize the points covered in this section
Transitioning to Agile is a project itself; and Ideally, it should be treated as an agile project and executed iteratively.
The success of an agile transition may hint at identifying an influential sponsor and creating an Enterprise Transition Committee
Make choices carefully regarding small pilots vs. all-in; visible vs. stealth; split and seed vs. grow and split; and technical practices early vs. stage technical practices
It’s important to set and manage expectations as well as anticipate and plan for overcoming resistance.
Get the HR department on board with different roles and evaluation models
Make sure the design of an Agile workspace is conducive to communication and collaboration and
Get the project management office involved early.