Image Courtesy: The Daily WTF
A little over a year ago I became the team lead for a software team in a company that specialized in government contracting, and in particular the US Army. The company had been awarded “CMMI Level 3” compliance, and that was good enough for the government; but unfortunately CMMI doesn’t mean good software. It just means a reliable process was involved, even if it’s a crappy process.
Before I took over as Dev lead, our development cycles were 3 months from prioritization to delivery, with the product being a .NET 2.0 Winforms client. We spent a lot of time responding to customer requests (aka putting out fires), and when we weren’t doing that, we were planning. Lots and lots of planning. Planning is almost a pastime in government contracting. The planning also fails, consistently. Plan for 3 months away and in a month we found out that everything we had planned for had changed.
You probably know where this is heading. I started to institute agile within my team. Our meetings had been weekly meetings that lasted two hours and included people from other teams who were not acting in a supervisory role but were supervising. They included minutes, and they included the on-site customer rep taking every little thing we talked about back to his hierarchy. In short, they were useless. Those meetings were the first to go; and in their place was the daily standup. 15 minutes, 3 questions and we were done. I built a virtual kanban board that pulled the data from our bug repository, and we used that to keep track of where everything was at for the release. Having no formal agile experience, I didn’t know where else to go from there. The rest of our organization (1 other dev team, plus a QA team and System Engineering team) were still under the previous constraints, and because of the pain of our release cycle, there was no way we’d release code faster than every 3 months… unless we changed the rules.
Change the rules I did. I found a way to be able to update the clients without new installs (Click Once was a no-go, due to customer ‘concerns about security’) in RemoteApp, and it also alleviated the load pain we were feeling (due to complex object graphs serializing using .NET Remoting). So I started to push for this upgrade; knowing it would pave the way for us to be able to shorten our feedback loop from the time we found out about a problem until we were able to release a fix for it. It also meant we’d be able to deploy features much faster and get feedback on them much faster.
In the meantime, the project suffered from the same problems it had before: poor communication through ‘official channels’, feedback not being given or received in a timely fashion, and features the users didn’t want or need. In the end, we didn’t communicate enough to the customer about all of the ways to improve the software or the problems with the approach we chose. We failed to communicate, and we For all my efforts, I failed to make the project better.
I failed because I didn’t put the feedback first. Agile is first about feedback. It’s about that communication loop between the people that use the software and the people that create it. Before the technology, before the kanban board, and before anything else, the communication has to be fixed first.
We didn’t have communication across teams: Our teams were silo’d so that only the QA lead would talk to QA guys, the Sys-Engineering lead to the System engineering guys, and the other Dev lead to his team. I even exhibited “Don’t fuck with my territory” behavior. We were scared, we were defensive, and we didn’t knock down the walls that keep that feedback loop from happening.
The easiest thing to do is to improve feedback. Improve feedback by cutting the planning the release cycle, improve feedback by mixing the teams. Improve feedback by shuffling management around, or abolish it completely. Get rid of anything that hinders actual honest-to-god communication. That includes punishing people when they do speak up. Punish people when they’re disrespectful, not when they’re vocal.
Looking back on the many failures in that project, feedback was the worst, and it was also the easiest to fix.
Agile fixes communication in multiple ways, the first is that it requires cross-functional teams. A team in the Agile world is made up of the customer, the developers, QA, the scrum master, and any other business representative that has a stake in the process. Secondly, Agile mandates constant communication to the customer and to the rest of the team about the state of the project. It improves feedback by limiting the scope of work to what can be delivered in two weeks. The most a team can ever be behind what the end-user wants is two weeks, instead of the three months we were previously. It also does away with those fiefdoms that crop up in silo’d organizations. It may not be the answer, but it is a better answer than the status quo.