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 have a column up on Stickyminds, Six Behaviors to Consider for an Agile Team. Please do leave comments there.
I hear this story again and again. A hiring manager can’t find the right candidate. Why? You would think it would be easier to find great candidates, because so many people are out of work or are looking for better jobs. But that’s exactly why it’s so hard for hiring managers to find people–there are
I learned this week that I made the Top Women in Business Blogging list. They tell me my readers nominated me. Dear readers, thank you!
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 received a call from a recruiter-colleague yesterday, bemoaning a hiring manager who was waiting for the “perfect” candidate. “I’ve sent her 5 great candidates, but none of them are perfect. Doesn’t she have to fill this position?” Well, maybe not right away. And, maybe it’s not just technical skills that make a candidate a
I’m proud and pleased to be on the list of LiquidPlanner’s Top Project Management Thinkers. I’m thrilled, too!
It’s a good thing I said my post about musings was just that–musings! I didn’t bring all of you along. Sorry about that. Let me be more clear. A program is a collection of projects, where the value is in the overall deliverable. Yes, each project may have a deliverable that’s valuable, but the value
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