Have you heard about Scrum, but…? This means "we do scrum, but…" we don’t do retrospectives, don’t do daily standups, etc. Well, there’s a deep wisdom behind all the Scrum practices we give up. Be aware of the risks you create and know how to counteract them. This is a first post in a series that aims to show how you can keep the benefits of Scrum in real life.

It’s not always practical to implement Scrum in full. We’ve all been there. We may be in a hurry and rush the planning session. Or there’s only part-time, inexperienced Scrum Master. Or our client keeps changing the scope of our sprints. That’s often the reality. But remember one thing. With every aspect of Scrum you don’t do, there’s benefits you loose. Up to the point of failing the project.

Note: In this article series I strive not to use Scrum jargon as the lessons from it can be applied far beyond Agile projects.

Be sure to subscribe (RSS) or check back in a week for the next one.

Scrum Is Funky & Feels Like Extra Effort

Scrum seems to require a lot from us. It comes with funky vocabulary: sprints, planning poker, retrospectives, Scrum Masters, etc. But it’s worth it. I worked on projects that implemented it correctly and magic happened! If you’ve participated in a well-led, agile project then you know what I mean. But there’s a caveat to this productivity nirvana: it only works if go all-in on Scrum OR your team really, really, REALLY knows what they’re doing.

Why there's such a tremendous value behind Scrum? Because it takes into account communication issues. It was invented to handle the mess at the intersection of software projects and reality. Finally it accounts for the human psychology. It provides tools & feedback loops to counteract the negative effects of all these. When you divert from Scrum, you're on your own in dealing with all those aspects!

Lack of Retrospectives

In my experience, this is the single most important part of the Scrum process. That’s when the team sits down to discuss what went well and what wasn’t working during the last sprint (recent period of work). It's key to improving the way teams work. Here's an exaggerated (or is it? 🤔) reason why it's so important:

Benefits of retrospectives

1. Identify problems. Often times minor problems may yield a big impact on the team’s productivity. Taking the time to discuss them creates opportunity to identify the most important obstacles. You get a prioritized list of problems that need solving. This is your map.
2. Improve productivity. Having identified the problems allows you to tap into the knowledge of the team for solutions. It makes external dependencies explicit which allows you to act on them. It makes improvement a constant and manageable thing.
3. Boost engagement. Thanks to retrospectives the team has a place and time where they can voice their concerns. They have a forum to raise problems and seek help. Proper follow-up with improvements builds up the sense of control and influence among the team members.
4. Contribution. There’s many ways to conduct a retrospective meeting. Some of them are designed in a way which allows even the most shy of the team members to be heard. There's tactics to quiet most outspoken people a bit.
5. Appreciation. Our work is an endless fight with problems. That’s reality. Otherwise we wouldn't have jobs 😉. Yet it’s sometimes hard to stop and take notice of all the things that are going well. That's our psychology that filters out all that's OK and brings only problems to our awareness. If you don't appreciate what works the situation can spin up into negativity in the team. Bringing a spotlight to things that work fine is important for a balanced perspective!

Risks Of Not Doing Retrospectives

• Team is being slowed down by problems.
• Frustration builds up and morale plummets.
• Quality suffers.
• Developers create weird workarounds and shortcuts that introduce non-obvious dependencies in the project.
• Avoidable bottlenecks slow down the team’s progress.
• People feel out of control of how they work.
• Negativity permeates the team.

Counteractions / Remedies

If you can’t do proper retrospectives you need to ensure there’s a way for the team to identify problems and improve. You can do it in different ways. You may have regular 1-1 meetings. You can still do retrospectives, but more rare. The team can appoint someone to look for bottlenecks and then to coordinate improvements. You can provide slack (unallocated) time the team can use to improve their way of working.

Summary

As you see making a simple list of what went good and bad can go a long way. Retrospective is when you uncover problems. This is how you remove frustrations of the team. This is when you tap into their knowledge and their perspective. This is how you improve performance. This is how your team grows.

Be sure to subscribe (RSS) or check back in a week for the next one.

PS. If you're interested why Scrum scrum works and why skipping its elements is so risky you may want to read about the PDCA (plan–do–check–act) cycle.