Object Oriented Analysis & Design with UML

Explore

Gallery

Object Oriented Analysis & Design with UML

Learn Agile & Scrum

15-Get Started With Scrum in Your Organization

Get Started With Scrum in Your Organization

⁠

Loading…

⁠

In this chapter, we will discuss how a tech team can approach the process of becoming agile through adapting a Scrum Framework for their project management approach.

Understanding Context

Before introducing any change into a team or organization, it is crucial to take stock of the current context. For example, if the tech team is high-performing and management is particularly happy with their output, then you have to ask yourself, "Why attempt a major organizational change?"

The idea of introducing an agile process usually happens because certain team members or management see an opportunity to improve upon existing quality, output, and procedures. However, they could also be frustrated with their current situation because progress and output are below expectations.

It is vital to note any pain points, goals, and desired outcomes the team and management have before implementing a change process in the organization. This establishes the reasoning behind the desire to change. It will be helpful moving forward, particularly if adopting a new process brings challenges. You can remind everyone involved why it is worth this effort.

Pain points can take many different forms. The website

pointsandfigures.com⁠

provides an excellent insight into the definition of pain points. Essentially it defines a pain point as: A problem, real or perceived.

⁠

Change is usually motivated because it is necessary

Top Down and Bottom Up Change Processes

It is worth noting that change can be promoted/suggested in two ways:

Top down - where management teams believe in the value of change and push employees to adopt new processes that management think will be more effective.

Bottom up - where the employees or team members doing the work want to improve their own processes and persuade management of the value in making changes.

When introducing agile frameworks like Scrum into the organization for the first time, a combination of top-down and bottom-up influencing is required. It won't be effective if management or the tech team don't buy into the change.

Deciding Where to Start

Several factors make successful Scrum adoption more likely. You should look to see which teams and projects in the organization can match some of these criteria:

Employees who have already worked in Scrum will be excellent members of the first teams. They can help team members who are new to the practice.

Tech leads often make good Scrum Masters. They must be open-minded, eager to learn, and attend the relevant training.

Failing projects can be a good place to try something new that breaks progress into smaller, measurable units.

Projects where the team is already motivated to try Scrum (bottom-up buy-in is already achieved) and where management is at least willing to entertain the idea of change (top-down buy-in seems possible) will make adoption more likely.

Introduce Scrum to one team first, and then other teams can also adopt it when the first team enjoys some early success.

Achieving Buy-In With Common Language

When introducing Scrum, some team and management members will likely not be familiar with it. Therefore, you need to explain what it is, and then people can make up their minds. How you present Scrum will be critical to how open they are to adopting it (or learning more).

Akamai is a company that specializes in customer identities. The Akamai team suggests using a common language when explaining Scrum and then relating that to Scrum terminology. For example, you explain to a stakeholder that you would like to spend one hour every two weeks showing them a demo of all the team's work. Most likely, the stakeholder will think this is a good idea. You can later refer to this as a "Sprint demo" or a "Sprint Review."

Here are some other common language descriptions for Scrum terminology:

Product Backlog: A single list of all work for the product. This list is ordered and maintained by the Product Owner.

Daily Scrum: A daily 15-minute meeting where Developers share progress and call out if there are any blockers or impediments to meeting the Sprint Goal. They adapt their Sprint Backlog as necessary.

Sprint: A timebox of development that is less than a calendar month. Two-week Sprints are common in the industry.

Sprint Retrospective: A meeting at the end of a Sprint to assess how the team is doing and if any improvement is needed.

User stories: A type of Product Backlog Item that describes how a user or persona will use the product and what they need/desire.

Product Owner: The person accountable for ordering the Product Backlog.

Scrum Master: The person who ensures the process is working and that the team is improving. It's also the person you can ask if you have any questions about all of this.

Stakeholders are usually happy to try Scrum when they find out that they will get a valuable Increment they can release every Sprint. They will also get a Daily Scrum, a Sprint Review every Sprint, and an ordered list of items they can discuss and understand with the Product Owner!

⁠

Using common, everyday language is a great way to achieve buy-in

Educate the Organization

The wider organization (people who don't work in or manage teach teams) will also be curious about using Scrum.

Organize information sessions where employees can get a quick and easy-to-understand introduction to how Scrum works. They can be told of any upcoming events and ask questions about how the change will affect them. This is especially good for those who want to stay up-to-date with product improvements and make feature requests.

Kotter's Change Process

Harvard Business School professor, John Kotter, suggested an 8-step process for effective organizational change management. These can be helpful steps for you to consider when introducing agile processes into the organization.

Establish a sense of urgency - Identify why change is important, what frustrations the team wants to remove, and what opportunities lie ahead. Link the proposed change to these improvements.

Form a powerful coalition The tech team may listen to a senior engineer on the team more than they will listen to you. Getting that person on your side first, then having them explain the benefits, can be a very effective way of persuading a team. The same is true for upper management, where a key ally with a good reputation can get support for change on a managerial level.

Create a vision - A vision is a short, compelling, desirable, and achievable statement of some future state that will inspire people.

Communicating the vision Talk to people about this vision and spend time explaining why it is desirable and what it will mean for them.

Empowering others to act on the vision - Encourage others to act by changing corporate structures, removing obstacles, and creating a culture of risk-taking.

Planning for and creating short-term wins - Change can take time. Along the way, there are smaller and easier ways to achieve victories that will show everyone that the new way is working. Management is also less likely to cancel your efforts if they see success. Team morale will also improve.

Consolidating improvements and producing still more change Use your increasing credibility (due to short-term wins) to change the organization's policies and systems to fit the vision better.

Institutionalizing new approaches - Embedding the change as part of the company's operational procedures.

Let’s Recap!

Adopting Scrum is a major change for most organizations. Understanding the organization's current context (pain points, opportunities) is vital to make the motivation for change clear.

Use common language when introducing Scrum to people who don't know it.

Aim for simultaneous top-down and bottom-up buy-in and education.

You are all set with this course on Agile Project Management and Scrum! Let's test what you've learned through the following quiz!

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.