I’m a huge fan of team-based collaboration to complete small stories through the architecture. (The image above shows three small stories implemented through the architecture.) More collaboration means lower WIP (Work in Progress). That lower WIP allows the team to increase their throughput (finished features) and lower cycle time (release something useful faster). (See how […]
Do you feel as if you are always behind on your project? That someone—or several someones—started before you or your team started this project? It’s not your imagination. They did. At the very least, a product leader or someone on the portfolio team said, “If we created a project to do A thing for B
When I started working on projects, we thought we could use a serial/waterfall approach to project management and product development. While we were wrong, one very good thing happened in the 1970s and 1980s: We took the time at the end of each phase to do a little retrospective. Yes, even for a serial approach,
In my work with project and program managers (see all the various titles below), I always recommend they clarify their project or program boundaries: drivers, constraints, and floats when they start the effort. But in a recent coaching call, I realized there’s another question I use a lot, especially with sponsors: When do you want
In a recent conversation, I realized that very smart and experienced project managers do not always know the difference between activity-based plans and deliverable-based plans. While activities might result in an interim or internal deliverable, activities do not result in a user-focused deliverable. The team might make some progress, but not progress users can see.
When I wrote Manage It! Your Guide to Modern, Pragmatic Project Management, I included this chart, the Iterations Content Chart as part of a possible dashboard. I created that chart to clarify the challenges a specific team faced. They had problems with multitasking and the inevitable changes. The first way to use an iteration contents
Are you trying to use story points for estimation? If so, you might have encountered these problems: Story points reflect the ideal thinking of the team, not the actual experience of the team. Your managers don’t want story points—they want durations and dates. In the absence of sufficient information, everyone makes up fiction (human stories)
I see many teams and team members who say, “Agile stinks. It’s a way to force me to work too fast and not finish anything.” When I ask people what’s happening, they say: We’re doing an agile death march because someone else already told us what we have to do and the date it’s due.
How do you know when you finished a feature? You might have a checklist, to make sure multiple people looked at all the artifacts, and that everything is checked in. (This is easier if you work as a mob/ensemble, pair, or swarm.) In addition, a product leader might approve the feature. Finally, the team, a
I’ve been talking with a very sharp leader about how that person uses the ideas of risk and technical debt. I’m paraphrasing, but the leader said something like this: “We realize we need to incur some technical debt. So we explain that we choose to include the debt as part of our risk mitigation. That’s