Tag Archives: Scrum Master

The Five Things Every Scrum Master Should Do

05 Friday Oct 2018

Posted by in Management

≈ 2 Comments

Tags

, , ,

The larger a Scrum team is, the more opportunity for wastage there is, and so the more difference a good Scrum Master makes.

A team with a bad Scrum master can feel powerless, floundering, isolated, and overwhelmed whereas a team with a good Scrum Master generally feels well informed, connected, directed, powerful, and like they are working at peak effectiveness.

Be punctual

  • Set a regular cadence for the team.
  • The daily scrum is always at a predictable time so no time is wasted trying to organise it every day. The larger the team, the more important this is.
  • This of course also applies to the Review, Retrospective, and Planning meetings too.

Set a strict agenda

  • Tangent topics will come up regularly during meetings, and although sometimes these can be important discussions, they often take up a lot of time. Make sure that there’s never a time when 2 or 3 people are talking and everyone else is phasing out. If it’s on topic for a Scrum meeting, everyone should be involved, otherwise it should be taken offline (after the meeting with just the relevant people).
  • Make sure that someone takes a note of these topics as they can sometimes be forgotten otherwise.

Help your team

  • The people who know best how to make software are the people actually making it. If they raise an impediment, take it seriously and work towards a solution.
  • Help to motivate the team by showing appreciation for quality work. Doing this publicly often helps motivate other team members to strive towards the same level.
  • Encourage collaboration amongst team members. If one person is stuck, help them to realise that it’s always ok to ask for help.
  • Protect the team from excessive scope change. Adding a last minute Product Backlog Item (PBI) to a sprint should only be allowed if the team can drop an equivalently sized one.
  • Minimise WIP (work in progress) by encouraging the team to finish each PBI before picking up another whenever possible. This helps to minimise multitasking and ensure granular delivery of value to the stakeholders.

Help your Product Owner (PO)

  • A good Scrum Master should help the PO effectively communicate his requirements and priorities with the team. He should then reinforce those priorities and encourage the team to work in priority order whenever possible.
  • It’s a good idea to have high level conversations with the PO on occasion to work out what their more abstract goals are so you can help by making micro decisions for the team when appropriate. This way you can occasionally act as a Proxy-Product Owner when needed.

Coach your team

  • Make sure the team follows the Definition of Done.
  • Make sure the Product Owner creates well fleshed out PBIs with easy to understand Acceptance Criteria.
  • Ensure that the team has a uniform understanding of the estimation method being used (we use 2-Small, 4-Medium, 8-Large, where a Medium is about a day’s work)

The difference a good Scrum Master makes is well documented, and if you follow the above guidelines, you should be well on your way to empowering your team.

Along with my brother, I made a video on this topic which explains how the Scrum Guide defines the role of Scrum Master:

I’ve written many more specific tips on SSW’s Rules to Better Scrum

The Sunk Cost Fallacy

07 Friday Apr 2017

Posted by in Management

≈ Leave a comment

Tags

, , , , , , , , , ,

The sunk cost fallacy is in action every time you:

  • Sit through a long boring movie even if you decided after the first half an hour that is was terrible
  • Finish a meal that tastes bad and after you’re already full
  • Continue a bad relationship or friendship, purely because of the time and energy you’ve invested in it so far

Put simply, it’s the motivation to continue on a bad course of action, where logically the future does not look bright, only because of the time/money/energy you’ve put into it up to that point.

These already spent costs, that cannot be recovered, are known as “sunk costs”, and there is a strong human resistance to giving them up. It feels like admitting failure. But being able to be agile and “pivot” when needed is the mark of an intelligent business, and the sunk cost fallacy is generally the main thing in the way of that.

A pivot is when, part way through developing a product or service, you decide to take it in a different direction than the current planned path. This might mean changing the main focus of the offering, or even making it do something completely different to the original plan, and should be informed by early feedback as much as possible.

The problem with the sunk cost fallacy is that you end up investing much more than necessary in to whatever you’ve sunk the costs into, leaving you with fewer resources to go down productive paths. For example, if you’re stuck in a bad relationship, you can’t open yourself up to a future good relationship. And if you’re constantly paying for ongoing product development on a dead product, you can’t be working on a useful product instead.

All you’re doing in this case is throwing good money after bad… but there’s a silver lining. What you’ve paid for up to this point isn’t all wasted. The validated learnings you have gained will stop you from repeating the same mistakes. You have tested the market, an idea, or a product line, and you’re better positioned for your next endeavour.