Mastering The Complete Agile Scrum Master Workshop | Free Udemy 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

• 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.

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.

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:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. 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:

1. Highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

• 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,

1. Higher productivity and lower development costs – this is accomplished by reducing waste and irregularities by only developing what is absolutely essential for the customer.

2. 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.

3. Higher quality software – using techniques like test-driven development, continuous integration, acceptance test-driven development, and refactoring can lead to nearly defect-free software.

4. 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.

5. 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.

• 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

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:

1. Scrum

2. Extreme Programming

3. Crystal

4. Kanban

5. Lean

6. Feature-Driven Development

7. Dynamic System Development Methodology (DSDM)

All of these methods Share Agile practices and values, like

1. Embracing change

2. Lightweight or lean documentation

3. Daily Stakeholder collaboration

4. Incremental Delivery and

5. Continuous improvement

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.

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

1. If testing is good, let’s do unit testing, integration testing, and acceptance testing

2. 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

3. If simplicity is good, let’s eliminate anything that does not add value and make sure we always do the simplest thing.

4. If the review is good, let’s continuously improve by making sure we do reviews and retrospectives at the end of each iteration.

5. If communication is good, let’s make sure our team space and tools encourage face to face osmotic communication.

6. 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:

1. 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

2. 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.

3. 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

This section will have detailed information about the following:

1. Scrum Pillars and Values

2. Scrum Lifecycle

3. Scrum Ceremonies

4. Definition of "Done"

After completing this section, you will be

1. Come up with the transition plan for moving an organization to Agile

2. Identify the important milestones in the plan

3. Identify symptoms of resistance to change and be prepared to overcome them

4. Articulate the principles of self-organization and cross-functionality

5. Explain the physical and cultural changes needed in the ecosystem in order to enable Agile.

Using the ADAPT, there will be five attributes required for successful scrum adoption.

1. Awareness – the awareness that the current process OR approach is not working. The first step is realizing that change is necessary.

2. 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.

3. 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.

4. 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.

5. Transfer – last but not least is transferring and spreading the advantages of scrum throughout the company.

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

1. Financial

2. Customer

3. Process

4. Innovation

5. 
   

Mike Cohn suggests we can benefit by using the balanced scorecard concepts for SCRUM teams, by these four categories

1. Operational Excellence

2. User Orientation

3. Business Value and

4. Future Orientation

We can define specific measures for each category

Operational Excellence

For example, as a part of operational excellence

1. We can define predictability metrics, such as did the project end at the desired Sprint, or did it require extra Sprints?

2. We can also define productivity measures such as functionality delivered per release or features developed per developer

3. 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

1. Measure the downtime experienced by users

2. We can also find measures for user satisfaction through surveys or net promoters scores

Business Value

For business value,

1. We can measure how frequently incremental value delivered to the customer

2. We can also measure the substance of releases in terms of user-visible features

Future Orientation

For future orientation

1. 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.

2. We can also measure the understanding and maturity of SCRUM with the key indicator being attendance and participation in scrum ceremonies.

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

1. Less risky and

2. That you pick the team that is most suitable for the transition.

3. 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

4. You can almost guarantee that the transition will be successful

5. This way you can defer the radical change and

6. 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

1. The transition will be quicker

2. The overall cost for the transformation will likely be lower

3. Seeing other’s experience, the same kind of issues will also let you learn from the other teams

4. The all-in approach will require more top-down buy-in support and

5. Having that always assist in making changes

Here are some other approaches conducting an agile transformation

1. The first one is to make a public display OR

2. 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

1. One is to split the first successful team and assign them to other teams to sow the seeds of Agile and

2. 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

1. The technical practices like pair programming or continuous integration. You can introduce them early to get significant success with early adoption or

2. You can introduce them in stages. The benefit of starting early with practices as you can almost instantly see the benefits

3. 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.

The process of transitioning to agile should be managed like a project itself iteratively and incrementally.

1. 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.

2. 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.

3. 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

1. 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.

2. 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.

3. The star performers will worry about all of the focus being on the team.

4. 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.

5. 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,

1. We need to reduce the reliance on specialists.

2. Everybody should be able to perform a little bit of everything. Also, keep everybody busy by having them to a little bit of everything.

3. To give time to the testers, we should try and finish before the end date of the sprint.

4. The concept of team learning should be encouraged then share the knowledge across the team to create more generalists capable of handling everything.

5. 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.

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.

1. 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.

   
   

2. 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.

   
   

3. 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.

Therefore, during the scrum transition, the human resource department is important.

1. 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.

   
   

2. 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.

   
   

3. 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.

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.

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.

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:

1. Developing training plans

2. Providing coaching

3. Assist with reporting or compliance

4. Be a gatekeeper for projects

5. Provide and maintain tools

6. Assist in collecting data

7. Identify and reduce waste

Let’s summarize the points covered in this section

1. Transitioning to Agile is a project itself; and Ideally, it should be treated as an agile project and executed iteratively.

2. The success of an agile transition may hint at identifying an influential sponsor and creating an Enterprise Transition Committee

3. 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

4. It’s important to set and manage expectations as well as anticipate and plan for overcoming resistance.

5. Get the HR department on board with different roles and evaluation models

6. Make sure the design of an Agile workspace is conducive to communication and collaboration and

7. Get the project management office involved early.