I encourage my clients to find and focus on the core value of whatever they’re creating. What is it that doesn’t yet exist in the world but should? Go there first. Don’t defer that value. “But we need to create the infrastructure for that first, don’t we?” they often reply, by which they mean things like hardware, foundational technology layers, architecture, capabilities like user management, etc. Read More
Change on software projects is expensive; it leads to wasteful rework. Change is risk. We can deal with risk one of two ways. We can reduce the likelihood of the negative event occurring. Or we can reduce the impact of the negative event when it does occur. (Of course, the two can often be combined.) The traditional approach says, "Let's put more effort and thought in up-front and avoid that expensive change." (That is, let's prevent the negative event from occurring.) The problem, as decades of experience have shown, is we still can't seem to avoid change. Here's why: the kinds of change that plague software development can't be eliminated by thinking harder up front. Read More
Atul Gawande is a surgeon and author who has written some excellent books and New Yorker articles reflecting on the state of modern medicine. Recently, his writing has gone beyond medicine in interesting ways. As he looks for lessons for medicine from other disciplines, he ends up with things to teach both medical professionals and skilled knowledge workers more generally. His book The Checklist Manifesto manages to be a riveting 224 pages on what ought to be one of the least interesting topics possible: the checklist. So I was intrigued to see a link to a New Yorker article from Dr. Gawande on my own specialty, coaching. It's as good as I might have hoped. Read More
Effective agile teams get things done. They build software day after day that's not just "code complete" but really shippable. And when their product owner says, "ship it," they can get their shippable software into production at the drop of a hat. The Definition of Done can be a powerful tool to make these things happen...If it's used right. Most agile teams I see have one of four relationships with a Definition of Done: They don't have one They have one but don't really use it They have one but can never satisfy it They have one, satisfy it for each story, but still have lots to do at the end of a release I rarely come across teams who use the Definition of Done to good effect day after day, sprint after sprint. Find out why and how to fix it »