Due to COVID 19, all workshops and courses are remotely given for the foreseeable future.

Janet Gregory: Agile Consultant, Trainer, Advisor, Writer, Speaker

I’ve been seeing a pattern lately with some of the teams I’ve been training or coaching. Some have been doing agile for a couple of years but have gotten stuck in a rut and don’t seem to be able to find a way out of it. The same problems keep cropping up in retrospective after retrospective. They read the literature but it doesn’t seem to help. Let me relate one example that demonstrates what I mean.

The team size is about 14 at this time and has varied a bit but not a lot. The team members have been together for over three years, and have been struggling with making their stand-ups effective. They read that the appropriate team size is seven plus or minus two, so they’ve tried dividing up into two teams but that created a different communication issue between the teams.

They united the team as one again because the ineffective daily stand-ups were better than the lack of communication. The meetings went too long and no one seemed interested in what anyone else had to say, and were boring. The sessions became useless as a communication tool.
As I started asking more questions to the team to understand the underlying problem, I realized there were several contributing issues. The team size perhaps was one of them, but I have worked on teams that size that had very successful stand-ups so I didn’t think that wasn’t the main factor.

After some digging (mostly asking questions and listening), one problem that I saw was the developers had become very specialized, each one working on their own component. There was no interaction between what one developer was doing and another. The stories were divided up by component – horizontal versus vertical through the layers. One side-affect of this was the iteration became a mini-waterfall. The testers could not test the whole feature until all the components were put together – at the end of the iteration. This meant the testers had no real interest in what was happening either until the end of the iteration, and then they were so busy they didn’t have time to attend. The problem was amplified because of the 30 day iteration; there was a lot of code to test.

Looking at the real problem rather than the symptoms, gives us a very different problem to solve. By dividing the stories into smaller vertical slices, developers need to work together and communicate on a daily basis and will learn more about what the others do. The testers get the stories a lot earlier to test, and they become interested in the issues and progress communicated at the daily stand-ups.

With this team, I believe that changing the way they look at stories will solve multiple problems. Sometimes having someone from outside the team looking at the problem can save months, or even years of time.


Leave a Reply

Your email address will not be published.