At my current project, me and my very experienced team mostly focusses on supporting the development teams with architectural design challenges, long-running improvements, or helping them resolve technical debt that is impeding their user stories. However, during the last five months we picked up some considerable amount of new stuff in which we were tasked to setup the skeleton of a distributed backend architecture for mobile apps that uses high-level business events and commands to connect mobile apps to the company’s flagship product.
- Too often individual team members were working on user stories on their own. This is a natural tendency I’m seeing a lot with experienced developers. But although I do understand this, we noticed that this results in no work completing for days until all is finished. Also, not all developers are great communicators. Seeing a developer with headphones on, completely isolated from his surroundings, working for hours in solitude, and then taking his stuff to go home without any kind of progress was not an unusual phenomenon. And don’t get me wrong, those are very capable developers.
- The team complained that they lacked a complete architectural overview of the stories they were doing. Since I’m the most experienced developer in the team and have in-depth knowledge of most of the involved systems, I usually prepared the stories by writing down design notes and creating high-level sketches. Then, when a team member was ready, I tried to elaborate on all the aspects of the design. But for obvious reasons, them not being part of the design phase is a big impediment for the team to fully participate in the final solution. They never had to figure out the technical subtleties of interacting with the surrounding systems themselves, fully relying on me for guidance.
- Another side-effect of taking the lead is that I was the only one hearing about project issues and unrealistic deadlines. And since I tried to protect the team from this pressure and the associated consequences, that same pressure got under my skin. For instance, I started to get pissed when the team ran into set-backs or got annoyed with myself for not intervening much earlier. In general, I occasionally got quite pessimistic and couldn’t help myself from venting that to the team. Even worse, since the only point in time they got to learn about some design decisions was when I explained them my ideas, this pressure made them feel like there was never enough time to build a solid understanding of the problems, the options and the solution.
It doesn’t take a lot of science to understand that this was all caused by two things. One, us not knowing what needed to be done upfront. And two, our inability to determine where we are, what is still needed, and when that will be done. To resolve this, we decided to start scheduling the work in batches of two weeks, each preceded by a collective design and planning session. This didn’t prevent me from preparing the stories in secret though. But at least I was forced to fully involve the team in the final design process.