Author: George Dinwiddie

George Dinwiddie is a Software Development Consultant and Coach with over twenty years of experience creating software ranging from small embedded systems to corporate enterprise systems. With a strong interest in lifelong learning, he has pursued more effective ways of creating software at the technical, interpersonal and organizational levels. As principal of iDIA Computing, LLC, he helps teams learn more effective software development techniques while accomplishing their current projects.

Relationship of Cycle Time and Velocity

I sometimes see clashes between Kanban proponents and their Scrum counterparts. Despite the disagreements, both of these approaches tend toward the same goals and use many similar techniques. Karl Scotland and I did some root cause analysis of practices a few years back and came to the conclusion that there were a lot of similarities between Kanban and Scrum [as the poster-child of iterative agile] when viewed through that lens. I also noticed that while Scrum explicitly focuses on iterations as a control mechanism, Scrum teams tend get into trouble when they ignore Work In Progress (WIP). Conversely, while Kanban explicitly focuses on WIP, Kanban teams tend to get into trouble when they ignore Cadence.

A twitter conversation I was in revolved around Cycle Time and Velocity. Since this is a topic that’s come up before, I thought it would be valuable to describe it more fully. Again, I find there to be more similarities than differences between Kanban (which uses Cycle Time) and Scrum (which uses Velocity) in terms of predicting when a given amount of work will be done, or how much work will be done by a given time. Read More

16 Comments

Categories: Tools and Techniques

Tags: ,

Another Approach to the Diamond Kata

I saw that Alistair Cockburn had written a post about Seb Rose’s post on the Diamond Kata. I only read the beginning of both of those because I recognized the problem that Seb described with the “Gorilla” approach that, upon reaching the ‘C’ case.

“The code is now screaming for us to refactor it, but to keep all the tests passing most people try to solve the entire problem at once. That’s hard, because we’ll need to cope with multiple lines, varying indentation, and repeated characters with a varying number of spaces between them.”

I’ve run into such situations before, and it’s always be a clue for me to back up and work in smaller steps. Seb describes that the ‘B’ case, “easy enough to get this to pass by hardcoding the result.” Alistair describes the strategy as “shuffle around a bit” for the ‘B’ case. I’m not sure what “shuffling around a bit” means and I don’t think it would be particularly easy to get both ‘A’ and ‘B’ cases working with constants and not heading down a silly “if (letter == 'A') "¦ elseif (letter == 'B') "¦” implementation. I was curious how I would approach it, and decided to try. (Ron Jeffries also wrote a post on the topic.) I didn’t read any of these three solutions before implementing my own, just so I could see what I would do. Read More

7 Comments

Categories: Tools and Techniques Working Software

Tags: , ,

Another Two Sides to Estimation

There are many ways to look at the issue of estimation. Everyone in the business of software development has had experience with wanting estimates, being asked for estimates, or both. That experience frames how they look at the issue. A considerable share of those experiences have been painful. I dare say that everyone in the business has had some painful experiences around estimation, and the painful ones seem to stick in our memory more vividly than the benign ones.

What makes these experiences so painful? Again, the causes are legion. One frequent contributor is well illustrated by a story my older brother taught me as a child.

Read More

No Comments

Categories: Individuals and Interactions

Tags: ,

The Quality Carousel

I just observed yet another conversation on twitter that started with the topic of waste in software development, brought in value as an arbiter between waste and necessity, and then quality as a modulator of value. Surely a practice that increases quality also increases value, and therefore cannot be considered waste.

These discussions seem to spin in circles. They always have, and likely always will. Why? Because they treat quality and value as attributes of what is built, rather than as relationships. I like Jerry Weinberg’s definition in Quality Software Management:Systems Thinking.

“Quality is value to some person.”

This does not bring agreement to the discussions of value and quality. It does bring a different focus to them. Who is the person that matters? I can tell you who that is. Read More

1 Comment

Categories: Customer Collaboration

Tags: ,

Getting Things Done

No, not the book and personal productivity method by David Allen, though somewhat related in intent. I’m talking about getting things done in software development.

Traditional phased software development processes tend to have a long delay between starting to work on something, and having something working that people can use. During this time, there may be a lot of work expended on partial products and artifacts to support the process, but little or nothing that could be used for its intended purpose.

Both timebox-oriented [e.g. Scrum] and flow-oriented [e.g. Kanban] methods try to emphasize getting things done so that they can be used earlier and provide value. Even if you decide not to use them earlier, at least they can be evaluated for suitability of the intended use, and progress toward a larger collection of functionality that will be deployed for use together can be more reliably tracked.

The strategies for getting things done vary. Read More

2 Comments

Categories: Working Software

Tags: , ,

When Klunky Component APIs Show in the UX

At various times, the behavior of Facebook reveals to me that it’s a loosely coupled system with long latencies in synchronizing its various data stores. Just today, the iOS app asked me to confirm a friend request. When I did so, it gave me a pretty generic error—something about not being able to do this action at this time. That’s when I realized that I’d already accepted that particular friend request, days ago. That tells me that there are often inconsistencies between the database used with one interaction, and the one used with another interaction on another interface.

It also tells me that there are likely teams working on components, rather than features. If it was a feature team, the need for an error message would have driven a different underlying implementation. A feature team would want to differentiate between not being able to accomplish an action because it was already done, and because some problem was blocking it. For the former, there’s no need to show an error at all. Read More

No Comments

Categories: Tools and Techniques Working Software

Tags: ,

Validation and Uncertainty

What an extraordinary conversation I had recently on Twitter. It started with Neil Killick’s statement that we should not consider our stories truly done until validated by actual use. This is a lovely thing, if we can manage it. While I’ve not set such a bold declaration of “done,” I’ve certainly advocated for testing the benefit of what we build in actual use. Deriving user stories from hypothesis of what the users will do, and then measuring actual use against that hypothesis is a very powerful means of producing the right thing—more powerful than any Product Owner or Marketing Manager could otherwise dream up.  Read More

3 Comments

Categories: Customer Collaboration

Setting Expectations

Karl Scotland wrote an excellent blog post on Estimates as Sensors. In it, he extols the use of estimates to “sense capability and create feedback for yourself.” This is similar to my point in Estimation as Hypothesis.

At the end of this post, it now says “I don’t recommend using them to make promises and give guarantees to others.” Originally, this said something like “I don’t recommend using them to make promises and setting expectations of others.” I asked him what he did use for setting expectations. He had two responses. “I’d say expectations are set from understanding our capability, refined through sensing, and with a confidence range.“ and changing the post to reflect his original intent.

There’s more to this business of setting expectations. Read More

No Comments

Categories: Customer Collaboration

Tags:

Short Overview of Estimation

Back in 2008, Bob Payne and I were working with a team learning to practice Agile Software Development. They were doing quite well at a lot of things, but their sprint velocity bounced up and down like a yo-yo. The sawtooth velocity chart indicated, since they were clearly delivering value at a pretty steady pace, that they were not very good at estimating stories. Bob suggested to me that they might do as well, with less effort, by counting the stories instead of estimating them. Read More

9 Comments

Categories: Customer Collaboration Tools and Techniques

Tags: