Dependencies and planning of engagement with key stakeholders in scrum
Hi Forum, I have been recently running a programme of work with multiple applications where dependencies with external departments in multiple locations have played a key role. Considering the fast paced nature of the sprints and the short term planning a the core of the scrum philosophy, the team has been derailed and blocked a lot of times, as obviously formal engagement is required in big organisations.
The product backlog was just a backlog, what was missing was an overview and planning of dependencies and organisational steps needed to kick off the of necessary engagements in a timely way. How can the focus of scrum on short term be reconciled with the necessity of forward planning in a high complex environment?
Would be great to have some feed-back.
Did the team leave Sprint Planning believing that they could accomplish the Sprint Goal using the Sprint Backlog they had forecast? Did they believe they had all of the skills and resources needed to create a "Done" increment of release quality, and that they had no unresolved dependencies?
The team was skeptical. But when the customer pushes to kickoff activities on a short notice (a few days before the next sprint) as you are meant to be agile what are you supposed to do? My question is: how do you drive and communicate these dependencies in such a way, that you are not perceived as being "waterfall". Regardless of the methodology, if you cannot make sure that the engagement process is done well before (sometimes weeks in advance) the beginning of sprint execution you are going to be derailed. How do you investigate dependencies in SCRUM? With a spike (see Wikipedia)? which is the recommended scrum approach?
I'd agree at what Ian was hinting at. The team can say whether or not they'll be successful towards the Sprint Goal. If they can't, that'll at least indicate an issue to be looked into. A whole bunch of "why's" later, your team may have a plan for resolution.
If you want to avoid finding that out in planning, try a refinement session.
The team was skeptical. But when the customer pushes to kickoff activities on a short notice (a few days before the next sprint) as you are meant to be agile what are you supposed to do?
Commit only to goals you honestly believe are achievable. Have a cross-functional team, with minimal dependencies, which can focus on things just one Sprint at a time. Insist on respect, and assert that no party should be pressured into doing things which are unrealistic. Be open about what is in truth realistic, and about what is not. Have the courage to stand your ground on these things and, if necessary, to say no.
Thanks Ian, Mark. Standing your ground is always good. Ideally it would be better to have a method to avoid these discussions in the first place. Both standing your ground and refinement session are good measures to handle this type of issues