I have finished integrating comments from the early review of Agile and Lean Program Management: Scaling Collaboration Across the Organization. I decided that the book was good enough to release to the general public. I find it difficult to release books in progress. The in-progress part challenges my perfection rules. However, since this is an […]
A client asked me to do an assessment. He wasn’t sure agile was working for their teams. The standup meetings felt like micromanagement. People were on several projects, so they didn’t meet their commitments. The project manager had to translate the project’s progress and status to Gantt charts. Worst of all, people went through the
If you are not on my Pragmatic Manager email list, you might not know about these opportunities to explore several topics with me this month: An Estimation hangout with Marcus Blankenship this Friday, April 10, 2:30pm EDT. If you have questions, please email me or Marcus. See the Do You Have Questions About Estimation post. Think
Update: I titled it Predicting the Unpredictable. I have finished the content for Essays on Estimation. But, I need a new title. The book is more than loosely coupled essays. It reads like a real book, with progression and everything. I have a number of ideas. They are (in no particular order): Predicting the Unpredictable:
I had dinner with a colleague. While we were settling into our coffee, he asked me, “What does post-agile mean to you?” I was no longer calm and relaxed. “That’s a nonsense word. Post-agile!” Here’s why I reacted the way I did. We have known about miniature milestones, or inch-pebbles, since the 1940s. That’s how
I run into clients who believe they are applying agile project management. Yet they are seeing little benefit. Why? Typically these folks try to apply agile while still using a fixed mindset. In this article, I’ll give you core practices and tips for reaping the benefits of agile. Fixed vs. Growth Mindset In agile, we
For years, we bought the cone of uncertainty for estimation—that is, our estimates were just as likely to be over as under. Laurent Bossavit, in The Leprechauns of Software Engineering, shows us how that assumption is wrong. (It was an assumption that some people, including me, assumed was real.) This is a Gaussian (normal) distribution.
Many organizations create teams by their architectural part: front end, back end, middleware. That may have worked back in the waterfall days. It doesn’t work well when you want to implement by feature. (For better images, see Managing the Stream of Features in an Agile Program.) Pierce Wetter wrote this great article on LinkedIn, There is
I’m writing part of the program management book, talking about how you need to keep everything small to maintain momentum. Sometimes, to keep your work small, teams move from iterations to flow. Here are times when you might consider moving from iteration to flow: The Product Owner wants to change the order of features in
In self-organizing teams, teams remove their own obstacles. It’s a good idea. It can be difficult in practice. In Scrum, the Scrum Master is supposed to facilitate removing the team’s obstacles that the team can’t remove. It’s a good idea. It can be difficult in practice. And, what if you aren’t doing Scrum, or you’re