I’ve opened this series of articles with a conversation I had with my mentor about Company Values. Another interesting conversation we had was iterating and optimizing the company’s workflows and culture. As an industrial engineer it was no news to me, but as an engineering manager it was. I had to ask myself what is it in our development culture that causes Velocity drops. When was the last time you questioned yourself… about yourself? What is it that you as a manager do that causes Velocity drops? What can you do to prevent them?
As I’ve mentioned before, I was reading my way through what Agile is. At one point, I was trying to decide between Scrum and Kanban, which one is right for us. I’ve always worked at Scrum, meaning Sprints of various lengths. Working in Scrum entails sprint planning, sprint retrospective and many other activities. There is indeed a need to prioritize and estimate tasks, but in Silo they are of a completely unknown nature or definition. Does it have any value in a continuously changing environment, as we are a small startup after all? The answer was a definite no. When you’re that small and priorities change on a daily basis, there is no value for through preplanning. We went with Kanban and saved a lot of working hours. Further down the road, when we were a team of 9 heading towards production, I double checked the causes leading to that decision. I decided to remain at Kanban as Scrum would have been a waste of about 20 working hours just to do Scrum. If we would have gone that way, that would have been a Velocity drop. Another instance of valueless work prevented.
However, we did do standups. At least up to a certain point. At first it was all good but my team ended up being against it. As we were a multidisciplinary team, when Mike wanted to report progress on the MCU it was of no interest to Guy the UX developer. They were rightfully angry as it indeed was a waste of both of their time. They felt that Velocity drop. I was horrified by the thought of fellow R&D Leaders wondering to themselves “What do you mean you don’t do stand ups?!”. Stand ups are the bread and butter of Agile, how can we live without it. It just didn’t make sense at all.
At that point, stand ups provided value only for one person. It was only me that needed to be kept up to date with progress. When I realised that, I came up with a different method that would require less of my team’s time. We started doing small forums of 2-3 people once a week or two. I used the coffee breaks for catching up once in a few days. I always made sure they were entirely in sync directly with the product team. Once in a while I was indeed caught with “my pants down”. “I’m not aware of this” I had to say a few times during management meetings. Most of which were concerns that did not actually require my attention which was good. I took some heat, but that was worth it. My team felt their Velocity raising and managed to do more work with their precious time. They went home happy, came back the day after happy. Everybody wins.