Five for Friday – November 9, 2018

Well, that

  • First is that I love it when people share music with me. One of my team members introduced me to mouse on the keys, and I am enjoying their music so far. One of my favorites is ‘spectres de mouse‘ (Spotify link)
  • The New York Times built a nice visualization of election results – quick and simple and tells a story – all good attributes of data viz
  • I will save a link to this infographic on Scrum vs Kanban. It highlights the pros and cons of each (ftr, I have a strong preference for Kanban). The cons list remind me that no matter what model you choose if you fail to follow the principles of the model, it’s probably not going to work for you.
  • I’ve taught a lot of developers how to write better tests. This article on why good developers write bad unit tests reminds me of a lot of that coaching
  • I saw Bohemian Rahpsody last weekend, and you should go see it too. As a long-time Queen fan, I admit I had a bit of a hard time with the movie’s subtle and fictional strays from the history of the band, but the story and acting were fantastic

Five for Friday – November 2, 2018

I’m getting to a stage in my career where I’m beginning to realize that some of my biggest growth happens when I’m doing nothing but thinking.

But, I did leave my head a few times this week and found a few interesting things to share.

  • Quote I’m thinking about: “A creative man is motivated by the desire to achieve, not by the desire to beat others.” – Ayn Rand
  • If you’re reading this in the US, please vote. If you’re not in a mail-to-vote state (or even if you are), there’s likely relevant information here
  • This article that asks, Is it time to bring data to managing? brought back a few memories of the awful performance management at msft – along with some reasonable ideas on doing better. 
  • Also on the leadership front is this article on leading with love (actual title is less fluffy). It reminds me of the care personally aspect of Radical Candor, which is something I continually try to do better.
  • I love solving debugging mysteries and figuring out those WTF moments in software. I found this article on debugging an AWS issue that was fun to follow. One punchline – “Why Amazon S3 returns two different errors for the same problem is beyond me, but that’s not important here.

Five for Friday – October 26, 2018

Five for Friday – October 19, 2018

I’m preparing for some meetings with some colleagues in Europe next week and I’m a little frazzled. But this is what my frazzled brain liked this week.

Five for Friday – October 12, 2018

Another Friday, another week with cool things to share.

Five for Friday – October 5, 2018

Here are a few (five, actually) things I saw this week and liked.

Five for Friday – Friday, September 28

Here are a few of the things I found interesting this week.

  • I thought this article about “hacking” British Airways was sort of interesting – but mainly that they glossed over the real hack – “It is likely that the hackers had access to the site, and modified the code to insert a backdoor.” 
    Read and make your own judgement.
  • Camille Fournier (author of the wonderful book, The Managers Path posted this article on engineering productivity.
  • Ben Kelly says, You probably need fewer testers than you think (and he’s probably right)
  • Saw this on twitter from Cassie Kozyrkov on Speaking at conferences. It’s really good (especially compared to the usual posts on this topic)
  • Finally, I tweeted about this, but it’s worth calling out here too.

Five for Friday – September 21, 2018

I had this weird empty feeling all afternoon, and it just hit me. I (almost) forgot to post my five interesting finds from the week.

Five for Friday – September 14, 2018

Here’s stuff I found interesting. Some of it published recently – some is not. 

  • I posted earlier this week about painful observations of “stand-ups” turning into horrible status sentences. Seth Eliot pointed me to this great post by Henrik Kniberg that covers my peeve better than I did.
  • I’ve been reading Option B by Sheryl Sandberg and Adam Grant. I’ll avoid personal feelings and just say that it’s well-written, and I’m enjoying it.
  • I loved The Children’s Guide to Kubernetes. Heck – even I can understand it.
  • I frequently (consistently?) state that a retrospective is the single most important meeting your team can have. While this article (4 Reasons Why Your Scrum Sprint Review Isn’t Effective) focuses on the scrum sprint review ritual, the concepts apply to any retro.
  • Continuous Testing for Devops Professionals is out. I’ve read 90% of it (I was fortunate enough to be a reviewer), and think it’s pretty good.

Status and Progress

Status meetings are boring. More importantly, status meetings are unneeded. Meetings are for discussion, and updates on status rarely require that (until, of course, they do). Nothing – nothing is more painful than sitting through a meeting where people go around the table and say, “Today, I’m doing X”. 

Hopefully nothing alarming so far.

A lot of teams have adopted Scrum for project management. One of the rituals of Scrum is the daily stand-up where traditionally, 3 questions are asked:
1) What did you do yesterday?
2) What are you doing today?
3) What is blocking you?

And a lot of times during the stand-up meeting, most people say something like, “Yesterday, I worked on the fizz filter. Today, I’m working on the fizz filter. Nothing is blocking me.”

And then the next day at stand-up, they say, “Yesterday, I worked on the fizz filter. Today, I’m working on the fizz filter. Nothing is blocking me.”

Eventually, since the answers to questions 1 and 3 never change, standup information is “optimized” to something like this:

Today, I’m working on the fizz filter.”

…and this repeats until they’re (eventually) done with the fizz filter.

Something is wrong, right?

Somewhere in the rituals of scrum or agile, teams who operate like this lost the importance of communication and collaboration – they go through the motions of “agile”, but fail to get the immense value that’s easily within their grasp.

If you’re tied to the canonical three questions of scrum, then at the very least you owe it to your team to improve the way in which you communicate your status. Discuss details; include something you learned (maybe you were blocked, but figured it out); think about how other team members may be able to help you. You can also make a big dent in the scrum-as-status-reporting problem if you break your work items into things that can generally be done in a day or less.

Yesterday, I worked on the database connection for the fizz filter. I had a challenge getting the ODBC connection set up, but Janet gave me some tips and I got the problem solved. Today, I’m going to write a test suite for the fizz filter database connection. I may need some help learning the new test runner, but other than that, I should be good to go”

If you want to go further, Brent Jensen taught me a question that I now use to drive any project management meeting I’m in. This came up while discussion managing a team using kanban (which I believe, when used correctly, far exceeds scrum as a project management framework), have task owners answer one question:

What needs to be done to move this task to the next column?

The question is automatically contextualized by the kanban column containing the task. Answering the question reveals questions, dependencies…and even status. 

The question from Brent is wonderful, but the the main point here is that your status messages (barf) or status meetings (double-barf) aren’t helpful for you, your team, your software – and ultimately, your customers. The great news is that it’s easy to do better.

What needs to be done to move this task to the next column for your team?