If you read about my – Marijke – introduction to scrum, you know there’s probably a voodoo doll somewhere with my face on it. I wish I could tell you that there’s only one of those and I’ve bettered my agile life since then. But like many wishes, one can only cross fingers… Let me tell you about the second time I drove a scrum team (actually in this story: multiple. I am ambitious 🙂 ) crazy and what we all learned from it. And please keep in mind. I really meant well.
Back in my product manager days, I was once responsible of the introduction of a new product. According to Dutch law, we should inform our customers a few months before go live. Not really agile I hear you think! Might be, but that doesn’t mean you don’t get in trouble when you don’t comply. So. We did it! We called a date and printed millions of letters a few months before the actual go live date. While 6 scrum teams were still developing, testing and de-bugging
the functionality in a chain of minimum viable products. And of course, two weeks before the announced introduction date, it seemed impossible to be done in time! What to do? You probably guessed. Those poor guys (and girls!) worked overtime. Not an hour here and there, they worked nights and even weekends to still meet the communicated date. Here goes your sustainable pace – one of the scrum pillars – down the drain. And although these guys probably absolutely truly love their jobs, they were no happy campers. Who to blame? Of course, pushy business people . Represented by? Yep, me! 🙂
I felt this couldn’t be the way forward. I went to their stand-up, openly apologized for the situation and explained why our legal department wasn’t “scrumming” yet. And what the f%*)&^ck we were thinking naming an exact date in those letters! For me, this story tells how hard it can be to combine a scrum/agile way of working with some basic principles you have to follow being a large organization. Sometimes you can’t avoid having to deal with deadlines. What could I have done differently? To be honest, only one thing. I can’t change Dutch law and squads can’t change running into bugs in the end stages of delivery. That’s part of the process. But we can improve communication. Communicate with each other, starting from the earliest stages of development and continue during the process will make everybody’s life easier. That doesn’t mean you will always agree and it doesn’t prevent you from working overtime. But at least you all know why it needs to be done.
Those guys who made sure we met the deadline still work at my department. I see them almost every day. I still feel like I should say sorry every time.. 😉 So, once and for all, speaking for all people having to push deadlines in an agile organization: We are sorry. We really mean well!
Cheers, Marijke
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
wasn’t it an option to first finish the MVP, have the letters printed then and so be sure you have the at least the MVP ready when you sent the letters? Or were there other timelines or so..
Hi Maarten, thanks for your comment! Like many projects, this was a complicated one. The go live date had been pushed back a few times already and we wanted & needed to go live asap. The product that went live was the mvp. Ordering paper for multiple million letters and printing them takes a few weeks, so we had to prepare in advance. But you are right. Looking back, we could have discussed at an early stage the dependency with the letters, date and mvp. I think awareness in every part of the project about that would have helped! Still the situation I descried in the post might have occured, but the understanding and emotions would have been different! Cheers, Marijke
Thanks for the response. The new situation with you being in the same tribes as the teams should help then with getting these dependencies resolved sooner, where the old system was the project coming from business to IT and it already being set in stone a bit more.
I completely agree! Being all in 1 tribe already pays off and I think it will continue to improve over time (when people get to know and understand each other and each others work better). We will keep you posted 🙂
Great post and thanks for sharing your insights regarding the necessity to push for a deadline. I share your opinion that an early and openly communication will help to see and learn how progress in the project looks like.
I’m not familiar with the Dutch law – but maybe there are possibilities to explain the nature of software development (working in a complex environment) that implies that you cannot predict an exact date so far in advance (without adding an huge buffer and even with that buffer still having a high risk of failure).
Maybe even the costs of announcing a delay could have been favorable in comparison to the high risk overtime strategy. Just to explain, I’ve been myself in these kind of projects often enough and really often there were much better ways than burning motivation, increasing stress and fighting for an artificial deadline.
Btw – what methods did you use to forecast the deadline date?
What will you can the next time a similar situation will appear?
Hi Sebastian, yes, looking back I think I would do differently next time: have “business” dependencies and milestones such as legal obligations and customer impact on the various scrum boards for the engineers to see and take into account, be present at more stand-ups and have more joint sessions with all parties involved. I think that would have helped 90% of the situation. Still sometimes it is simple not avoidable to hit deadlines and, as we all have experienced – the end of a project is always more stressful than the start. I remember having weeks to study for an exam while being a student, but it always boiled down to one sleepless night, drinking liters of coffee, doing all the material in that 1 night 🙂