5 Silent Killers Of Agility (Using Scrum) You Cannot Ignore

We all know that ‘agile’ is the buzz in IT and has been for at least 10 years now. The draw is the iterative delivery and the ability to adapt to change. Iterative delivery means that work can be delivered in small functional chunks sooner vs. One big giant release after months or years. Unfortunately calling yourself agile and even adopting some of the principles are not enough.  
Below I highlight some of the silent killers to agility.

  1. Ceremonies Lack Value – In scrum the following ceremonies exist:

• Daily Stand-up – A 5 to 15-minute meeting, intended to be conducted standing up (to ensure the time box) where the team members answer 3 questions: What did I do yesterday? What am I doing today? Do I have any roadblocks? This meeting is intended to be highly informative.
• Backlog Grooming – A weekly meeting where the team reviews the backlog and ensures stories have the proper level of detail (as determined by the team) and have a story point value.
• Sprint Planning – A meeting that kicks off each sprint (project cycle) where the Product Owner presents the work suggested for the sprint. The team reviews discuss and agrees on a body of work commitment.
• Retrospectives – In traditional projects, this is called a ‘post-mortem.’ In the scrum, this is done more frequently to ensure that the team quickly adjusts to repeat positive behaviors and discontinues negative behaviors.
• Demonstrations – A meeting that wraps each sprint where a team member presents the work completed to the necessary stakeholders

The problem arises when one or many of these ceremonies are seen by the team as unnecessary. I am not prescribing a strict adherence to these ceremonies, but if you deem a ceremony to be part of your process, there’s a reason. If the team doesn’t understand that reason, you need to constantly reiterate the value to your team.

2. Changing resources – A common characteristic of Agile teams is that they are stable. This means that the team is staffed with stability in mind. When the team stays together, unchanged, they learn how to best work together and they grow with each other. Every time a new member is added the team has to be partially focused with onboarding new team members and it messes with the team chemistry. Additionally, the team’s velocity will need to be re-established based on the changing resources.

Solution: When possible, insulate your existing team(s) from change. If needed, spin-up completely new teams, so as to avoid impacting the existing teams.

3. Scrum Master to Team Ratio – The Scrum Master is the public servant for the team. Their role is to coach, mentor, remove roadblocks and protect the team. With that role and those responsibilities in mind, it’s easy to see that the Scrum Master has to be intimately involved with the team to be able to perform their function and serve the team. When a Scrum Master is spread across too many teams their effectiveness is heavily diluted. Best case is to have each Scrum Master with only 1 team. I’ve seen and functioned in environments that capped the Scrum Master to 3 teams or less. That’s a little more of a stretch, but with staggering ceremonies and sprints, it’s possible.  When the Scrum Master has greater than 3 teams I’ve personally experienced (as well as observed) a decline in the ability to serve the team.

Solution: Invest in more Scrum Masters. Bring on new resources or promote from within, just get that Scrum Master to team ratio down.

4. The Personality of the Scrum Master – It’s very common in many organizations to convert traditional project managers to the role of Scrum Master. That can work, but it can also be problematic. The Scrum Master needs to be the right personality. A traditional Project Manager is constantly pushing the team to meet deliverable timelines within budget. A Scrum Master, while still invested in the team’s deliverables, is more interested in helping the team and the team members become successful. The Scrum Master’s role and personality are very different from a Project Manager.  As mentioned in the previous point, the Scrum Master is a coach and mentor. That takes a special personality. Also, the Scrum Master needs to be fluent in ‘Agile’ practices and practical applications.

Solution: Avoid the simple decision of converting Project Managers to Scrum Masters. Instead, interview for people with the right personalities and skills. Ask servant leader-centric questions when interviewing for a Scrum Master. 

Discover your full project management potential with PRINCE2 Foundation Training Online. Gain the skills to confidently lead successful projects.

5. Time Off and Holidays – On my very first ‘scrum’ team we would spend a portion of our sprint planning to evaluate the calendar of the sprint. Each team member would look at their true calendars for the sprint and provide a daily capacity. That ‘true capacity’ could then be evaluated when choosing what stories and how many to bring into the sprint. Just know, it would be a disappointment for the team to fail a sprint simply because they didn’t take into account holidays or personal time off (most of which is known).

Solution: Create a calendar at the beginning of each sprint and have your team provide their ‘real’ daily capacity. Publish that calendar for the entire team to see. The exercise alone gets people thinking about deliverable commitments, but publishing the calendar is a constant reminder.

These silent killers in agile implementation can be silently sabotaging your teams, enterprise, or company’s implementation of agile. Also, you might see a completely different set of silent killers. It’s up to you to determine your non-negotiable practices and then work to mitigate those killers.