A reminder on why every software team can benefit from Scrum and/or Kanban

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.

Because of our usual support focus, we were kind of process-less. Yes, we used JIRA to track tech stories and did stand-ups every morning, but we never adopted a formal process like Scrum or Kanban. So after two months or so, we decided to do a little retrospective to see how we as a team were doing. We used the 4 L's technique in which we collected post-its in the four columns Liked, Learned, Lacked and Longed For. I will spare you all the great things the team liked, but these were some of the observations.

• 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.

To get the team to swarm more on stories, we decided to introduce a work-in-progress (WIP) limit of two. In other words, the team shouldonly work on two user stories at the same time. This not only allows us to finish stories faster, but it also forces us to think a bit better about how to break down the user stories so to promote parallel development. This alone requires a much more immersive understanding of the stories involved. In a way we combined some of the practices of Scrum and Kanban to do a little bit more upfront planning as well as track and report our progress. Together these have brought back the peace in the team.