Today I read… (8/16/2017)

A Guide to Becoming a Full-Stack Developer in 2017

Today I read… (8/15/2017)

6 Deep Learning Techniques They Never Taught You In School


I realized that I sort of use the Feynman technique. After I read something, I usually think about how I would explain it to someone or how it relates to my own experience.


Today I read… (8/13/2017)

How to Take Down Kim Jong Un

Daily Scrum – Person-by-Person or Story-by-Story?

Is your daily scrum conducted person by person? Do you jump back and forth from user story to user story because people working on the same story don’t speak one after the other? Does this context switching make it hard to understand the progress of that particular story?

I think the standard, and most obvious, way of conducting the daily scrum is to simply go around the room person by person. But, there is another way – going story by story through the sprint backlog.

I have tried both ways. When I was new to Scrum, it just seemed obvious that you would go around the room. This method will probably work fine for small teams or teams who take on a small number of user stories in their sprints. In other words, if there isn’t much context switching in the scrum, then going around the room should work fine.

But as your team grows the opportunity to switch context back and forth between stories will grow. And this is where the second scrum method, going story by story, can help.

With this method, you’ll ask who is working on a particular story and those team members will answer the scrum questions. That way you get a full picture of the progress on that story at once. Mike Cohn describes it this way:

For some teams, conducting the daily scrum by product backlog item can make much more sense than going person by person. When going item by item, someone on the team (often the Scrum Master) says, “OK, let’s talk about this product backlog item next. Who worked on it yesterday? Who is going to work on it today? And is anyone stuck on anything to do with this item?” When a team conducts its daily scrums this way, there is less lost context.

I used this method for a large Scrum team and everyone preferred it over the person by person method. However, I did notice some problems that you need to watch for.

The first was that the scrum can become mini status reports for each story. Because you now have multiple people talking about a story, it can be tempting to drill into details. Instead of each person answering the scrum questions and moving on, a discussion can start. So be careful about that and if necessary remind people to avoid status reports.

Another potential problem can occur if some team members are working on multiple stories. Those team members will have to get accustomed to only talking about the story being addressed instead of all their stories at once.  This isn’t a huge issue as long as they stay focused on the story currently being addressed.

Have you tried the story by story method? Let me know how it worked for you.

Scrum Master Mistakes

We all make mistakes as Scrum Masters. As we say “Scrum is easy to learn, but difficult to master.” We do our best and learn from our mistakes.

Mike Cohn talks about some mistakes he sees in his blog post “Three Mistakes Scrum Masters Make and How to Correct”.

I could have guessed the first and third mistakes he writes about. But, the second surprised me. Basically, Mike says the Scrum Master should not run the daily scrum.

I definitely have a take-charge personality and I do keep the daily scrum moving along by calling on people. And I think Scrum Masters need a leader personality in order to encourage the team to follow the Scrum principles.

I understand the desire to have a team which runs the scrum itself, but I’ve always seen my role as a facilitator. Now, I’m not trying to take over the scrum, but I’m making sure it doesn’t bog down, instead of being a silent observer. I regularly remind team members that they are sharing information for the benefit of the team, not for the benefit of the Scrum Master. Also, each Scrum team I’ve been on has had some remote members and calling on people was necessary at some point during the scrum.

However, I can see that a more hands-off approach will help the team become more independent and self-reliant. So this is something I will work on. I’ll ask the team to start the scrum and give the input without being prompted.

I can see another possible benefit. I mentioned earlier that the information shared in the scrum is for the benefit of the team itself. I tell my teams that the scrum’s purpose is to plan the work for the day so it supports the completion of the sprint goal. Although, I struggle to drive that ideal home to some team members. Sometimes input for the scrum can be too brief and not very helpful, or sometimes it’s more like a status report. Maybe a more team-driven scrum will help improve on this.

Let me know your what you think and what works best for you.

Today I read… (8/10/2017)

Reasons to Estimate During Planning Poker with the Whole Team

Three Mistakes Scrum Masters Make and How to Correct Them

Today I read… (8/8/2017)

Hack Your Mind: 7 Steps to Upgrade Your Mental Software

How to Spot Visual, Auditory, and Kinesthetic-Learning Executives

Key Takeaways:

Total confirmation that I am a visual learner!