I’ve written about Ruth Malan’s work elsewhere. I recently come across a tweet she shared:

@ruthmalan:

“making a picture is itself transformational:

1. [..]focused on common goals rather than the things that divide them
2. a co-created picture combines goals, roles and an agreed path [..] literally gets everyone on the same page
3. [..]is a litmus test for feasibility”

– @davegray

View on Twitter

Coincidently, I was able to experience this recently with my team. I’d been pushing for more design and facing resistance. On one occasion, I forced a design activity when some team members deemed it unnecessary.

To the team’s credit, they created the diagrams, reviewed them and discovered the requirement could be achieved in a simpler way. Nah, it was deemed unnecessary.

I can’t emphasize enough how the simple act of drawing a picture is transformational.

Interestingly, some team members expressed concern about the quality of the diagram. I’ll emphasize that a photograph of a whiteboard drawing is more than sufficient to achieve understanding.

People are sometimes afraid to express themselves using drawings because of expectations they place on themselves. If your team has trouble putting pen to paper consider whether unstated expectations on format are holding them back. Focus on understanding instead. It’s more valuable.

The team and I have been struggling with improving several Scrum activities. The planning meeting is one of them. Our struggle focused on how to get more value from the planning meeting.

One team member decided to increase stakeholder engagement by engaging on whether the stories the team was about to commit to were in fact ones that could be completed by the team. The result was astounding.

We initially focused on logistics – are the components in place and operational that permit software development? Basic impediment management. This quickly expanded into a run through of our ability to test the story.

I’m actually excited by this development because we are improving interaction with the stakeholders and it’s a benefit to everyone.

I’m in the process of changing defect management in my team. We use our retrospective to review defect and cost overruns during the sprint.

The change I’m making incorporates two ideas:

1. every defect is a lifecycle issue, and
2. start with the code change that prompted the defect.

The first idea ensures the retrospective remains a safe place to acknowledge errors. This is important because the errors that prompted the defect could be the result of an error made by someone at the retrospective. For example, a coding error that escaped code review.

The second idea ensures we focus on root cause and not the defect correction. This is important because the defect is a symptom. First, focusing on the correction would repeat the code review. Second, this sets up the context so that the focus is on what was being attempted when the defect was introduced.

I focus on the code because that’s closer to where the error manifests. Defects manifest as a behavioural or functional issue because something isn’t meeting the expectation of “working”. Since we have a patch for the defect we have a notion of what expected behaviour is. What we don’t know is where the problem entered the lifecycle.

I could focus on the test but it seems obvious we lack a test case otherwise the defect would have been corrected earlier. Clearly, a lifecycle issue that manifests in requirements won’t have a test case…

Since the code is the focus I use the commit history as the starting point.

R3 <- defect fix applied to great new feature

R2 <- another great new feature

R1 <- great new feature

The patch applied in R3 might update changes in R2, R1 or both.

What motivated R3 is interesting. What motivated R3 is in R1 or R2 or both.

That is R3 might:

• fix something in R1,
• fix something in R2 that negatively impacted R1, or
• fix something affecting both R1 and R2.

The problem gets complicated when there are many revisions affected by the defect fix. Such situations will bring in multiple people and perspectives. And hopefully ways to mitigate recurrence.

Code reviews is one of the first activities I introduced into my software team. Over the next two years, I watched my team move from a collection of co-located individuals working in silos to a group of people who embraced the idea of improving our code. I attribute this change in part to code review.

The team and I structured our code review around two simple rules.

1. Review everything. Even one line changes.

2. Honour the reviewer’s veto on the “ship it”.

It’s worked marvellously.

Still, I often felt silly requiring code reviews for a one line change. I find myself explaining that quality starts with a single line of code. I find myself having to explain this a too few many times to skeptics.

I was pleased to learn from Vaidehi Joshi’s article Crafting Better Code Reviews that Steve McConnell’s research included statistics for improvements on code reviews of one line changes.

Finally, vindicated.

In The Problem You Solve Is More Important Than The Code You Write, Fagner Brack reminds us that not writing code is a better solution. Fagner’s thesis is that choosing what to write is secondary to the problem you solve.

He writes:

There’s a difference between encapsulation of complex logic and abstraction of useful knowledge. Sometimes, information should be made explicit to be comprehensible. If you abstract them, they can have the opposite effect and be harder to understand.

Abstraction as a tool of obsfucation.

This is an elegant framing of a problem I keep running into: When do you stop introducing abstraction? Fagner provides the best answer I’ve seen to this question: don’t introduce an abstraction if it obscures important information. Or impedes understanding.

A corollary, to Fagner’s thesis then might be that the abstraction employed to create an implementation must draw from and not obscure domain knowledge.