7

I'm the new Scrum Master of a Team that develops a software for a customer outside our company. This is my first time working as Scrum Master; I have no background in this field. Our company is just a small software development contractor and our customer is a big multi-national corporation. We rely heavily on them in that a big portion of our projects are done for this customer.

Our customer however doesn't really care that we're doing Scrum. They don't seem to have any product vision and constantly change their opinion about what they want next. That in and of itself shouldn't be a problem (the PO should have the vision and that the customer can't make their mind up is the whole point of agile); however it's happening to such a degree that our PO has no chance of creating a Product Backlog. Most of the things we work on are unknown until the day the Sprint Planning takes place. During Sprints we are constantly pushed to change the scope of the current Sprint (i.e. add more things).

This has the following effect on our Team:

  • We have no Product Backlog.
  • We never have a Sprint Goal, Sprints are just a combination of unrelated features/ change requests/ bug fixes.
  • There are things added to our Sprint Backlog during the Sprint.

And all this leads to us never getting anything done.

My understanding is that those problems come from the fact that our Product Owner lacks the authority to say "no" to our customer. I understand that following Scrum-Theory I as Scrum Master should refuse both the constant change of sprint-scope and the working on features which are completely unknown until the Sprint Planning. However there's no point in saying "no" to the PO: it's not him who wants to do those things anyway. He knows what the effect on our team is, but he's forced to do it.

Are there any ways to improve this situation?

Improve this question

5 Answers 5

Reset to default
8

You have a couple different options here and I think it starts with Karthick's suggestion. You definitely need to:

Facilitate a discussion with all stakeholders and work to better understand what the vision and direction is for the project as well as to set meaningful expectations for all parties.

If the PO lacks authority, spend time during that discussion and explain the PO role and the values that make them so effective, e.g., being empowered and decisive.

If stakeholders are just looking to submit whatever they want to the team to work on, suggest that they form a committee (which the PO should be on) to manage and deliberate on inputs and which are then approved by the PO for development work. I've personally seen this be successful on large enterprise projects.

If the work keeps changing day to day and you want to stick to Scrum, force that committee to chose which work to take out of the sprint. E.g., if you put something in you need to take something out- this will occur often at first, but over time you are re-educating the business on how to treat software development; be very strict about this and allow no exceptions. Good scrum masters are assertive, deliberate, and tactful.

Provide reports and metrics back to this committee on how their change process is affecting the product, provide empirical data to back up why the existing process needs to change - demonstrate progress over time by continually presenting this information back to that group.

If you are completely in an operations and maintenance phase (as it kind of sounds), consider Kanban as an additional option. E.g. focus on completely finishing a single item at a time, measure those lead times, and report back to the business side as your team improves. This allows for flexible backlogs and also the ability to forecast when a work item, on average, will be completed.

Improve this answer
4
  • The problem with facilitating a discussion with all stakeholders is that I can't do that. Some of the stakeholders are members of different layers of management of the customer cooperation who I simply can't request to talk to (again, we are a small contractor, they are a multi-national cooperation). We have a team of people who are our contacts. Those appear to be sometimes heavily influenced by their managers which forces them to either suddenly reprioritize or even add things to running sprints.
    – user2431655
    Commented Feb 2, 2015 at 12:03
  • If you have limited/no access to their stakeholders, reach them in a different way. Focus on reeducating those that you can talk to and work with. Be very strict with your sprints, again, if they want to put something in, physically sit in a webex session and force them to take something out and explain that the item taken out can be evaluated for the next sprint.
    – Jon Luzader
    Commented Feb 2, 2015 at 16:48
  • Below in another comment, you mentioned not knowing the product vision, to me this raises a flag. It means you have no goals to compare incoming work with. As a recommendation, I would suggest working with your customers to define a Product Vision Statement (on mobile right now I'll link later), its a highly visible, living document that describes the purpose of your system and what it is going to be, etc. These things I think will better help you control change and re prioritization on your project admist limited stakeholder access.
    – Jon Luzader
    Commented Feb 2, 2015 at 16:48
  • 1
    Remember, Agile's #1 competitive advantage is its ability to react and respond to change, you just need a few more things in place to control it.
    – Jon Luzader
    Commented Feb 2, 2015 at 16:50
5

Since you are dealing with an external customer, who does not follow and presumably understand the problem, that is where you need to start. Talk to the customer. Call the stakeholders for a call along with the PO. Explain the churn on the team. Help them understand the solution (Scrum) and how it would be beneficial for them too.

Read the book Agile Development with Scrum. You will find many useful points in this book.

Improve this answer
1
  • This. Coaching is a key part of the Scrum Master role, and this is how we change behaviours of those who interact with the team to benefit everyone.
    – Toby Speight
    Commented May 19, 2022 at 15:44
1

If you can have a face to face with your Product Owner. Talk about the risks that she is introducing by not saying 'no'. For example, reduced product quality, burn out, and team demotivation. You can also tell her that Scrum may help her reducing these risks. While you are doing this, you can also learn about her motive, and figure out why is it difficult for her to say 'no'.

With this approach you can start a discussion with all cards on the deck: she'll now your motivation and you'll know hers.

I won't go to the customer until you have this talk. Imagine how would you feel, if your team members would go to the PO instead of you, when they have a problem with the way you do your job. Moreover, the customer may not be interested in the way you work and may also prefer to talk to a PO than to the team (although in Scrum it can work).

Improve this answer
3
  • "Moreover, the customer may not be interested in the way you work" What would you do if that actually was the case? (I don't know that for sure but I highly suspect it.)
    – user2431655
    Commented Feb 2, 2015 at 10:21
  • I'd still talk to the PO first and when nothing changes in a couple of days I'd go and talk to the customer and the PO's boss. It is my personal belief; I won't step over somebody without talking to him/her before regardless of the stakes.
    – Zsolt
    Commented Feb 3, 2015 at 9:19
  • It is also possible that the customer is injecting new requirements "on the fly" because of a lack of a requirements-planning process that directly involves them. They are "swatting at" the situation instead of planning it.
    – Mike Robinson
    Commented Jun 8, 2022 at 17:30
0

I just can agree with the answers before to get in touch with the customer. In additional thing you should do in this conversation is to figure out if the customer is happy with the progress and fix the problems the customer is stating with Scrum practices. Most oft the time I get problems from the customer like planability. And then it is easier to connect their problems with solutions Mike an empowered PO and stabile requirements matching a vision.

Improve this answer
0

If you can establish metrics, get these accepted by the customer, and report these to your PO and to your customer, this is probably the most efficient mean to get a change in their behavior.

Can you evaluate the amount of work (in point, or even better in $) that is not under control or wasted because of this constant change ?

Improve this answer
2
  • I can determine the amount of story points that we failed to deliver every sprint. However I can't really link it to unplanned Stories since we don’t estimate those. I can determine the $ that unplanned features cost. However I have no idea about the value of features that we failed to deliver. Since I don’t know a vision I can’t make any statement whether those unplanned features endanger a release goal either.
    – user2431655
    Commented Feb 2, 2015 at 10:19
  • @user2431655: You should be able to estimate how much work got wasted because a story was abandoned without finishing it.
    – Bart van Ingen Schenau
    Commented Feb 2, 2015 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.