You may have noticed I haven’t been writing much on my blog. That’s because I’ve been writing a book, instead.
I’ve self-published before, both solo and with co-authors. This is my first professionally edited book, though.
It’s been a lot of work, but my editor, Adaobi Obi Tulton, has helped me create a much better book than I would have created by myself.
Take a stroll over to Pragmatic Bookshelf where you can buy it. And after you read it, I’d love to hear what you think.
A friend asked for suggestions on a metric for backlog grooming. I’ve never written down these numbers, but this is the metric I use in my head.
Agile 2018 has come to an end. Once again, virtually all of my time was spent in the Audacious Salon, where I was a track chair. Once again, it was an immersive and powerful experience for me.
It’s time, perhaps past time, for me to describe the salon to the world. To describe how it came to be, the intent, the evolution, and the magic I’ve seen flourish.
This description is, of course, the viewpoint of one man. Undoubtedly I’m biased. Understandably, others will have different viewpoints based on different hopes and wishes, different experiences, and different knowledge. I invite you to share these differences in the comments, even if your viewpoint seems negative toward the concept. Perhaps particularly if you have some complaint, doubt, or fear about the Salon. I, or we, can learn most from a diversity of opinion from diverse people. Read More
When I first met Andreas Schliep, he told me a consulting war story with the punch line, “Well, you can paint that wall with a screwdriver if you like”¦” There’s no stopping people who are intent to use the wrong tool for a job, or use it in the wrong way. Sometimes it even works. I’ve seen someone successfully, after a fashion, driving wood screws with a hammer. Read More
On numerous occasions I’ve observed long-time members of the Agile community complain about misinterpretations of what Agile means, and how it performed. Frequently this is precipitated by yet another blog post about how terrible Agile is, and how it damaged the life of the blogger. Sometimes it’s triggered by a new pronouncement of THE way to practice Agile software development, often in ways that are hardly recognizable as Agile. Or THE way to practice software development is declared post-Agile as if Agile is now obsolete and ready to be tossed in the trash bin. Read More
The simplest method of estimation is to compare the anticipated work to past experience. And we all have experience that we can use. The big question is how relevant is that experience. A secondary question is how clearly do we remember that experience.
We always have experience, of course. We weren’t born developing systems. We’ve tried things, and learned things, from childhood onwards along a path that’s lead us to today’s situation. In all the things we’ve done, there’s something that we can compare with the work we’re facing. Read More
Even when you’ve done something many times before, sometimes you forget something or make a mistake.
This morning I was on my way to visit a client and realized I’d forgotten something. It seemed to me important enough to do something about it, so I went back home and got it. The unanticipated delay threw my schedule into disarray. I wasn’t going to arrive by the time I wanted. I was frustrated and unhappy with myself.
I see similar things happen all the time in software development projects. Something throws off the schedule. People get unhappy. Read More
“I need this project done by date D and within cost budget C. Now calculate an estimate on the project.”
A friend of mine used this example to illustrate anchoring bias in estimation. Note, however, that he doesn’t make the question explicit. Further conversation revealed that he had in mind that the date and cost should be the output of the estimation. With that assumption, that statement preceding the request will definitely anchor the answer, and realizing that this bias is likely will call into question whatever estimate is given.
Given the stated need, however, I would reframe the call for an estimate from “When will this project be done and how much will it cost” to “What is the likelihood that the project can be done within these constraints?” Read More
Sometimes we intentionally make our work more visible so that we can more easily see what’s going on. We do this so that, as a group, we get a better picture of the whole of the group’s effort. At it’s best, this is more than a dashboard that displays information. Instead, it’s a tool that’s used by the people doing the work in the process of doing that work. Read More
Ryan Ripley has posted the second Agile for Humans podcast where he, Amitai Schlair, and I discuss the life of a consultant, how to make retrospectives valuable, and the place of managers in an Agile organization.