Chris Johnston

My current project, on the surface, is great. We do Agile. We pair, we practice TDD, we have stories that the business prioritize for us, we have a nice card wall where we can see our cards move from the story backlog to completed. We have continuous integration with unit tests, integration tests, acceptance tests and selenium tests. And we care when the build breaks. We also have weekly retrospectives even though our iterations last two weeks.

I should have nothing to complain about, and yet, I do. However, I would like some feedback on my complaints. I think the team could be doing things better and would like some other opinions on a gripe that I have.

We have a practice of kicking off stories before a pair can begin work. This involves getting the BA, the producer (the business representative), the tech lead, the tester, and the rest of the team together to discuss a single story that a pair is about to work on. The reason that I have been given for this is that stories change too quickly and frequently and, therefore, cannot be reviewed any earlier then just before the pair begins work.

People are busy though, especially the business representative, and thge pair ends up sitting around waiting until everyone is available. A few of us have put forth the idea of doing a kickoff of all the stories committed to for an iteration during the iteration planning meeting. Then simply letting the pair work on the story when they get to it. If there are changes, it is the devs responsibility to read the story and discuss those changes with the BA and business. The conversation shouldn’t end just because everyone has done a kickoff.

Management, however, squashed this suggestion pretty quickly for the reason stated above. My take is that they don’t trust the devs to properly read and implemented the story. Which brings us to walk through.

Walk throughs happen after a story is dev complete and once again involves the BA, the producer, the tech lead, the tester, and the pair. Everyone goes through the story, dissecting it to ensure that it has been implemented correct. The pair cannot work on anything else until the walk through has been done. In the end, this means that the devs have to wait for everyone to be available.

The interesting thing is that even with all this scrutiny, I am not convinced that it results in any less bugs or better code. As far as I can tell, it simply wastes everyone’s time. The amazing thing is that the team continually votes to keep kickoffs and walk throughs as part of the process and adds things to make then either longer or harder to perform.

I can see value in each of these practices. Once you have completed a story, it is nice to have another pair of eyes take a look and double check that you haven’t missed anything. And before you start, it is important to have that conversation with the BA and business in order to clarify exactly what it is that they want. Both of these are vital parts of software development.

I think the part that bugs me is the lack of trust that is implied by the way the two practices are carried out. I feel that as a dev I am assumed guilty until proven otherwise. Until I can repeat back to the BA and producer what is written in the story, I am deemed not worthy to begin work on it. Likewise, until the business, BA, and tech lead have all signed off on a story, it is deemed incomplete simply because it was implemented by a developer. Or I could be reading to much into things.

Other devs have also commented on the lack of trust they feel due to these two practices, so I don’t think it is just me. But how do you go about changing this kind of culture? And is it even worth changing? It gets frustrating when these issues come up in retro and either management simply says no or the rest of the team votes to make them even more complicated and time consuming. I am not sure how to change an entire teams mind, especially when it seems to most people that it is working fine.