-k.

I bumped into an old friend in the pub the other day. We started talking and she told me about a retrospective she’d recently been involved in after the project she was working on had been suspended due to yet another management restructure (there have been several in the last twelve months). A large number of people from the business and the development group were in attendance. Her team of four developers was there along with the architect who had created the solution architecture and the non-functional requirements and the project manager. There where one or two people in the room she didn’t recognize and she assumed they were from the business side.

Introductions were made and she was surprised to find that “John” had worked on the project reviewing the architecture. She had never encountered him and had worked closely with the solution architect, who’s eyes seemed to roll when John introduced himself. Still, she knew that the architecture had been through a number of reviews. She’d bounced a couple of architectural decisions that had sprung from these as non-functional requirements for business approval as they had had the potential to significantly increase the amount of effort required to produce the system without adding any direct business benefit.

As in most retrospectives the meeting was an attempt to extract lessons learned while delivering the project in order to improve the process in the future. The meeting was going well. Many of the positive items where directed directly at her team and she was proud of the work they had done. She was surprised when one of the people she didn’t recognize began to raise issues around the clarity of the projects purpose. She’d been working with the business on a daily basis and, although the requirements had been subject to some change and clarification, she had never felt that the projects final goals were unclear. “How can you even begin to develop a piece of software without a vision statement?” True she’d never seen one, but the project wasn’t really rocket science and she thought the objectives of the project were clear.

True, they were running behind scedule. This was due, in the majority, to the restructure and a freeze on resources. She had a project team half the size she’d been promised with a higher proportion of junior developers than had been agreed. Another contributing factor had been the toolset mandated by the architecture team. When early on in the project she’d queried the reasons that they needed to use a particularly painful tool. She was told that it was vendor “A”s product in the space and we only use vendor “A”s products.

John continued to insist that the project didn’t have enough governance. He insisted that the project needed more rigid processes. He failed to understand that the project delivery team hadn’t failed and my friend took offense at the assertion they had because there wasn’t a huge paper trail of ill-informed sign offs.

The business side of the project had been very happy with aspects of the system they had been able to preview. That the project had been put on hold due to a restructure was not in any way a failing of the delivery team, but John continued to prattle on about roles, responsibilities, more detailed task reporting on time-sheets and an interesting observation that if you have half the number of development resources the spend rate would be 50%. “We’re not even CMU level 0” he exclaimed, confusing everyone until the project manager corrected the term.

We had a couple of drinks and laughed and wondered how far they would progress down the CMM track before they realized that people interacting was more important than process they employ. “No matter how rigid a process you have, a monkey will still play with its shit.”