3 years ago I was contracted by ABN to build what ending up being a sales portal for their Fixed Income Business Unit. The team started out with just me on the sales side. I was both the Technical Architect and Project Manager and the team grew to 15-20 people by the time I left. So why I am telling you this?

I left because the team structure had evolved into something that I couldn’t work within. I loved the people, but when things are better without you, than with, you walk away. In the beginning, as the team grew I mentored and coached, held frequent team meetings to synchronise knowledge and status, we delivered frequently (despite clearcase) and were quite proud of our continuous integration build environment. The business defined value. We delivered it. The team structure was flat. Work was fun.

Then the business threw more work at us. Management reacted by adding more levels of management (sigh!). The team moved from a flat to a hierarchical structure. The once fluid communication with the customer stopped. There was a layer between us and them. My project manager hat was removed. I was purely technical architecture now (”thank’s very much cleve, we’ll take it from here…”). The team stopped having meetings. The team became individuals. The individuals reported individually to the new project manager. The team became dysfunctional in some respects but we had to continue to deliver software. That’s what we do. We just did it in a different way.

During this change in team structure, I fought to maintain the close collaboration we had built up with the customer. I fought to protect the team dynamic. I failed. The islands of developers (read as component groups) were formed.

Currently, I’m half way through a book by Ken Schwaber called Agile Project Management with Scrum. It is the book that I wish I had known about to give to my project management to read, to understand what I was fighting for and why it was so important to both the business and development teams. I basically failed to articulate the guidelines, practices and rules of Scrum in a way that made sense to both of us.

Ken, I take my hat off to you. The more I read about Scrum, its case studies and how ScrumMasters have applied it to the thousands of projects out there, the better I feel. I always thought it was mad to fight complexity (software) with complexity (high ceremony process and/or methodologies). Although outwardly Scrum appears simple (this is good a thing), its conceptual rivers run deep. I am looking forward to learning how deep…