Introducing Scrum to Your Team

Scrum requires an introduction before it can be useful for any team.  You want to bring forth Agile and the Scrum methodically, specifically, in a way where the team can consume it, learn it, and then begin to make it their own.  According to the Project Management Institute’s Organization Agility Conference 2018, 73% of companies doing software development work use Agile and traditional approaches. 

77% of these companies have no clear rules as to which project should use Agile and which should not.  They choose the methodology based on the buzz around Agile and Scrum.  When introducing Scrum, you need an approach you are confident in.

Assess the Current State

Before you introduce Scrum, you need to assess the current state.  Teams that worked well in the past in Waterfall does not mean they will succeed as an Agile team or squad.  A starting point or baseline discovery must occur.  A simple assessment is to see where teams are at with their maturity of Scrum knowledge, of how they behave with one another, etc.  Make the baseline visible so that the team buys in.  Use the Agile Manifesto, the 12 Principles of Agile as the foundation, and Agile Mindset Assessment.

Introducing Scrum for the First Time

You have a team or organization who has never used Scrum and introducing it can be hard.  Initially, understand why they want to adopt Scrum in the first place.  What is the reason to adopt Scrum?

When Scrum is adopted first, you want to start small.  You do not want to take on anything huge, that incorporates multiple organizational units, teams, etc.  Start small with a project that is manageable, tangible.  Go with something quite visible to gain the most traction.

Teams need to set expectations in that Scrum is very easy to explain, but difficult to do in practice.  When you start with a smaller project, you can show the benefits quickly.  There will be problems, and that is ok!

Be mindful that the team may initially push for longer sprints (e.g. 4 weeks). This can potentially lead to the team practicing mini-waterfalls within each sprint. Resist the urge to go 4 weeks long with the intention of bringing it down to 2 weeks later - that won’t happen! The team may complain that there’s not much they can get done in 2 weeks. Check out the Ultimate guide to the Sprint Backlog.

Slice the functionality thinly but deeply - viz. not horizontally but vertically along the technology stack. Scrum will reveal issues that exist, and it requires people to think differently.  Let the teams explore Scrum and figure out how to solve their problems, as they arise.

Taking It Larger Scale

Some organizations will want to take it larger scale.  Larger projects will give organizations more value, more bang for their buck.  When you go into a big project with Scrum, you have a lot of teams and individuals used to the traditional Waterfall environment.

Before you take it large scale, though, you need to highlight Scrum as a process.  In the process of Scrum, stakeholders are getting involved throughout the process, rather than just at the end.  Once you have stakeholders and team members that have those eureka moments with Scrum, it is then you can begin to take it larger scale in its implementation.

Common Push-Back on Scrum

The way people work causes individuals to push back.  Scrum requires everyone to work together, collaboratively.  You need individuals to trust one another as a team.  The push-back, most commonly, is individuals saying they are the expert in their role and need to sign-off before things go forward.  With Scrum, it does not work that way.

Strictly speaking, Scrum does not have roles.  Developers and testers may be interchangeable, with a basis of the workload and the available capacity of those team members.  You will have testers saying they do not develop, and developers saying they do not test.  In Scrum, roles go away as the whole team is responsible.  Teams that lack emotional intelligence, and the real sense of the team, will struggle.

The other push-back is that individuals speak the terms of Scrum, but do not execute with Scrum as a process.  Agile Coaches have the role of changing the culture, breaking down the roles, and driving forward the Scrum events and keeping the context of that on-point.

Adopt the Guidelines, the Process

Scrum does not have a step-by-step approach.  Scrum has guidelines and lays out a high-level process, but it is up to the teams to adopt everything in a way which will work best for them.  An Agile Coach that comes in will need to figure out the coherence level of the team and also which flavor of Scrum, how best to adopt it, to be successful.  You do not want to bring Scrum to an organization with a hard-handed approach.

Have the whole team figure out the working agreement and write it down.  In Scrum, teams need to come up with it, so they have ownership and also know how they want to work.

Adopting Scrum within an organization is possible, but it requires buy-in.  Scrum may not even be the right Agile methodology.  There exists Kanban, ScrumBan, XP, and many others.  If the vehicle doesn't meet the needs, change it and adopt what works for you!