Scrum Dynamics 24 - Scrum Role Antipatterns

How to deal with an over-driving product owner

How to deal with an over-driving product owner

In Scrum Dynamics episode 24, Neil covers his top 10 antipatterns for Scrum roles in Dynamics 365 projects. 

An antipattern looks like a good idea to a situation you were facing but wasn’t the best option when you look back on it. Antipatterns are traps that we want to help others avoid. 

Here are Neil’s top ten antipatterns for Scrum roles: 

  1. Uncommitted product owner. If your senior project stakeholder is too senior, they usually won’t have the availability required to be a committed product owner. Find someone in the next level of the organisation and backfill their job so they can be a full-time product owner for your Dynamics 365 project. 

  2. Committee of product owners. This antipattern often occurs when we’re implementing Microsoft Business Applications across several divisions. Don’t settle for a committee of product owners from the different divisions. Find one single product owner they can all trust. Otherwise you’ll get pulled in lots of directions. 

  3. Overdriving product owner. Often product owners with a background in sales leadership use motivation techniques, such as setting stretch targets, that often don’t work with developers. Use their enthusiasm, vision and communications skills, but watch out for them becoming a backlog troll. 

  4. Learn-as-you-go product owner. Most product owners in a Dynamics 365 project have never been a product owner before might never have worked on a project before. For the sake of your team, your users and your organisation you deserve product owner training, to read widely about product ownership and to work closely with your scrum master for coaching on the product owner responsibilities. 

  5. Part-time scrum master. World-class sports teams don’t expect one of the players to coach the team. Great scrum masters might be able to coach two, possibly even three teams, but it’s a full-time role that shouldn’t be handed to one of your developers. 

  6. Combined product owner and scrum master. The goals of the product owner and scrum master can occasional come into conflict. If the product owner wants to push the team hard to meet a release deadline but the scrum master wants to preserve a sustainable pace. Keep the roles separate to balance that natural tension and avoid a conflict of interest. 

  7. Scrum monster. Every scrum master is familiar with the rules in the Scrum guide. And they’re familiar with agile software development technical practices. Great scrum masters know when to bend the rules, and how to make the most of situations when your team can’t follow the rules. 

  8. Rookie scrum master. It can be hard for a lot of project managers to transition into the scrum master role. It requires a mindset sift into an agile way of thinking, and Neil recommends that project managers spend a year working in a scrum team before trying to coach the team as a scrum master. 

  9. Sharing developers between projects. Sharing a developer between projects can appear to maximise their productivity, but it can drag down the throughput of the teams relying on that developer. If you can’t dedicate a developer to your Dynamics 365 project, then make mutually agreed commitments about when they will be available so that you can determine your capacity for sprint planning. 

  10. Learn to code. This one is for Stephan Smith who wrote a contentious article on LinkedIn, “Three forbidden words: I don’t code”. Everyone in the scrum team should be prepared to help the team do whatever it takes to meet the sprint goal every sprint. Sometimes it’s a task within your specialty, sometimes it’s something new. But there’s an antipattern that hopes that an amateur programmer to develop mission critical code. Be adaptable. Expand your skills. But software development is an engineering discipline and not everyone should be copy/pasting scripts from Stackoverflow into your Microsoft business application.