SLA based delivery model under Agile-Scrum framework
Management has signed a five year contract without understanding/defining the scope of work (Sales team did that). Among many key terms, the disturbing part is, at the end of the sprint if you are not delivering all committed user stories (meeting stringent acceptance criterion and DONE at sprint level) you wouldn't get paid. It's AON condition (all or none). Team is in forming/norming stage, well trained in scrum framework, collaboration is distant milestone, using open source technology to build this enterprise level product. Scrum master has to sign the official contract at begininng of the sprint (highly contextual) and knows his job very well. The PO is non-negotiable and highly demanding (from client side). We are using 3 weeks sprint. Since the product is new, estimation process will take some time to reach maturity level. Due to high unknown unknown we were not able meet 2 sprints commitments and obviously penalized. Keeping aside the theoritical suggestions like (toxic environment, educate the client and sales team, coach the PO, find new job, use waterfall etc. ) do you have any practical solution how we can address this problem? Since this knowledge work absolute estimation and meeting that estimation is impossible. Hence we are struggling to meet our own sprint level commitment be it due to high severity bug or lack understanding of domain/application. I know there is no silver bullet solution for this but any alternate thought would be highly appreciated. In a word I can't let go $10M contract.
Hence we are struggling to meet our own sprint level commitment
I'm not sure what the team's "own" sprint level commitment actually amounts to in this case, or what evidence they have used to make a commitment at all. From what you describe, it sounds like others are trying to make some sort of commitment for them. Can you clarify this matter?
Hello Ian,
Thanks for your time. Here is more insight. Since the team is new (working together for last 3 months) their understanding about the product is evolving. PO is trying to dictate the terms. He is trying to set 75 user story points (didn't disclose how he is setting that expectation) to be delivered every sprint (he shouldn't but that's reality) and after very intense negotiation team is committing to deliver 40 story points (internally we calculated it at around 50 story points, used voting method). But for last two sprints they actually delivered 30 story points. Inspect and adapt is not in scope. PO is saying I'm investing XYZ dollar per sprint and I want ABC amount of work at end of sprint with quality. I feel they have adopted wrong methodology/framewrok to deliver the project but that doesn't make any difference here. There must be some win-win formula, that I'm trying to figure out here.
PO is saying I'm investing XYZ dollar per sprint and I want ABC amount of work at end of sprint with quality.
He will get at least a certain amount of work, as presumably the Development Team are expected to work so many hours per week, and there are probably mechanisms in place to ensure they do that (at least if they want to get paid).
Shouldn't the Product Owner be more concerned with what is achieved, than how hard people are working?
There must be some win-win formula, that I'm trying to figure out here.
That depends a lot on the people involved. Scrum requires a different way of thinking, respect for the change of roles and responsibilities, and ultimately it relies on behaviour.
How do people expect Scrum to solve their problems if they continue to behave in ways that more traditional management techniques have encouraged?
Hi Simon,
I'm with you. Specific to this context, there is no front end work. All midleware integration and DB work. Hence, at end of sprint there is no scope of showing something it's all or none (integrated work).
Again, I personally believe, the decision makers should attend/complete the mandatory training to understand & accept what org/cultural change is required from their side in order to reap benefits.
The way Agile manifesto was presented ,for some people, offered a one size fit all solution. They need to clearly define the prerequisites to get there.
Let's see how we can manage this challenge. I'll share my experience down the line.
Thanks
If (and only if!) nothing else works, you could try shock therapy. In a sprint planning, commit to one (1) small PBI and deliver just that. If you are done in the first half of the sprint, do nothing for the rest of the sprint.
This is a drastic way of showing the effect of the behaviour of the client. It is a distructive way to address this, but then again so is the approach the client and their PO are using.
Hi,
Tricky situation few things that I can think of
1.) I would introduce Definition of ready for the PBI if the team thinks the items are big and ambiguous , introduce thorough US refinement . This can be sold to client as improvement of the delivery items in sprint .
2.) Try going Kanban - no cadence , that would alleviate scrum time box. PO gets to see and part of team progress.
3.) Look at team see if there are any leverage points , assuming you have experienced team members who can stand to rigour of delivery and stand up to PO.
Good luck.
Abhinav