At the end of the last year we faced the following situation: a product owner turnover, and the new one coming with a great idea. It happened to be that this great idea was a “happy new year” promotion, and so it would be great if we could implement and deploy it at the beginning of december. Unfortunately, we were at the beginning of the second week of november, and a sprint had just finished…
- we use two week sprints;
- we needed more time to plan the promotion;
- starting a sprint without the promotion features would lead us to a late deploy date;
As I could do nothing about the fact that we needed more time to plan the promotion, and as this promotion could bring us very good results, I saw our sprint length as an impediment to deliver the value that our new product owner envisioned. So, I removed it! I proposed a one week sprint where the dev team could kill some tech debits and the product owner’s team could plan the promotion. Both teams enjoyed the idea, given the context, and we did it that way. After this one week sprint, we returned to the usual two week sprint, and implemented the features of the promotion, releasing it at the beginning of december, as it should be, and the promotion became a success!
An impediment can be as abstract and subtle as one can imagine. Even things we know as “agile laws”, as the fixed sprint length, can be bended to serve us better. Of course, before doing that I’ve made it very clear to the product owner that we were going to take this manoeuvre only because of this particular situation, and that we shouldn’t use it anymore, in any circumstance, given that he would have time to plan his releases with a lot more anticipation after this very first sprints of him.