A Highly Evolved Card Wall

I’ve been promising Mark Levison since forever to describe the highly effective card wall that evolved at one of my past clients. The team started with a simple beginning, and modified it as they saw fit to suit the needs of their situation. This is not a universal model for others to blindly copy, but there is much to learn from it.

No doubt that it continued to evolve beyond my knowledge, as this team spectacularly took control of their own development process. I’ll never forget the Monday morning that I walked into the team room, direct from the airport, and saw them pulling cards and tape off the corkboard wall. “What the heck are they doing?” I thought. I stood and watched from across the room as the scurried around excitedly with much conversation. Tape and cards started to go back on the wall in a different configuration. I knew then that this team was going to excel, as they were paying attention to how things were working for them and adjusting accordingly. Excel they did, and their wall was in frequent flux as long as I knew them. It’s amazing what a team can do when they have the desire and freedom to improve.

Read More

Who Should Attend The Retrospective?

For years, I’ve seen people argue online about who should and should not be invited to a retrospective. In typical consultant fashion, my answer is “It depends.” Here I want to describe the dependencies so that it’s not such a mystery.

First, let’s define the basics so we have a foundation for the conversation. My definition of a retrospective is

  • Looking at the past, together
  • To gain insights
  • And make choices for the future.

“Looking at the past, together” is what the word “retrospective” literally means. The word dates to the 17th century, and is formed from the Latin retro meaning “back,” and specere “look at.”

Let’s see how this affects the question of who should attend.

Read More

Refactoring Arpeggio

The other day, GeePaw Hill mentioned on Mastodon

“inline-jiggle-extract” is a coding pattern that needs describing.
If I were a better person, I would write that up.

https://mastodon.social/@GeePawHill/110262262154288983

As it happened, I’d recently talked about that pattern on LinkedIn

I found the sequence of inline, re-order statements, extract to be one of my favorite refactoring arpeggios.

https://www.linkedin.com/feed/update/urn:li:activity:7055994041762508800?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7055994041762508800%2C7056048897181241345%29
Read More

Optimization of Human Systems is a Fool’s Errand

Michael James is on a rant against Agile Coaching as it often appears to be practiced, but what he describes doesn’t sound much better, to me.

Michael describes Agile Coaching as “push[ing] processes and ways of working on teams,” and “trying to ‘change management culture.'” He suggests “starting with a clear system optimization goal stated again and again from upper management.” Never mind that this, itself, is an example of trying to change management culture, assuming that’s not what they’re already doing.

Read More
No Comments

Categories: Individuals and Interactions

Tags:

Features and Stories, Large and Small

Imagine you work for a company that produces a videoconferencing system. You’ve done pretty well with it, but you’re middle of the pack of competition. Then there’s a worldwide pandemic, and the market for videoconference software explodes. There’s a silver lining in this terrible event. A rising tide lifts all boats, right?

Maybe not, if the competition has more of what the customers want. It’s critical to remain a viable choice in the eyes of customers.

Read More

Accommodating the Unexpected

As I write this, much of the world is in a state of disarray. Many businesses are shut down for fear of spreading the Covid-19 virus, and others have suddenly switched to distributed work over the internet. Most software developers are working in physical isolation. Even those accustomed to working remotely are reporting that the current situation is affecting their ability to get things done.

I think it is safe to say that no software development organization expected this to happen. No IT department accounted for the disruption in their estimates and plans. While epidemiologists could predict that there would eventually be a worldwide pandemic, even they could not predict the severity or timing of such a disruption.

How has this affected your work? Are you still expecting to meet the plans made before this happened? Have you given up planning altogether, just trying to get something, anything, done? Or have you looked at how things have been progressing in the last 2 or 3 months and adjusted your expectations?

Read More

The Order of Tests

It’s been awhile since I’ve done much coding. That’s not my day job anymore, and I lose interest working by myself. In the past week, however, I’ve had a couple opportunities to mob program remotely with the Canton Coders. With the COVID-19 restrictions on gathering in person, people are much more likely to work with you virtually.

So last week I found myself mobbing on the Roman Numeral kata and today on the Zeckendorf kata, both on cyber-dojo. A lot of fun was had by all, and I rediscovered what I know about Test Driven Development with a bit more clarity.

Read More
5 Comments

Categories: Tools and Techniques

Tags:

More About Development Culture

Josh Kerievsky called me to task for not following up on his third version of his story of providing a quick fix before a test-driven fix. As I said, I don’t want to be critical of Josh. I will, however, cast a critical eye on the code he has shared.

For those just tuning in, the previous installment talked about differences between the culture we espouse and the culture we practice. This installment will return to that.

Read More

TDD, Options, and Culture

The background for this post: Gil Zilberfeld posted a link to a blog post by Joshua Kerievsky. I had some questions and Josh’s response, to me, seemed to change the story a bit. As I suspected, the story is hypothetical, and changes to support the intended conclusion. This always makes it very slippery to talk about a story. The details matter. And in this case, the change overwrites the original, without any indication of what has changed. That makes it even harder to have a conversation about it.

The Story

I’ll give a synopsis of the story here, since it may change again. In brief,

  • “A customer reports a defect. It’s inhibiting them from getting some important work done.”
  • David finds the defect and test-drives a fix, including refactoring to re-design the code around the defect. He spends two hours doing so.
  • In a parallel universe, Sally finds the same defect, fixes it without an automated test, hand-tests the fix, pronounces it good and pushes it to production. There’s no indication of how long this took, but presumably it’s intended to be less than two hours.
Read More
2 Comments

Categories: Tools and Techniques

Tags: