Tackling the issue of Ad Hoc work requests on the Dev team?

If you are the Product Owner then you are accountable for the ROI of the associated product lines. In other words you are an entrusted party. You determine what constitutes value on behalf of stakeholders, and you have a duty to them to maximize it.

This means that stakeholders...including an MD...cannot tell a PO what to do. If they believe they can, then there is a fundamental misunderstanding regarding the role and function of a Product Owner and Scrum is being improperly applied.

Scrum does allow for canceling a Sprint in case priorities shift drastically, amongst other scenarios.
.
.
.
Sometimes the forums don't capture the entire picture. 2 questions emerge --
A) Is all of the work visible?
B) How long is the duration of your Sprint?
C) Please confirm that there is only 1 Scrum Team? If so, what is the size?

>or should i just accept that for a startup, there will always be chasing of the 'big fish'.

That will always be the case with a startup, but you also don't want to always be in chaos mode, either. Try to allow for big fish, but also not accept every "urgent" feature request that comes in.

Here are some things that might help:
http://ScrumCrazy.com/scope
http://ScrumCrazy.com/bugs
Might be good to track some of these metrics to ensure that your chaos is not killing your product's value:
http://AgileSoftwareTraining.com/for-executives
In particular, monitoring customer sat and usage metrics might help you know if your other customers are being negatively impacted by too much big fish chasing.

Hi David,

Who is the Scrum Master of your team?

At a startup, not only Scrum Team is cross-functional, but whole organization.

I've several experiences similiar to yours.

Excuse me for my poor English as I'm not a native speaker. I try my best to explain what I do.

We raised this issues in Sprint review and Retrospective events of the first Sprint.

IN SPRINT REVIEW, I showed the velocity to MD and hightligted the impact on release date.
IN SPRINT RETROSPECTIVE, we implemeted some improvements to work out these ad hoc issues and negotiated with MD.

1. The team will asign a person to support Ad Hoc work requests every day.
2. The ad hoc support task is time-boxed, Two man hours per day. 11:00 ~ 12:00 and 17:00~18:00
3. All the ad hoc tasks must be listed on a Backlog and ordered by MD.
4. The unlucky guy must be asigned by the Team at Daily Scrum.
5. The asigned team member does her/his best to deal with these extra tasks.
6. It is important to exclude these support hours when calcaulate the TEAM’s capacibility.

MD: 2 hours support may be not enough.
ME: OK. Why not to employ a dedicated employee to take care of these tasks?
MD: ...

Just for your reference.

First, stick to the rules. The productowner is the only person to decide about priorities. The developers are the only group te decide what they can do in a srpint.

Add some flexibility for the unexpected. You can create some time in each sprint for ad-hoc questions, but you should not allow to cancel a sprint for a big new project.

Your customers are your stajkeholders. The best thing you can do is tak to them directly. I'm sure customers will understand new features take time. You also need to negitate aminimum viable product with those customers. Maybe you can help them with a small most wanted part of the feature and do the rest later.

It all starts by keeping the scrum framework as boundary conditions and find a solution that complies wit the framework.

Just make everything transparent - if something needs to get done right away, then make them aware something else will need to give/get dropped/worked on later.

Think of the team like a bucket of water pipe - only so much can flow through at one time. To make room for something new, you need to remove something that already exists.

Hi David,

Use the SCRUM board and your influencing skills . It feels like the MD is not aware of the SCRUM roles and core principles around self-organisation and team empowerment. It's easier said than done when we talk to senior management to "drop" things off.
Suggested approach to tackle some of the problems you have highlighted:
1. Radiate information. The SCRUM board radiates information enabling conversations based on facts rather than emotions. You will find it easier to influence the MD by talking in front of the board. Every time a team member works on an Ad-hoc issue put it up on the board on a sticky note with a brief description of the issue and the number of hours worked on it. At the end of the sprint calculate the proportion of the team capacity in hours worked on Ad-hoc issues as opposed to new features. Try to bring him over to the board and have this discussion. Bring up topics such as value based delivery - were the ad-hoc issues as valuable as any new features that the team could have potentially built and shipped? You've just created yourself a coaching opportunity.
2. Coach the team on roles and responsibilities in SCRUM. Organise a "Roles & Responsibilities" meeting. All team members need to attend and invite the MD to it. Use a whiteboard or a wall and create columns titled Development Team, PO, SM, MD. Get a bunch of different colour sticky notes for each role on the board. Ask the team to write down what they believe their responsibilities to be against their role in SCRUM - for about 10min. Ask each team member to go forward onto the board and put up their stickies and talk through the reasoning behind their thoughts. Facilitate the discussions creating opportunities to coach team members on their responsibilities including the MD. Allow the team to reach working agreements on their roles and responsibilities collectively.
3. Propose the new Admin features to the business to eliminate manual tasks. Use the data you have gathered from the adhoc tasks to create a business case for it.
4. Continually lookout for coaching opportunities.
5. I see the positive from the adhoc tasks that the team is requested to work on. They have now acquired this knowledge and it will be particularly important when the team matures in control of their destiny. Try to keep this knowledge in the team.

Jitesh

Reactivity is a problem in start-ups; MDs and Sales tend to say Yes too easily to keep key accounts happy, even sell airware and then expect the development team to just deal with it and rescue commitments that should not have been made. Sometimes its because sales people are paid on commission, other times its scrambling to get the next invoice out bring more money in (unless the start up has been adequately financed). This results in Adhoc tasks and usurping plans.

To become a healthy organisation and transition from startup to BAU it needs to reduce significantly, so foresight and education is an important part of the solution.

When a company bows to these requests, it becomes expected by the customer thereafter and then its hard to shake off. I think the startup MD mentality can be a little tricky sometimes when it comes to changes, such as transitioning to Agile and Scrum.

In a similar case to yours David where we had basically a dev team and sales people, we formed a small team of engineers for technical pre-sales activity and support. It was lead by one person and we rotated engineers through it - some stayed eventually as it grew. Its not a proper support solution either but it allowed us to reach a compromise and say "Ok, channel your adhoc requests to this new team leader" and largely kept the heat off the core dev team.

"...a call between the management of our company and another large customer today. The result of the call was a conversation between the MD and me that they had made the following decisions which needed to be actioned immediately."

- this is counter productive in many ways. It can be demonstrated with KPIs - the effort required to cancel the current work, the impact in resource re-scheduling, incurred delays to other projects (and therefore unhappy customers), impact on reputation of the companys ability deliver to commitments etc... Again, its education - if the MD wants the company to grow strong then he needs to manage the customers according to his companys capacity, otherwise he'll simply burn off his employees. Its worth having a chat with him about it and seeing if he has any strategy to grow out of this; you can contribute to it by coaching ;)