A colleague was looking for a way to move toward agile but not really transition all the way. “I don’t think we’re ready for two- or three-week iterations,” he said. “We want to move a little more slowly than that. But, we do want to do something more agile than waterfall. And, we want to […]
I often receive emails from readers asking questions such as “We have ten developers and two testers. How do we compare to our industry?”; “We have six-week iterations and a two-month hardening iteration at the end of our release. How agile are we?”; “We finish twelve stories in a four-week iteration. How many stories do
A great way to destroy a program is to avoid writing a charter. When I do assessments or work with teams, I often find that programs do not have charters, or that the charter is too big, or is missing some key piece of information. But what do you really need in a charter? Too
Last night, the New England Society of Applied Spectroscopy had an evening of remembrances for Raúl Curbelo. Raúl was a pioneer in the development of spectroscopic instrumentation. I worked for Raúl at Digilab from 1978-1982. I spoke last night. Here is an excerpt of my comments: I can’t speak to the breakthroughs Raúl developed in
On the bike at the gym this morning, I thought about increasing my level. When I exercise, more friction is good. But when you develop or use products, more friction is bad. Brian Marick talks about this when he speaks and writes about “ease” for development teams. If you’ve encountered a web page that made
My column on Stickyminds is up: Measure Throughput, Not Utilization. Enjoy!
Some teams don’t do demos at the end of their iterations. Many of the teams who don’t do demos also have trouble finishing all the stories they committed to at the beginning of the iteration. They continue, iteration to iteration, not always finishing, not getting to releaseable at the end of the iteration. And, sometimes,
Who’s in Charge of Quality? At the Agile 2010 conference a couple of weeks ago, I heard many people say, “When QA gets the software, …” In an agile project, that makes no sense to me, unless the team has not developed its own definition of done. In more traditional projects, the people in the
Last week at Agile 2010, Joshua Kerievsky and I facilitated an Open Jam session (open space) about what done means. We discussed a variety of points. I believe we eventually agreed that context matters. It’s important to know what your product success criteria are. If you don’t use a project charter where you define success
Josh Kerievsky has an intriguing post about . The idea is that a story is not done until: A story isn’t done until it is being used by real users in production and has been validated to be a useful part of a product. I have trouble with this definition: The development team is dependent