Winston Wolf... A scrum master from the movies!

"I'm Winston Wolf, I solve problems..."

This is the introduction from Harvey Kietel's character in the movie Pulp Fiction.

Better quality version
Low quality, but longer clip

Here are some of the excellent Scrum master qualities Winston demonstrates in this clip.

1. Skin in the game. He puts "skin in the game" by showing up to the crime scene. He's now as guilty as the rest of them. 
2. Team. He forms the team. The four guys in the house are the team. They are all in together in the one situation. The husband is part of another team (husband and wife), but the Wolfman takes subtle control of him and takes him into this team using a clear vision, providing a service and providing compliments. 
3. Trust. He immediately builds the relationship and trust. 
   1. Reputation. He comes with a reputation and he makes sure they know it. Sets a seemingly impossible task to start with. Surpasses expectations. (He shows up at an impossible 20 minutes early.) 
   2. Commitment language. He states "He will solve the problems."
   3. Respect. He knows names. Respects his fellow team mates. Commands Respect from the guys.
   4. Forms a bond, establish a relationship immediately.
4. Belief. They believe he can solve their problem. He uses positively and commitment language to instill this belief.
5. Time lines. He understands the deadlines. He ensures everyone else knows the deadlines too by repeating them. 
6. Calmness. Cool head under tight deadlines. Understands the situation. Knows the facts of the case, but is never flustered or excited. Looking at the ugly crime scene, he looks for coffee... I'm so cool under this pressure, I want coffee. 
7. Complements & treats. Small things really help the situation given the pressure. When he gets the coffee he's thanks and compliments the guy who makes it. He makes some jokes at various times.
8. Disciplined. Enforces discipline. Comes across as curt, but then explains himself as he has no positional power.
9. Urgency. He "thinks fast", he "acts fast". All times he conveys the sense of urgency, while not being hasty or flustered. He is calculating and organised. He arrived 20 minutes early!
10. Everything is delegated. Notice that he actually does none of the "Hard Labour"... But note that he asserts that he has expertise in the area. Even though he never lays a hand on anything other than the coffee cup, the team believe he can help them.

---

Updated 22/11/2017

A short discussion on code coverage

What is code coverage? 

Code coverage is a measurement of the lines of code executed during a test. Usually this is aggregated together over a number of tests, to give a suite code coverage metric. It is a measurement that is easy to obtain automatically as there are lots of tools out there to measure it for you. It is usually expressed as a percentage of the lines of source code executed. It is can be used as an indication of quality of the test suite, however like all statistics it needs to be used in the correct context.

What does it indicate? 

Low levels of code coverage indicates that our automated test harness does not do a very good job verifying the entire components' source code. We cannot be confident that the changes we made in this release will not effect some of our users out there in the world.

Hmmm so a higher number is better? 

Yes. Higher numbers can mean we have a very good test suite, but does not guarantee it. When developers use code coverage as a targeted Key Performance Indicator (KPI) when writing tests, a small subset of the required tests would give an artifically high code coverage metric, while leaving little or no confidence in our test framework. It is amazing how many times managers put a coverage KPI on developers. This usually results in an artificially high coverage metric, typically 95+%

So we should have 100% then?

Absolutely. Why not? If the code is well structured AND you thought of all the tests required, it should be pretty near it. You will always have code, like logging, tracing and certain "aspect" type or cross cutting work that you may not test because its not actually business logic or effects business logic. If the code is legacy code the cost of introducing a test framework to reach high levels of code coverage may not be worth the effort. You should instead aim to write the most popular/common test cases and just use code coverage to see help indicate future refactorings/removal of code. 

100% code coverage means 100% confidence? 

Absolutely not. Not even close to 100% confidence. 100% code coverage does not mean we have written 100% of the tests that ensure our code is working. Only 100% of the tests required to test a component ensures confidence when future changes are made.

So I need 100% of tests? 

Exactly. Thats all that matters. Thats what we really should be striving to write, not to hit a coverage limit of 80%, 90% etc.

Can I automatically measure % tests I have written? 

No... not without a clever human involved. This is where a good automated tester earns their bread and they are worth their weight in Gold. Literally.

Some Jack Donnaghy leadership advice thats best avoided

Some stuff a scrum master should probably refrain from doing, no matter how bad your day or week goes...

"Use fear when reason fails"

"Maintain upper hand by delivering backhanded compliments"

"Follow a proven strategy"

"Quote random statistics to prove your point"

While they are hilariously effective, the side effect is to wreck your team.

Thoughts, trials and tribulations...

Well it had to begin somewhere...

I'm a scrum master, working in a development team in Ireland. I wanted to start a blog to re-enforce my learnings as I go about gaining more experience as a scrum master.

I enjoy scrum mastering... High performing teams producing quality software interests me. I am also a geek at heart. I enjoy technology. I enjoy coding, "wiring" software components together to produce something useful, that makes our lives better. I relish doing a good job and take pride in a great product. I think software creation is more craftsman ship than engineering, but engineering principles are very useful to produce it. I am firmly in the camp that the scrum master must be technically very strong and they must keep their programming and engineering skills current. I subscribe to the Agile manifesto.

I think I am a rare, if not unique, type of scrum master.

Anyway I hope to write about a few of my positive and negative experiences here. Sharing is caring. A problem shared is a problem solved.

Cheerio...