Handling a Mistake - Adopting a New Workflow

Problem

My company was acquired and our business was going to move over to Berlin by the middle of the year. After the acquisition the new business asked us to adopt a new workflow. I (and another engineering leader) verbally agreed, not quite understanding what exactly we were signing up for. I didn’t think much of it, knowing that we only had three months left before our positions were dissolved, so I went along with it. I simply agreed to adapt to the new process without reflecting on what the consequences might be. Besides, we thought, how hard could it be? This was obviously a mistake on my part.

Actions taken

When asked to switch processes we were working with global Sprints - one Sprint across multiple organizations placed in different time zones. Given these circumstances it was hard to do Sprint planning, kickoff activities, and Sprint closure due to the time differences. All of the organizations were working on different things.

Another issue with the Sprints was that the new workflow was designed for commitment and a delivery for each Sprint. The contractors we were working with would take five tasks, commit to those five, give them priority, and have them done by the end of the Sprint. On the other hand, our organization would pick up as much as we possibly could to deliver in a Sprint, even if that meant having incomplete development by the end of the Sprint. Therefore, we had two contrasting opinions about conservative delivery commitment based.

The solution to these differing global Sprint processes was to create collocated based Sprints. Each location had its own Sprint and method for Sprint processes and all activities in that Sprint would happen within an organization, within a single time zone. All of a sudden there was no overlap and everybody was happy.

A second consequence due to the adaption of a new workflow was that the workflow itself was very difficult. It contained 14 steps including planning, backlog, commitment, spec, and more. Hence, even if you wanted to reject a ticket you had to click 10 times to get it through. This resulted in a lot of noise and chaos in our existing seamless Sprint activities. Needless to say productivity and morale suffered as well. As a leader, it's important to listen to feedback, especially when you make org-wide changes.

So we went back to the whiteboard and condensed the 14 steps down to 7 - backlog, committed, in progress, blocked, under review, ready to release, and closed. Simple, to the point, and everything else was only one or two steps away, instead of 10. It was an easy transition for the team because it was more familiar, since it's similar to what we had before, resulting in a boost in morale and productivity.

Lessons learned

• As a VP of Engineering there is the notion that I am thorough and don’t make mistakes. However, I’m only human and I actually make mistakes all the time. I’m not perfect nor do I pretend to be. Once I’ve realized I made a mistake, I will own up to it and take the necessary steps to course correct. Ignoring mistakes is not an option.
• No matter how tired you are, even if you know that your job is going to end in a few months, don’t take anything for granted and always try to make time to vet new adaptations. Trying “to deal” with something will only make matters worse, impacting the morale and productivity of the team.