0 Comments
A couple of years back I was engaged on a project to help recover an agile project run amok. The project was one of the first in the organization to use an agile development methodology and consisted of eight four-week sprints with six capability development teams. The project manager was a very theoretical scrum master who was more concerned with having an agile "design win" than he was with ensuring the business sponsor was satisfied with the project result. After about the third sprint there were significant issues with capabilities not working together, interfaces with external systems breaking, and problems with meeting sprint dates for committed capabilities. To save the project, we had to take a number of steps that violated the purist agile model but were necessary if we were going to keep moving forward on the project. Our implementation looked like a mishmash of agile and waterfall. It wasn't pretty, but we eventually got the project done.
The Scenario: The project manager is providing a weekly status report to the project sponsor
The Message: It's good to provide early warning to potential issues, but it’s bad when you don’t provide the next steps you're taking or what help you need. This labels you as a messenger rather than the manager you’re expected to be. The Consequence: Issues without next actions or asks gives the impression you're not taking ownership of the issue and you're expecting someone else to manage through it. The Take-Away: Don't be an issue messenger. Define the issue, articulate what next steps are, and be clear on what and when you expect others to do to help squash the issue. |
Topics
All
Reprints
Contact Lonnie about article reprints. Please specify article you wish to reprint. Backlist
See Lonnie's Amazon Author Page Archives
September 2024
|
RSS Feed