When managing a project scrum I stick to a few things that have worked well for me.
- Make it clear that the name "sprint" is a bad one. This is marathon. Encourage maintaining a steady pace and do not become a party to burn-out.
- Use Agile pointing methodology by the book.
- Standups are for communicating wins and blockers; your overall general status is not useful to the rest of the team and makes the standup go long. Project chit-chat, problem-solving, and talking about wins, is for afterwords or completely different meetings.
- Defend the team from management's attempt to deconstruct points into hours, days, or any other more conventional metric; Agile exists to neuter these anti-patterns, and the points exist only to figure out what gets done in a "sprint" interval. Offer velocity tracking and focus on results instead.
- Defend the plan and the team from all stakeholder asks, and make it clear that adding to an existing plan also means taking other tasks away.
- Carefully triage emergencies, bugs, into the plan with stakeholder consent and involvement.
- In fact, everything for Scrum is just triage, including features. Mark everything with a relative priority, even the normal things.
- Celebrate every single last win, no matter how small. There are no victory ceremonies in the standard Agile Scrum playbook; this is on project leadership to address and absolutely must be done without fail.
If done well, the project says on a relatively even keel for the duration. Using Agile for evil, by instilling a false sense of urgency every two weeks, will burn your team out faster than any Waterfall crunch ever could.
Here's where people get this all screwed up: Agile methodology requires constant communication between the team and stakeholders, leaving the PM/Lead to play goalie for the project's run. That leader must be comfortable saying "no" to anyone/everyone, manage stakeholder expectations at regular intervals, and must have a keen sense of how to break down a project's deliverables into achievable increments. In short: this person must be both technically and socially adept.
If that doesn't sound like your lead or organization, Waterfall may be a better move. It pushes a lot of this communication and negotiation to the planning phase, before any engineering work is done. In the case of contracting, it also escalates project change to a legal process, which can blunt/halt the influence of meddlesome forces. It's also possible to avoid big crunches and burnout, if (and only if) your project management has a clue and is dogged about milestone due dates. Overall, it pushes the bigger social aspects to a preparatory phase which can be executed by different personnel than the team that implements the product.
- Make it clear that the name "sprint" is a bad one. This is marathon. Encourage maintaining a steady pace and do not become a party to burn-out.
- Use Agile pointing methodology by the book.
- Standups are for communicating wins and blockers; your overall general status is not useful to the rest of the team and makes the standup go long. Project chit-chat, problem-solving, and talking about wins, is for afterwords or completely different meetings.
- Defend the team from management's attempt to deconstruct points into hours, days, or any other more conventional metric; Agile exists to neuter these anti-patterns, and the points exist only to figure out what gets done in a "sprint" interval. Offer velocity tracking and focus on results instead.
- Defend the plan and the team from all stakeholder asks, and make it clear that adding to an existing plan also means taking other tasks away.
- Carefully triage emergencies, bugs, into the plan with stakeholder consent and involvement.
- In fact, everything for Scrum is just triage, including features. Mark everything with a relative priority, even the normal things.
- Celebrate every single last win, no matter how small. There are no victory ceremonies in the standard Agile Scrum playbook; this is on project leadership to address and absolutely must be done without fail.
If done well, the project says on a relatively even keel for the duration. Using Agile for evil, by instilling a false sense of urgency every two weeks, will burn your team out faster than any Waterfall crunch ever could.
Here's where people get this all screwed up: Agile methodology requires constant communication between the team and stakeholders, leaving the PM/Lead to play goalie for the project's run. That leader must be comfortable saying "no" to anyone/everyone, manage stakeholder expectations at regular intervals, and must have a keen sense of how to break down a project's deliverables into achievable increments. In short: this person must be both technically and socially adept.
If that doesn't sound like your lead or organization, Waterfall may be a better move. It pushes a lot of this communication and negotiation to the planning phase, before any engineering work is done. In the case of contracting, it also escalates project change to a legal process, which can blunt/halt the influence of meddlesome forces. It's also possible to avoid big crunches and burnout, if (and only if) your project management has a clue and is dogged about milestone due dates. Overall, it pushes the bigger social aspects to a preparatory phase which can be executed by different personnel than the team that implements the product.