Measure Throughput, Not Utilization
My column on Stickyminds is up: Measure Throughput, Not Utilization. Enjoy!
My column on Stickyminds is up: Measure Throughput, Not Utilization. Enjoy!
I’ve been working with and discussing agile program management with a bunch of people. One of the big issues is: what do we call certain people at the program level? We need a program manager, someone who sets/explains the program’s vision, develops program-wide release criteria with sponsors, has a way to articulate program status, someone
I’ve been working with several clients on their transition to agile. Yes, the technical staff needs training. Yes, they often need coaching on how to choose small chunks, estimate and commit to an iteration’s worth of work, and then to deliver that work. And, I am beginning to think the biggest problem in transition is
I’ve been working on agile program management and a colleague emailed me about his program. He’s having trouble seeing how to do agile on a large program. The customer wants to see a working system before they add the features, so the customer thinks the program need to provide “all” the architecture, with some hard-coded
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,
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
I’ve been working with Rebecca Wirfs-Brock on an agile architecture workshop. I’m working with Rebecca because she has such a depth of experience in architecture, as well as design. She’s working with me because of my project and program management experience. We’re pretty psyched. We’re working through the issues of large programs and architecture, and,
I’ve been working with organizations who want to move their programs to agile. They’ve been successful with small projects. But now, they want to make agile work with large programs, programs that involve hardware or firmware, programs with many pieces of interdependent software features, programs of 50 to 300 (or more!) people. Now, you might
I often meet people who are transitioning to agile, and they decided to pick Scrum, because it’s a helpful project management framework. Ok, that makes sense. But then they decide that they no longer need project managers, and that the development manager can act as the Scrum Master. The Scrum Master is not a management