George Dinwiddie's blog
type: channel
description: Effective Software Development
date: 2024-07-11T11:45:52Z
update period: hourly
update frequency: 1
update base: 2000-01-01T12:00+00:00
generator agent: https://wordpress.org/
items: The Value of Iterations
items: Another Visualization of the Satir Change Model
items: A Highly Evolved Card Wall
items: Who Should Attend The Retrospective?
items: Refactoring Arpeggio
items: Changing Recurring Outcomes
items: Optimization of Human Systems is a Fool’s Errand
items: Features and Stories, Large and Small
items: Accommodating the Unexpected
items: The Order of Tests

The Value of Iterations
type: item
creator: George Dinwiddie
date: 2024-07-11T11:45:52Z
subject: Tools and Techniques
subject: Agile
subject: Estimation
subject: Progress
subject: Time Boxes
description: I often see comments in social media disparaging working in iterations. I’ve heard such comments in person at client sites in the past. Why do some people dislike iterations so much? Sometimes they talk about the high overhead of repeated planning and tracking. This makes me suspect that their planning and tracking procedures are not […]
encoded: I often see comments in social media disparaging working in iterations. I’ve heard such comments in person at client sites in the past. Why do some people dislike iterations so much? Sometimes they talk about the high overhead of repeated planning and tracking. This makes me suspect that their planning and tracking procedures are not aligned with their needs. Estimating stories is a particularly sore point. People often try to estimate with a precision much greater than they need. If you’re working in iterations, there’s really only two needs for story estimation. Have we prepared enough work to keep us going for the duration of the iteration? Are we getting ahead of ourselves and preparing too far into the future? In other words, we want to have enough work prepared that we don’t have to stop working on it to prepare more in mid-iteration, but we don’t want to prepare more than we need right now. This often gets translated to “preparing exactly the amount of work that we’ll accomplish,” which is accompanied by a lot of anxiety that we’ll miss that measure. That’s WAY TOO MUCH precision. Just try to get it “close enough.” What sort of preparation? In my experience, the important part is that we understand what we want each bit of work to accomplish. Some people get that as a by-product of estimation. I prefer to use Matt Wynne’s Example Mapping to achieve that understanding together from all appropriate points of view. I’ve also seen people upset about the other end of the iteration, anxious that they won’t accomplish exactly the amount of work that they prepared. This usually gets warped into preparing a little more than they can accomplish (not a bad thing) and then someone is disappointed they didn’t accomplish it all (which encourages safely aiming low). I’ve seen teams move to (an approximation of) Kanban just so they won’t be judged as not having delivered “enough.” When that happens, progress seems to get slower and slower. If you want to get somewhere, it’s …

Another Visualization of the Satir Change Model
type: item
creator: George Dinwiddie
date: 2024-05-17T17:56:02Z
subject: Responding to Change
subject: Change
subject: Virginia Satir
description: Some years back I had a conversation with Bas Vodde about the graphical way that the Satir Change Model is usually represented. If you search on the internet, you’ll likely to end up at Steve Smith’s description, which is very good but shows “performance” as if it’s a measurable thing. While at the UNC Satir […]
encoded: Some years back I had a conversation with Bas Vodde about the graphical way that the Satir Change Model is usually represented. If you search on the internet, you’ll likely to end up at Steve Smith’s description, which is very good but shows “performance” as if it’s a measurable thing. While at the UNC Satir Summer Intensive workshop in 2018, I thought about a different way to view the process of change. This view is less from an external point of view, and more from the point of view of the person going through the change. Rather than a graph, it’s a map of the journey from the Old Status Quo to the New Status Quo. <img fetchpriority="high" decoding="async" width="1024" height="576" src="https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080-1024x576.png" alt="" class="wp-image-1589" srcset="https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080-1024x576.png 1024w, https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080-300x169.png 300w, https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080-768x432.png 768w, https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080-1536x864.png 1536w, https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080.png 1920w" sizes="(max-width: 1024px) 100vw, 1024px" /> Late Status Quo Imagine you’re sitting at home, minding your own business. It may not be the life of your dreams; it may not even be without pain and annoyances, but you’re accustomed to the way things have been going. Foreign Element Then something happens that upsets the apple cart and drives you out of your recent status quo. This may be an internal event, such as deciding that your status quo isn’t good enough, but it’s most often externally triggered. Something may have happened that revealed your status quo wasn’t good enough for you any more. Something may have happened that destroyed your status quo–perhaps you were let go from your job, a loved one rej…

A Highly Evolved Card Wall
type: item
creator: George Dinwiddie
date: 2023-12-24T20:14:20Z
subject: Tools and Techniques
subject: Information Radiators
subject: Planning
subject: Three Amigos
description: 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 […]
encoded: 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. New ideas on the horizon This was an IT team, and the functionality they were to build was handed down to them from executives of various departments of the business. The team included a sub-team of analysts to receive and make sense of these requests. As they came in, the names of these requests were recorded on index cards, and pinned up in the left-hand side of the wall. This area came to be known as the Nursery. These represented work that was desired by someone, but hadn’t yet been started. Seeing them on the wall kept them visible during conversations, though. Sometimes those conversations resulted in something else happening, and a card being removed. Business Analysis To the right of the Nursery was a section called Pre-School. It was here that the analysts kept track of their work as they interviewed various people in the business to turn v…

Who Should Attend The Retrospective?
type: item
creator: George Dinwiddie
date: 2023-04-29T17:34:14Z
subject: Individuals and Interactions
subject: Retrospectives
description: 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 […]
encoded: 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. What are you looking back at? For a retrospective to make sense, the people involved should be looking at some shared experience. They’re unlikely to come up with insights if they’re each looking at something different. I emphasize the “together” part because I see so many teams and organizations assume that everyone saw the same things and interpreted them the same. Even for a small team working together in a common room, this is almost never true. The differences in what different people noticed, or how they interpreted what they noticed, is often the root of the most illuminating insights. The “who should be invited” question is answered by “who shares that experience.” If you invite just the programmers who are working on a project, they’ll address the things that are important to programmers, and therefore noticed by them. There may be times when this is exactly what you want. As you move to “whole team” product development, you’ll naturally want to include other members of that whole team to include other points of view—that of software testers, designers, customer researchers, and whomever else is adding value to the product. These various constituencies may be working somewhat independently, but toward a common result. The more closely these constituencies work in collaboration, the more …

Refactoring Arpeggio
type: item
creator: George Dinwiddie
date: 2023-04-26T17:41:28Z
subject: Tools and Techniques
subject: Working Software
subject: Refactoring
subject: TDD
description: 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. […]
encoded: 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.

Changing Recurring Outcomes
type: item
creator: George Dinwiddie
date: 2022-03-18T21:16:51Z
subject: Responding to Change
subject: Change
subject: Systems Thinking
description: Has it ever seemed to you that you’ve been here before? Have you ever gotten that sense of deja vu that the situation around you is completely familiar, even though some of the details are different? I have a motto: “When some behavior persists, a feedback cycle exists.” What does that mean? When W. Edwards […]
encoded: Has it ever seemed to you that you’ve been here before? Have you ever gotten that sense of deja vu that the situation around you is completely familiar, even though some of the details are different? I have a motto: “When some behavior persists, a feedback cycle exists.” What does that mean? When W. Edwards Deming said “A bad system will beat a good person every time” he meant that it doesn’t matter if you’ve got good intentions and work hard if the system is designed to produce bad outcomes. What I mean is that when a system repeatedly produces certain outcomes, it’s a signal that the system is designed to do so. That doesn’t mean that someone intentionally designed the system for bad outcomes. I’m talking about the de facto design—the one we happen to have. In a complex system, there are lots of effects going on that we can’t predict, or even easily observe. And any system made up of people in inherently complex. Perhaps someone did try to design the system to produce desired outcomes. The mere fact that they called it “designing the system” rather than “growing the system” signals that they were assuming the problem was merely complicated rather than complex. Complex systems have all sorts of non-linearities and unintended side-effects. Complex systems also have extraordinary staying power if they’ve survived at all. They have feedback loops where some the increase of some observable behavior either inhibit or promote some other behaviors. Each of those behaviors, in turn, inhibits or promotes others, and so on, until we have a behavior that either inhibits or promotes the one we started with. If the number of inhibiting influences in the circle is an even number, then they “cancel out” and the result is that our starting behavior promotes itself. That’s what makes it impossible to change the behavior by “trying harder.” Instead, we have to change the system. Changing the system is not an easy thing. Again, you can’t go to the drawing board, draw the system you t…

Optimization of Human Systems is a Fool’s Errand
type: item
creator: George Dinwiddie
date: 2021-09-28T20:04:10Z
subject: Individuals and Interactions
subject: Coaching
description: 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 […]
encoded: 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. A Clear System Optimization Goal The part that worries me is that a “clear system optimization goal” implies that “better” can be described as optimizing along one dimension. The very word “optimization” implies that there exists an optimal outcome or organization. Optimal from the point of view of whom? For what purpose? Such a goal sets a target that, as Deming alluded, people would meet at the expense of destroying the enterprise. In truth, there are many aspects that we care about. Some of those aspects may be valued widely through the organization, and other aspects by only a few. While there may be trade-offs between these aspects, it’s unhealthy that any single aspect take precedence over all others. Profitability? Would you give up the lives of the employees for that? Or the survival of the organization? In a related article, Michael suggests the system optimization goal of the “organization’s ability to respond to change.” Maximizing this at the expense of all other measures, however, would result in an under-damped system with little or no stability. I’ve seen organizations chase whatever is the latest request made of them, and the result is disheartening. While being adaptable is a great strategy, it only maintains its value if it’s accompanied by enough stability to preserve what you’ve already achieved for as long as you need it. Whose Point of View? Given that Michael mentions the “system optimization goal stated again and again from upper managem…

Features and Stories, Large and Small
type: item
creator: George Dinwiddie
date: 2020-05-18T15:07:28Z
subject: Individuals and Interactions
subject: Tools and Techniques
subject: Product backlog
subject: User Stories
description: 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 […]
encoded: 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. The VP of Marketing says, “We can’t compete. We we need a breakout rooms feature.” “Why do we need that?” “Our competitors have it, and we’re losing sales.” “What do people use breakout rooms for?” “I don’t know. Just build it.” So, a new feature, Breakout Rooms, is added to the product backlog. It’s a Feature because it’s a named part of the product rather than a capability the product gives to the customer. It’s a noun, not a verb. If you were selling this product in a box in the grocery store, you might add a banner across the top corner saying “Now with Breakout Rooms!” The VP of Product looks at the updated backlog and asks “What are Breakout Rooms?” “They’re separate workspaces where some of the participants can work separately from the rest.” “How are they used?” “There seem to be a number of different ways. Just among ourselves and our friends, we’ve come up with a short list.” A meeting facilitator may want to break up a meeting into separate subtopics and assign people to each. A meeting facilitator may want to have small-group discussions so that everyone gets a chance to contribute without it taking an undue length of time. A meeting facilitator may want people to work with intermittent ongoing support from a small group within the context of a larger exercise. A meeting may divide into multiple topics, and the facilitator wants to let participants self-select which topic interests them. During meeting breaks, people may want to have “hallway conversations” with others, but without the burden of everybo…

Accommodating the Unexpected
type: item
creator: George Dinwiddie
date: 2020-05-17T17:44:56Z
subject: Responding to Change
subject: Estimation
subject: Planning
description: 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 […]
encoded: 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? The unexpected happens in smaller, less noticeable ways, all the time. I’m amazed when I see otherwise Agile development shops estimate all the user stories they think will constitute a software release, plan dates on those estimates, and expect to hold that steady as if they won’t learn anything while implementing those stories. Others have been dismayed by such behavior, and call for bypassing planning and just working on what seems valuable at the moment. I can’t imagine keeping a company successful without reasoning about potential future events. In fact, I think that’s so important that I recommend revisiting this on an ongoing basis. Sure, estimate what’s needed to meet your goals, though I might do it on a higher level than user stories. Make plans based on those estimates, but include contingency buffers in your plans for the unexpected. Measure your progress along the way. When your progress doesn’t meet your expectations, don’t get out the buggy wh…

The Order of Tests
type: item
creator: George Dinwiddie
date: 2020-03-30T03:23:47Z
subject: Tools and Techniques
subject: TDD
description: 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 […]
encoded: 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. Both of these katas involve converting base-10 numbers to some other representation. It’s a natural assumption to start with 1 and work your way upwards. This can make your work harder than it needs to be. It becomes even harder if you start with an error condition. Looking for the Roman numeral equivalent of a null did not help us move the code in the right direction. Handle the happy path first, to get the code designed for its utility, and then add the error conditions that make sense. We quickly decided it made more sense to use an integer parameter, which couldn’t be null, anyway. Beyond that, ordering the test cases in numerical sequence of the calling parameter will ask you to take some bigger steps than is necessary. Bigger steps provide bigger windows for errors, and reduce your flow. In the Roman Numeral kata, starting with inputs 1, 2, and 3 is OK. For 1, the simplest path to a green bar is to “return 1.” The 2 case begs for an “if” statement. The 3 strongly suggests refactoring to avoid a long list of “if” statements. So far, so good. The 4 case, however, takes a big leap. It introduces a new output symbol, “V,” and a new concept, out-of-order symbols to represent subtraction. That’s a lot to do all at once. We skipped that for a moment, and did 5 and 6, first. The case of 6 develops the need to consume one character and then work on the next. Then we went back to 4. I think that was premature. We ha…