Last-minute changes in an agile project

Today I ran into this quote:

“This means, that in an agile methodology the
responsibility of producing a quality product
is shared by ALL those involved in the process
and is not the responsibility of a specific group
of specialists.”

It made me think about the sort of ‘panic phase’ that usually occurs in the hectic period before a release.
Yes, I know that in Scrum, the team is supposed to deliver working software to production every sprint, but hey, sometimes that doesn’t happen. Especially when developing a new product, there might be a certain base level of functionality that the business wants to put in production that just cannot be built in one sprint. That is dangerous, I know. Most of the time, when doing scrum while facing a normal deadline, people start to panic and will try to stuff in last-minute requirements. For the team, this is hell. The developers will look for the quick-fix, the tester is losing overview and drowns in work, the design is never up to date….and everybody just reels in confusion.

There are a couple of reactions I’ve been observing in people when this sort of thing happened.

You have the type of person that just wants to melt away, become one with his desk, blend into the walls, will do anything not to get involved. They just stop communicating. I don’t know what’s bothering them, because they won’t talk about it.

Then there’s the type of person that wants to be the superhero. Never give up, always see the options. This is in one way a better attitude, but also has a dangerous side. This type of person is usually the PO. Giving up isn’t an option. When the ship goes down, they go with it.

Another type of person is the person who just shrugs after the next sudden change comes around. They stop caring, because the credibility of the PO has dropped below zero. This person will just surf news websites, have fun with other team members, and still do their job without question. They have become immune to the bigger goal.

And then, there’s a type of person who will become cynical (I fall into this category). At first, this person will co-operate with the changes, trying to keep an overview, talking to others a lot about impact and trying to make the best of it. However, this cannot last forever. At some point they’ll provide loads of cynical remarks, and just stop trying to be polite about it.

Personally, when a project goes into this state, I think it’s nearly impossible to keep up a team-spirit where ever team member feels responsible still. The PO turns into a ‘dictator’, the team is like a leaf blowing in the wind, direction unknown. People don’t like to be tossed around into direction A, then direction B. They want clarity. Scrum is so awesome, but when people start treating it like ‘oh, we can now change anything at anytime and if you don’t agree you’re not agile’-sort of thing, then the fun is soon over.

So, regarding the quote: when the situation described above happens, the business runs the risk of losing peoples’ commitment to the ‘higher goal’ of releasing high quality software. Responsibility will no longer be a shared and sacred thing. It’ll all rest on the shoulders of those who brought in their last minute changes. And the cynical being in me thinks: I hope it’ll fire back at them.

When thinking about a solution of this problem, I cannot help but blame the stakeholders and PO for not thinking about the consequences of their changes sooner. It’s always good to have a concept phase before sprinting, and really use that time to think things through. Go beyond the happy day scenario’s, think about errors, alternative flows. Think about legal consequences, think about existing users, think about the architecture, etc. So many things can go wrong in IT projects, but nothing sucks more than finding all those things out during a crucial phase of development!