Why Your Team is Not Agile

Maybe Your Team is not Agile because They Don’t Know How to Be Agile

Many Scrum Masters feel frustrated when their team is not agile enough or they don’t practice scrum the “right way.” Probably every Scrum Master feels this way at some time in their career.

So, why is this happening?

We could list an infinite number of reasons for this, but if you look past the symptoms, we can group the team’s lack of commitment or poor performance to 3 root causes: 1) Inadequate training, 2) No consequences and 3) We forget that we are servant leaders.

Inadequate Training

Maybe the team doesn’t know how to be agile.

It never ceases to amaze me how many companies transition to agile without training everyone involved: management, the engineering staff and (oh yes) the business team members too. Agile methods are more than ceremony. To be agile, you must change the way you think. To truly transition, everyone involved must understand not only how to practice, but also the theory behind why the practice works.

Companies that train their staff may only train the Scrum Masters and maybe the engineering staff. I’ve never understood why management feels exempt from training too. If their entire staff is transitioning to a new approach to application development, won’t their approach to managing their staff need to change too? How can anyone manage and support what they do not truly understand?

One of the major benefits of scrum is Product Owner membership on the team. This precious customer representative influences timing and impacts quality. Their vision has direct impact on customer satisfaction. If the Product Owner is an integral part of the team’s ability to deliver, then why is it that the Product Owner rarely receives training before joining the team? How can we expect someone to write stories when they do not understand the concept and they haven’t been trained how to plan or how to write story requirements and acceptance criteria?

If your team does not know how to be agile, as the Scrum Master, remove this blocker by requesting training for those who need it.

No Consequences

What happens when the team misses their commitment?

Many scrum teams operate without a team contract. Agile is about self-managing teams. Self-management is an awesome responsibility. As the first step, the team needs to define how they want to work together. If the team skips this step, then there is no commitment to practice scrum and it’s no surprise that anarchy ensues.

The team contract should acknowledge mandatory attendance at ceremonies like Daily Standup, Story Grooming, Sprint Planning and Retrospective. The contract should also include expectations when a team member cannot attend. The team contract should be prominently displayed on wiki or SharePoint pages. Consistent disregard for aspects of the contract should be escalated to management by the Scrum Master in the same manner as any blocker to team success. For more information about team contracts, check out Chapter 1 of the GSD Scrum Handbook.

Many teams cannot seem to time box their sprints or meet their story commitments. This common problem has roots in many different aspects of practice. As Scrum Master, do not let these problems languish. Discuss them at Retrospective. Let the team identify the root cause and then let them decide how to change their behavior. At the beginning of every Retrospective, review practice changes from prior Retrospectives to see if the team has actually changed. Holding the team accountable for walking their talk is an important aspect that is often overlooked.

We Forget that We are Servant Leaders

Servant leaders are not task masters.

In the age of agile, many project managers have transitioned to Scrum Masters. In our past waterfall world, the project manager works with the team to create a work breakdown structure and then creates a plan with tasks that must be completed to complete the project.

In scrum, the Scrum Master must know scrum, but the Product Owner decides what the team works on and when the work is complete. The Development Team decides what they can commit to. Everyone decides how they want to work together. Then, the Scrum Master clears the path and removes roadblocks.

For many Scrum Masters, it’s hard to give up control. When your team is not agile enough, first look inward. Are you part of the problem? Scrum Theory prescribes 4 events: Sprint Planning, Daily Scrum (Standup), Sprint Review (and Demos) and Sprint Retrospective. If your team practices these events, they practice scrum.

Coach your team and arm them with knowledge about best practices, yet give them freedom to practice scrum in the way that works for them. If it’s not working, review at Retrospective and let them decide how to change.

Providing team training, allowing the team to define their own rules and consequences, and ensuring the team has freedom to practice within the boundaries of scrum are the recipe for self-managing teams that are most likely to meet their commitments.

Do you have any experiences that you’d like to share?

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru 503.799.5500