Scrum Master Tip – Team Consensus

In Scrum Master Tip – Many Voices I listed a few things to try if your team meetings are dominated by one person and you want to hear from the others in the team.

On a similar note, I’ve found the following tips useful to Team consensus on decisions.

Issue to Avoid

Failing to get buy-in from the whole team on important decisions.

Why is it a problem?

If someone doesn’t agree with a decision, they are unlikely to follow it. At worse, they will become unmotivated and disruptive and slowly drag the team around them down.

I try to save these alternative techniques for the important decisions and fall back on the simple consent check of “does everyone agree?…ok then, decision made” for day to day things.

Potential Solutions

With all of these solutions, there’s a risk that the more timid members of your team are copying the dominant person, so keep an eye out and if need be, split the group up.

Roman Voting

After 3, everyone gives a thumbs up or thumbs down. other.

Vote with your feet

Imagine there is a line along one wall where one end is agree and the other is disagree and ask the team to stand along the wall depending how strongly .

Consensus Check

Use planning poker cards where a higher number is more agreement.

Unit Testing – Check your Return on Investment

I once asked a team to question everything we do. We ended up with a few suggestions about things we could streamline but I was surprised at how quickly everyone on the team said “unit tests are good”.

Are unit tests good?

I’m strongly believe that unit tests are critical, but only if they offer a good return on investment. It takes a scary amount of time writing and maintaining a suite of unit tests, so any efficiency savings can really add up.

Why are you spending time and money writing and maintaining unit tests that are trivial?

Adam Tibi got me thinking about it a lot recently when I read his post on not testing MVC controllers.

When are unit tests “Bad”

I basically agree with Adam, but applied to every single line of code, not just controllers.

I’ve seen teams decide a certain % of code coverage is required and then just mechanically write test upon test until that magic number is hit. What’s the point of unit testing something like a simple wrapper that passes through to another layer. What have you achieved?

I find questioning the ROI of a unit test can also lead to some nice refactoring.

Summary

Question your return on investment of every unit test you write and maintain. Why are you spending time and money writing and maintaining unit tests that are trivial.

If the unit test is pointless, mark the code under test with some sort of “ExcludeFromCodeCoverage” attribute and spend your time, and money, on more important things.

Convert unix epoch time to DateTime in C#

I recently had to convert unix epoch time to DateTime and like the rest of the world turned to stackoverflow. The top answer is a very simple solution of adding the unix time, which is in milliseconds, to a DateTime of 1/1/1970.

Nothing wrong with that, but it turns out it was added into DateTimeOffset in .NET 4.6:

static DateTimeOffset FromUnixTimeSeconds(long seconds)
static DateTimeOffset FromUnixTimeMilliseconds(long milliseconds)
long DateTimeOffset.ToUnixTimeSeconds()
long DateTimeOffset.ToUnixTimeMilliseconds()

So now you can do something like:

var dateTimeOffset = DateTimeOffset.FromUnixTimeMilliseconds(1454049938871);
var dateTime = dateTimeOffset.DateTime;
Console.WriteLine($"The time is {dateTime}");     // The time is 29/01/2016 06:45:38

I can’t imagine it will make a massive difference to your application whichever way you choose, but I think it’s really good that little things like this are still being added to the framework after all this time.

Further Reading

If you’re really interested, you can look at the /source and see it’s pretty much the same thing, but I imagine it’s slightly more efficient. I guess you could do some metrics, but if converting to and from unix time is the bottleneck in your application I envy you!