So what happens when the project goes live and people start rolling off? Is all that knowledge lost? How do you stop the “I didn’t write this crap” mentality from setting in. I can’t even count how many times I’ve heard that phrase. I’ve heard so many developers use the “I wasn’t involved in that decision, so I’m just going to follow what they did” excuse instead of refactoring a bad piece of code. This doesn’t fall into a single clean Agile category, but it affects things like code quality, morale, and ultimately the productivity of teams, so I thought it would be good idea to cover it in this book.

Real-Life Stories

Story 1: Creating a Sense of Ownership

On a very large project I saw the effect of what I just described in the introduction to this chapter. We used several vendors and contractors to pump out code. One of the vendors, which will go un-named, had a small army of analysts and developers on the project. To be clear, these were very talented individuals for the most part. . But at the end of the day, these individuals were under a lot of pressure to get code delivered and knew full well that they would not be supporting this application when it went live. Sure enough, there was a lot of poorly written and designed code. To compound the issue, there was no real documentation and these developers were the only ones who knew how key parts of the application worked. Once the project went live and the vendor, and other individual contractors, rolled off the project, it was apparent that what the vendor and the contractors delivered had a lot of issues. Of course, it was too late at that point and the employees of the company were stuck having to learn this code and then replace large portions of it.

Thoughts

Again, this problem is not all that unique. What makes it interesting is that it is not unexpected, yet proper planning to account for it is often not put in place. But there are things that can be done to minimize such problems.

For example, think about some sort of oversight. Have senior developers from the company provide oversight for architecture and design decisions. Have code reviews that must be signed off on by at least one senior developer.

Another thing to think about is accountability. Have something in the contract language about holding vendors accountable for what they deliver. There should be something in the contract about accepted code coverage numbers, defect counts, and so on.

Give some thought to effective handoff requirements. The contract language should include something about handoff requirements, and about creating handoff documentation in the companies’ required format. Such documentation should be reviewed with the teams that will support the code after it goes live.

Finally, put coding standards in place. Having standards in place, as I’ve talked about elsewhere in this book, is crucial. These standards should be enforced in code reviews and through CI (via static analysis and automated tests).

Story 2: Spreading Knowledge

In another organization I saw the impact of offshoring sustainment. We had several teams in South America that supported part of the application. These teams were very good and knew parts of the application very well. The problem was that whenever there was a holiday in their country (apparently the country has a lot of them), there was no coverage if there was a live site (production outage). Specifically, there was no primary off-hours developer. When a production issue arose during one of these holidays, a manager had to scramble to find a developer who could look into the issue. This was not good for the business because the response time was slow, not good for the manager who had to run around to find someone to help, and finally not good for the poor developer who had a trial by fire.

Thoughts

I don’t think the situation in Story 2 is all that unique to this one organization or company. I’ve seen application support offshored at other companies. But I think a few things can be done to mitigate this risk to the business.

For example, either have the offshore team take care of 24/7 support or have an onshore team lead. 24/7 support obviously addresses the issue, but I would still recommend doing some of the other things mentioned, like cross-pollination. The onshore team lead is something I think is a good idea in general, not just in terms of support.

Another idea is to have documentation (troubleshooting guides, procedures, etc.) that can be used by other teams to support parts of the application when the primary teams are not available.

Try rotating the support among offshore and onshore teams. That way when one of the offshore teams is not available, there would be an onshore team that at least has the knowledge needed to support a production issue. This type of “cross-pollination” among teams is a good thing in general.

Story 3: Good Transition of Ownership

In contrast to Story 1, about what happens when contractors and vendors roll off a project and there is no transition, I was on a project where I saw the opposite happen. On that project, granted it was a smaller project of about 30 developers, the transition to the sustainment team was baked into the project plan from the beginning. The other thing that was different was that the project team and sustainment team were two different groups with different managers.

The manager of the sustainment team essentially would not agree to take on supporting the new application until a proper handoff was done. By the time the new application went live, a very smooth transition was done to the sustainment team.

This project was an Agile project, specifically Kanban, but regardless of being Agile or not, a smooth transition is important to the long-run success of whatever team is going to support the application.

Thoughts

So what are some of the factors that led to this smooth transition?

• We put together handoff documentation
• We had meetings with the teams that were taking over the application. In these meetings we went over the documentation we created and we discussed the application and infrastructure architecture and how to troubleshoot the application.
• This project had invested heavily in BDD, and when we handed off the application we had the functional tests running and green. Having automated functional tests is great whether you are handing off an application or the same team that built the application is supporting it. But in the case of handing off the support, if the automated functional tests are green in your CI pipeline, like unit tests, it tells the team members that they have not broken expected behavior, and the new sustainment team will have a sense of confidence.
• We had a clean product backlog with items prioritized. This made the transition of support after launch very smooth. Transitions of applications are often not just the application at a code level but can be at a Product Owner level, so having a clean Product Backlog matters.