Skip to main content

SLA based delivery model under Agile-Scrum framework

Last post 05:42 pm April 23, 2019 by Abhinav Mathur
6 replies
07:10 am April 20, 2019

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.


01:48 pm April 22, 2019

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?


04:00 pm April 22, 2019

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.

 


06:08 am April 23, 2019

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?


01:14 pm April 23, 2019

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


02:49 pm April 23, 2019

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.

 


05:07 pm April 23, 2019

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.