Stuff I learned working as a scrum master

 

Working as a scrum master I learned a couple of hard truths :

• People have a lot of misconceptions about what a scrum master should be doing
• Sometimes they are true (which makes things worse)

Now If you take a look at the Scrum guide the scrum master has a lots on his plate:

Now the things I most often hear is that the scrum master should:

• make sure there are burndown charts (as the single most important thing a scrum master does)
• organize and run the scrum events (although the guide says that the scrum master should be doing that as needed or as requested)
• remove impediments

I’ll be honest, in relation to burndown charts I never drew one (there are tools for that). I find that tiring and I think there are better uses of my time. But surprisingly this is what I most commonly hear from developers – “My previous scrum master was spending most of his time drawing charts and organizing meetings …..” – what?

Scrum events are important but the thing is that the value of a scrum event is not provided by a scrum master but by the people joining the event. I think that helping people to prepare for the scrum event is much more important then actually running the event it self. I rather focus my self on facilitation then on meeting organization.

Removing impediments its a very important thing. The team has bring business value by working on the sprint backlog as agreed with the product owner. Anything that is preventing the team to do that must be ruthlessly removed.

Now here lies the catch. That could be a wide variety of things. And is really contextual – what is the current situation within the team and the company dictates what is an impediment and what is a possibility to grow.

In situation A the team needs to build a MVP (Minimal Viable Product) to put on the market as quickly as possible. Anything preventing the team to the most important tasks to achieve that is an impediment ( I try to simplify things as much as I can). Now in that situation building a continuous integration server , something the team has no experience with , or making sure all resources on Azure are created as they should or taking care of 3rd line support calls coming to the team or helping write all the unit tests or doing some research or … the list could grow. And all those things could also be things the team could be doing and taking them as learning and growing opportunities.

Its highly contextual.

Now for me the rule of the thumb is as follows:

• Is it part of the teams core skill set – yes (let them do it)
• If not is it needed to achieve sprint goal – yes (ok deal wit it somehow)
• Is this the right time to grow the team on this skill – yes (let them do it, and help them)
• If not take care of it your self or find somebody who will

DotNet Core : The good, the ugly and the just started

I just started out playing with .NET Core on my own time. Getting the feeling for the technology, trying to learn the basic concepts and getting some basic programming tasks done.

Wow.

Working in .NET for the last eight or so years I really find this one much more different then the usual flavor provided by Microsoft.

Lets be honest, on most .NET projects I worked the MacDonalds style of programming, where 80% of the problems are solved easily by spending 20% of your project time while you spend the remaining 80% dealing with the remaining 20% of the problems which incidentally are what the the project is about. Go figure.

With this first dotnet core project I spend my time dealing with something completely different. It actually reminds me of the time I was learning to code in PHP and Python (it was years back during my Linux times).

The first thing that struck me was complicated level of setting up a project (project.json configuration) and linking all projects in a solution together and then managing all the different execution and deployment environments. Whaat?

But hell, its fun to deal with these type of issues.

Most of the help I got didn’t come from the actual documentation. It was mostly useless, so I just relied on googling for solutions or going directly to the dotnet core repository and looking trough the source code.

The second biggest problem was that there was not a solution wide way to build all projects and run all tests. Well, that was easily solved by using the custom Task functionality of VSCode.

Something like this:

.vscode/tasks.json

And then in the root of the solution writing this small batch script:
build.cmd

And then with a simple, and familiar CTRL+SHIFT+B , voila:

it builds everything and it even runs all the tests.

The command line interface is simple and easy to understand, and once you get past the project.json madness you will have a literally very powerful platform to work on.

The coolest thing it is that the project is completely open source so well if you find a problem or have a need, the solution is several hours and a pull request away.

Of course I don't see .NET teams jumping all over it right now. I haven't yet tried developing in .NET Core with Visual Studio but I guess as with every version 1.0 of a Microsoft Technology the tooling will suck long time (usually we have to wait till version 3.x till we get the maturity level high enough to develop normally). But hell, I could be very wrong.

Still its a cool thing to play with. If you are curious what I did so far please look at my GitHub profile: