Two Teams
There were two teams working on a legacy product, let's call them team A and team B. (There were other teams too, but these teams are starring now.) Team A was working on the very core services and low level functions that other teams, including team B, depended on. Due to the fact that automated code coverage was not on very high level and the code base was really complex and not in mint condition, there were many times moments that things broke down even though all automated tests passed. And because team B was working on the application layer, they often found these problems. And they suffered.Team A did mistakes. But they were always keen to correct their mistakes and open about development ideas. Approaching them was easy. You could walk into their team room and just state your business or ask for help. And they would help you out for sure.
The working model for the teams consisted of fixed deadlines. On a specific date things were to be done. Prior to this date was a so called stabilization/freezing period that was dedicated for bug fixing and testing that all parts of the complete system worked. One can imagine that closer to the deadline pressure was increasing.
During the stabilization period team B was blocked by some defects. They didn't proceed in testing because they didn't want to test same things again after the fixes would be completed. Unfortunately team B didn't make things easy. Usually they approached team A with JIRA issues. And we are talking about teams that handled plenty of issues a day, so prioritization and keeping track of all changes was a challenge. So sometimes it happened that the issues did not progress very rapidly.
At the time of deadline team A was done with their testing and didn't saw major blocking issues. Team B was about halfway done and still had issues open. And they were complaining that team A was blocking them. In the end both teams ran out of time and the common product was not releasable in time.
In Hindsight
Both teams made mistakes. One of the major ones was communication. In a small organization it should be more than ok to use the Adidas-method: walk to your colleague. Don't keep things in a desk drawer. Let the other person know about the problems in a timely fashion. Don't rely only on the tools.Another major mistake is relying too much on automated tests if you have low coverage. I think it's a sure recipe for disaster. If your code coverage is 35 %, it means there's still almost two thirds of your code that needs to be tested manually. It is laborous, time consuming and demotivating, but it's a must if you don't want to give out buggy software.
In our setup cutting scope is possible. The rule of thumb is that schedule and quality are fixed, but scope flexes. This principle was not obeyed and the scope was not adjusted in time. And quality debt had been accumulated during development resulting in big amount of late bug finds.
Finally the whole fixed schedule model can be questioned. Is it the practice that creates most reliable and high quality software? Of course continuous attention to quality, vigorous testing and cutting the scope in time will make a big difference. But most of the time people are weak and things tend to take all the available time. I have started to lean more and more towards concentrating on getting things done and letting the schedule flex a bit.
Another text book answer would be that if something is difficult, you should do it more. If it's hard to keep three month deadlines, cut the time in half or even shorter. Then you will iterate more rapidly and get better faster. I'd like that too.
