Building The Farm Team - Decision Making

To build leadership and decision making skills and to encourage the growth and participation of everyone we want to push every decision down. Not up. Further, we don’t want any decisions being made that are arbitrary and done in private, regardless of where you are at in the organization, and if fairly junior we don’t want you shouldering the burden on your own, and possibly the company suffering the consequences of your inexperience. For all of these reasons every decision maker should:

• Ask themselves if there is someone on their team that could learn from making this decision more so than they will, and if so, they pass the decision to them,
• and regardless of who is deciding, the decision maker must seek advice from whom they deem to have more experience on the subject before they make their decision. No advice. No decision is made. This applies to everyone. No one should ever be surprised that a decision was singularly made with no advice.

The company stands behind the decision maker, no second guessing, until the outcome of the decision is proven wrong, if ever. And of course decisions won’t be right all of the time. Which is fine. We can learn and adjust as we go. What isn’t fine are surprises - decisions made in private with no advice sought or given.

Extrapolated from from Bakkes Top 10.

How Do You Know You Have A Good Team?

The best test of a good team is to have one member go away for 2 or more weeks and nothing slows down and nobody needs to find them. And if that holiday goer does check in the team is annoyed and tells them to go away and enjoy their holidays. That's how you tell if you have a well run organization.

Greetings from Australia!

A Simple Spreadsheet for Tracking Scrum Team Performance

Here’s a spreadsheet that we use to track Scrum Team Velocity, Happiness Scores and Epic Costs, Estimated Completion Dates and Found Points Averages.

https://docs.google.com/spreadsheets/d/1V2j2XtHOgjYNMpitis2fxoXNsNqmNigtsGdmv6ubKy4/edit?usp=sharing 

Login with a Google Account and make a copy of the spreadsheet and have at it. If you have ideas for improvement I’d love to hear them.  

Keep in mind that there is no buffer calculation as I don’t believe buffer makes sense when sprint teams are running with continuous deployment. Which everyone should be. Right? !

Avoidance versus Blocked

If you have to get this done and you're not doing it because someone or something has acted in a way that is stopping you, are you sure you weren't looking for that excuse in the first place? Stop because you are truly blocked, not because something conveniently blocked you from doing what you didn't want to do.

Taking The Time To Reflect and Improve, But Not Wander - Retrospection

At the end of every sprint the team retrospects on what happened. This isn’t a wandering conversation to chat about how everyone is doing over a long lunch. A focussed and well tuned team can wrap this meeting up while comfortably standing. About three minutes per team member. If there are four members the discussion can be closed in 12 minutes if the team is working well.

Like all good meetings the team does their homework BEFORE THE MEETING and posts their conclusions before retrospection starts. They don’t make it up when they arrive. This is important, they give it the time it deserves, in advance and the homework includes;

• How happy are you? Out of 5, with 5 being the best, how happy are you with your role within the team, your performance and the support and resources you have to perform your role? And out of 5 again, how happy are you with the company? Do you think it is doing the right thing? Going in the right direction? Sum the two together and you have the happiness score.
• And then, what would need to be improved to make you happier? Or, if you are really happy with how things are going what do you think we need to improve to make the team go faster? At least one improvement, but no more than three. And once again, this isn’t done on the fly, this is carefully thought through and posted prior to the meeting starting. Continuous improvement is the most important thing we can do.

The team meets. Each member speaks to their points and takes questions. The scrum master sums the points shipped and the happiness scores and determines if both have improved, stayed the same, or declined. Based upon the past performance the points capacity for the next sprint is set and the remaining points to ship the epic, if one is running, are totalled and the revised expected completion date and total points to ship the epic are tallied. If the date is slipping and found points are accumulating the Scrum Master makes it clear we are going to miss our target.

Happiness is a precursor of velocity, if it is down, then velocity will follow. Tackle why the team is less happy first and get consensus as to how it can be improved.

If this isn’t the case, focus on how to improve velocity. What improvement can the team make to increase velocity?

And then finally, what controls or scope reductions should be put in place to correct slipping dates and found point increases?

Add the improvement to the sprint backlog on the board and give it points. Then move cards from the backlog up to the sum of the capacity for the sprint, no more, to the sprint backlog, and do one last check to see if anything is missing.

Summarize the conclusions. How are we performing? Happiness, velocity and holding to estimated ship dates. How will we improve? And what’s the target for this sprint. It’s a wrap and the new sprint begins.