Monday, September 18, 2017

A Long Story Cut Short - The Importance of Pausing to Think

Today was the day. My team released a huge epic introducing major changes in our application. Normally, we release many changes during our daily release slot. However, this release was unusual in itself, and it taught us a bunch of important lessons.

We started working on the epic on July, 11. As we had discussed the topic several times before, the whole team felt that we had a shared understanding and were ready to go for it. During the first two weeks only one developer focused on the topic, and gained first insights on how complex it actually was. He raised the issues he was facing and called for support, especially as delivering this epic was our highest priority. We decided to have the whole team step in and share the work load. We still highly underestimated how far this would go - or rather, how far we would let this go.

The whole team, meaning five developers, our product owner, our agile coach, and me as tester delved into the topic. And together, we gave birth to a monster. With every little change the whole solution got more and more confusing. It was incredibly hard to figure out what was expected and what was unexpected behavior, and especially how we would ever be able to understand our implementation in the future again. And by "future" I mean half an hour later. Everybody was having a hard time. Nobody was happy with what we did. The amount of curses increased rapidly. We all felt we would soon go insane. One teammate even suffered from nightmares and sleepless nights. We are really not proud of this tragedy, but this should give you a pretty good idea of what was going on.

Desperately, we discussed again and again if there would not possibly be any other way to fulfill the business need but also enable ourselves to keep our application maintainable, extendable, and last but not least testable. However, our discussions turned in circles. So we pressed on with implementing the epic, eager to get to a minimum viable version for which our product owner would let our users access our test system to get their feedback.

The fun fact - or rather really sad truth: As soon as we were ready to start the user acceptance test, one developer took the time to create a completely new prototype, based on a totally different assumption. And after only half a day, on August 30, he was ready to share his new approach with the team, to have them challenge it and find flaws in his thinking. We were stunned by his simple approach. We raised some questions, but couldn't find any reason why not to go with it. By only doing one thing differently, everything else became a lot less complex. Comprehensible. Consistent. Doable. With way less effort and way less changes in our application. What he did? He threw a convention over board which everybody had considered as a fixed precondition. You know, as soon as you have to handle x, everybody strongly recommends to do y to avoid problems. We had never challenged this assumption we had in our heads, all of us had accepted it as a given. But in the middle of implementation, it turned out that this convention made everything really bad for us. Neglecting the convention instead was fitting way better in our context, from business perspective as well as technical point of view.

Shame on us that we had to go such a long and winding road of learning how not to do it. Nobody had put pressure on us but ourselves, not our product owner, not our agile coach, not our stakeholders. We ourselves were driven by the thought that we have to get this done and finished as soon as possible, making us pressing forward without taking time to actually think and experiment early. The team even "temporarily" discarded our rule to stop starting and start finishing, meaning that all developers continued to start working on new topics before former ones had been completed. Unsurprisingly, this created lots of bottlenecks and context switching, making the whole situation even worse. And as soon as one of us felt we have a bit of time to breathe again - he found the clean solution.

To cut a long story short: within a few minutes of discussion, we wholeheartedly threw away our first implementation on which we had worked for nearly two months by common consent, in favor of this new and easy approach which we in the end fully implemented within about one week. After going through all this, we couldn't but ask ourselves in retrospect how this could have happened and why by all means it took us so long to challenge our assumptions, learn, experiment, and see the solution. But in the end we did learn the following.

Conventions are recommendations but not carved in stone; they might not apply or be a good fit in your context. Think outside the box (that you might have created for yourselves) and experiment early with different approaches. Don't get so busy that you cannot pause, breathe, and think. And last but not least: Don't be afraid to kill your baby, especially if it turns out to be a monster.

Bonus read: By coincidence or not, when thinking about publishing this story I came across the post On Real Options and Speculative Investments by Liz Keogh which nicely reflects many facets of our story. Besides the fact that I really relate to the core messages, it's a highly recommended read.

4 comments:

  1. Great read, I think this approach is also relevant in every day life too. If one feels that it's becoming overwhelming too quick they should pause and think of alternative approaches. Thanks for sharing.

    ReplyDelete
  2. I mostly respond to people these days by saying 'I'll have a think about it'. I've always dislike making decisions on the spot and feel strong enough these days to not do that. It's too easy to react and respond in the wrong way when not giving the appropriate time to think about the consequences or potential other solutions.

    ReplyDelete
    Replies
    1. Great advice! We should have done so as a team. In our case, we thought we had given our solution enough thought in the beginning - but then instantly went for it without actually trying it out or giving alternative approaches a try as well to see which one would fit best in our context. We're still glad we came up with a proper solution before it was too late, but it took us quite some learning time. In retrospect we really strive not to repeat this in the next similar situation, but to experiment with different solutions hands-on right in the beginning. Time will tell.

      Delete