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
No Comments

Categories: Individuals and Interactions

Tags:

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

Jeff Grigg chimed in with his concurrence

Dittos!

I’ve never really thought this needed to be described separately, given that combining Refactoring patterns is common. [Isn’t it?!?]

I look at the callers to a method and think, “This isn’t quite right. There’s still duplication among the callers, the parameters aren’t quite right, (etc…).

So I
– Inline
– Adjust a bit
– Extract
– (And usually adjust a bit to “clean up” after.)

https://mastodon.social/@JeffGrigg/110262321232963245

One of the big benefits of this sequence is that it encourages thinking about the concepts instantiated in code, and honing those concepts to be more appropriate to the domain under construction. This addresses the “technical debt” as originally described by Ward Cunningham by making the code more closely follow the concepts needed by the domain.

Another benefit is that editing the code becomes less about typing characters or lines of code, but about expressing the concepts important to the task at hand. I’m certain that this practice of editing at a higher level of abstraction is part of the reason that I became more productive when I started practicing Test Driven Development. Certainly it is responsible for TDD making me a better Object-Oriented programmer.

No Comments

Categories: Tools and Techniques Working Software

Tags: ,

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
2 Comments

Categories: Individuals and Interactions Tools and Techniques

Tags: ,

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
No Comments

Categories: Responding to Change

Tags: ,

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
No Comments

Categories: Tools and Techniques Working Software

Tags: , ,

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:

Daily Stand-Up Meetings

It’s my observation from watching small groups of people working together that it’s almost universally common that some people will take charge and direct the common effort and others will get quiet, abdicating any such role.

It’s also my observation that, even in a small team working together daily, people notice different things, interpret the things they notice differently, and assign different significance to those interpretations. People often think that because they are immersed in a common experience that there’s no need to talk about it. This appears to not be so.

Groups of technically oriented people often want to optimize the work process to those activities needed for the technically oriented output, and overlook those that are focused on the needs of humans and groups of humans working together. Yes, you can have a standup and not get any value from it. You can also not have a standup and avoid providing a convenient mechanism for taking advantage of the differences in observation, interpretation, and significance made by the entire team.

If you’ve got a really good team facilitator, they’ll likely notice this and help bring it out. If they’re really excellent, they’ll convince the team to work in a fashion where it can more easily come out without them acting as a middleman to make it happen. They might use a simple technique such as a daily standup to create such an opportunity.

No Comments

Categories: Individuals and Interactions

Tags: