Ad hoc changes during the sprint
Hi Everyone,
I'm kind of stuck and looking for some advice.
I just started a new Scrum master job at a big government organisation. They recently (about 10 months) a go started using Scrum for the teams. Well at least they think they are.
The Scrum team does Development and Operations work. The development work can be planned for the sprint but for the operations work it is mainly adhoc work which very often needs to be done immediately and can not wait till the next sprint (our sprints are 3 weeks). Resulting on that a sprint is never completed. Our burn-down chart does go down, it is more or less horizontal with ups and downs.
The Product Owner also acknowledges that our team has a problem working Scrum with all the adhoc tasks. I think one of the problems is that the rest of the organisation does not work in an Agile why. Also it feel to me that the management wanted to work Scrum so they place PO and SM in a team and then they can tick the box saying they transformed to Scrum.
I'm trying to think of a way to deal with this. A few ideas:
1. Leave say 40% of the capacity free in the sprint for adhoc work.
2. Have shorter sprint of lets say just 1 week
3. Move to Kanban or Scrumban
4. Work with 2 backlogs. 1 backlog for the planned work and 1 kanban backlog.
A few 'buts' about the above points:
1. At the beginning of each sprint, the amount of adhoc work is never know, sometimes it could be 60% and sometimes maybe just 5%
2. 1 week sprints could work, but doing all the scrum ceremonies each week would be overkill, the ceremonies could be don maybe once every 2 weeks. This is obviously not according to the Scrum guide.
3. I have no experience with Scrumban.
4. This just doesn't sound / feel right.
Any suggestions would be welcome!
1. Leave say 40% of the capacity free in the sprint for adhoc work.
2. Have shorter sprint of lets say just 1 week
3. Move to Kanban or Scrumban
4. Work with 2 backlogs. 1 backlog for the planned work and 1 kanban backlog.
Option 3 and 4 i would not advise.
But option 1 and or 2 are options you could suggest to the team to try. and with shorter sprints the sprint events can also be shorter.
And is it possible to adjust your product so that it has less ad-hoc tasks?
it feel to me that the management wanted to work Scrum so they place PO and SM in a team and then they can tick the box saying they transformed to Scrum.
To the best of your knowledge, is there anyone in senior leadership who wants more than a box to be ticked?
Kanban isn’t really an alternative to Scrum, so that isn’t going to solve your problem I’m afraid. Kanban is an improvement method whereas Scrum is a delivery framework, so they do work well together, but it’s not going to address the underlying problem. Scrumban isn’t really defined or owned anywhere so it can pretty much mean whatever anyone wants, and sometimes turns out to the be “the bits of Scrum that aren’t too hard plus the bits of Kanban that don’t rock the boat” so you end up doing nothing that causes the change you were intending to make.
One thing you could try: if the ad-hoc work is important then work out what percentage of your team’s time is usually spent on ad-hoc, and make that a PBI within your sprint backlog. If you are tracking the value on the Product Backlog Items, then you can show the delay on delivering that work because the team is spending time on the ad-hoc. It may be that the value of the ad-hoc work is greater in which case the product owner can make the business call on which work to order higher. Remember everything the team works on in Scrum should come from the Product Backlog and therefore through the PO, that includes the ad-hoc work. Transparency is your friend here, make the impact on value delivery visible for both planned and ad-hoc work and the business will usually push in the right direction.
The other thing you could take a look at is your Sprint length. If you had shorter sprints could the ad-hoc work fit within the sprint? Perhaps your SLA (service level agreement) on the ad hoc work would allow for say weekly Sprints, so you can plan that work in along with your other work at sprint planning to give you a better chance of actually feeling like you’re achieving something more in Sprints.
The key is always going to be transparency about the impact of the decisions as they are currently being taken, making value visible is really powerful.
I hope that helps.