Getting the skinny…have a sprint retrospective.
One of the things I've enjoyed about working in an agile, open source environment, is the collaborative approach to tackling problems. This same philosophy applies to project wrap up. Most people don’t like to talk about what went wrong during a sprint. By addressing failures and weaknesses that became apparent during the sprint, is a valuable opportunity to understand how you can be a better performing team.
Ideally, project managers want to hold a sprint retrospective the last day of (or soon after) the sprint, while ideas are still fresh on the team’s mind.
It's not just a time to look at what went wrong, but also recognize what went well during the release and how you want to change things moving forward. Additionally, as a project manager, I really see the value in taking the time to present the numbers (for example, actual versus estimated hours) during a retrospective. This helps your team build a more realistic understanding of project effort, and may prove to be insightful the next time a client asks, “How long will it take to build that new feature?”.
Additionally, identifying workflow processes can improve the team's effectiveness. Coming up with ideas for change is easy -- implementing them in the process is the harder part. But just like agile, it's an iterative process and may take several refinements to get it right. Be sure to communicate the changes that may impact your team and client to discuss how they will be beneficial to the project.
By documenting best practices that emerge from the sprint retrospective, the knowledge gained can be posted during future sprints so the team can refer to them and ensure they avoid falling into the same trap.
Comments
Post new comment