Change

I recently had a conversation with a business analyst in my delivery team. A problem had come up, in that he kept pushing for changes to a user story we had delivered in a previous sprint. Rather then going through the agreed channels he kept walking up to our cadet and asking her to do them immediately.

This is problematic for a few reasons, but in explaining this to the BA I gave an analogy that has since resonated with a few other people. The core of the problem was the BA felt he needed to be fair to a stakeholder who had been absent when the requirements were originally gathered. Although the story had been finalised, pushed and developed we learnt this stakeholder was not part of the initial analysis. In the BA’s mind it was important to be fair to the stakeholder, and this was their way of delivering on that.

The Metaphor

Imagine you were going to order sandwiches for your team and there’s a nice sandwich store across the road. You collect everyone’s orders, but John is away in a meeting. You know John likes BLT sandwiches, so you decide to order that. You walk across the street, and order all the sandwiches. The staff are lovely, the sandwiches are made to order and look delicious. You pay for the sandwiches, and leave.

Once you get back to the office you see John is back. A little worried, you don’t let John know you’ve been to the store and ask him what he wants. He tells you he’d love a BLT, but with some cheese and extra bacon. No worries – you’ll just run over to the store and get them to make the changes!

You go over to the store, and hand the staff back the BLT – you ask whether you can get some cheese and extra bacon immediately. They look at you a little strangely but, wanting to please the customer, they accommodate. You take the sandwich, and they tell you that will be an extra $2.

Confused you explain that you paid previously, and explain that of course you are only being fair to John – I mean, he never got to place his order. The staff at the store calmly explain that they are very sympathetic, and really want to help you get the right outcome – but more work has been done, more ingredients added, and there’s a cost associated with that.

This seems reasonable, and most people wouldn’t really question after this point.

Moral of the story

If this situation sounds ludicrous it’s because it is – this would never actually happen in the real world. In software development teams you’ll (hopefully) find people that want to help you get the order right for the customers. However, as with the sandwiches, there’s a cost. Usually this cost is in time, and unfortunately that’s not something that can be given away for free.

In many projects the way to ensure we don’t spend more then we have is to control change in some form – it might be sprints and sprint backlogs, it might be change requests – but the change process is there for a reason. It’s not to stop or push back on change – rather it’s to make sure that the team doesn’t go bust by giving away more time then they have.

Image Credit: Raúl González