2011 was a good year for me as a software development consultant in Stockholm. I terminated my long-running contract at a major nordic bank before the summer holidays. This turned out to be very timely, since just after that, work in the project was severely cut back.
Around that time I got a new contract with one of Sweden’s biggest travel companies as a “BDD coach”, which basically turned out to mean XP coaching and Scrum mastering together. It has been great fun and will continue into 2012. This assignment does not entail much programming but still lots of challenges. I am quite thankful for the switch and especially the timing.
This post is a summary of some of the things that I have observed and learned during this last year. Some of the things I knew before, but have been confirmed again. Other insights were new to me. Most of the things I mention are not technical in nature, because I think that would be less entertaining to read about.
It is next to impossible to transform a silo organisation from the bottom-up
This will come as no great surprise to seasoned agile coaches, but it may be worth repeating. You may certainly have a lasting, positive effect on the developers and teams, which is great, but on a higher level or on the bottom line you are actually not accomplishing much.
My attempts these last years ended up with something similar to “water-scrum-fall”. Requirements came from people in other departments, who were reluctant to participate. Operations were handled by an outsourced company, which gave them very little incentive to do much work at all. They were difficult to talk to and every delivery had to be scripted in minute details and with ridiculous lead times.
Not all large organisations are the same
I have a tendency to lump all large organisations into the same bucket (marked “dysfunctional”), but I’m not sure it has to be that way. Some large organisations have more distributed power, more collaboration and are generally more pleasant to work in than others. Of course, all large corporations contain dysfunctions and systemic wastes, but some seem to handle it better than others.
One of my customers has sister companies in all nordic countries, but there is no web czar to manage it all. Instead, there is a web council with regular meetings and coordination. And when there is a crises or an important decision facing them, they call a large meeting where multiple views and perspectives are heard until the tough decision is obvious to everyone. Much better.
Hiring people for their attitude opposes improvement
Most companies claim they hire people based mainly on competence and some on their social skills. This year I have encountered a company that does the opposite, they hire people mostly based on their attitude and expect to train them on the job. The upside of this is that the staff is generally wonderful, easygoing people. Each problem is viewed as an opportunity. In a crises, when they come together, they can move mountains.
One possible downside with this, though, is that everybody is a relations builder. This means that people will spend their days being nice and forthcoming to each other, which unfortunately also means that they will often hold back criticism, feedback and challenges. But that part is important at times. Where everybody is a “yes man”, there is also difficulty to challenge the status quo.
Recruiting managers internally is not all good
I always encourage recruiting people internally. I think there is just a bit of an advantage to have managers that actually know something about the work they oversee (strange, huh?). On the flip side, though, you may end up with people in positions where they are in over their heads. This year I have met architect astronauts who did not know the first thing about software development and never actually went to the IT department physically. I also encountered a project expert who had never heard that multiple deliveries during a project might actually be a good idea. It is both painful and embarrassing to watch these people trying to stay afloat.
Never get too comfortable with your position
Experience is invaluable but it can also be catastrophic. When you’re experienced consultant there is always a risk of underestimating situations. You have seen it before. You know what will happen. You count entirely on your personal abilities that have taken you through so many difficult situations before. You feel there is very little need to change. You know your thing and it always works.
Until it doesn’t. When things change quickly under your feet and you are busy talking and joking instead of listening and reflecting. Suddenly, it is clear to everybody else that you can’t cut it in this new world and you’re out on the street. This happened to one very experienced project manager I know.
Office seating is a radioactive topic
For some reason, changing the furniture or rearranging office seating seems to be the most risky decision any manager can take and to be avoided at all costs. I heard of one office seating rearrangement this year, where some people actually screamed insults at the people responsible for it. Other people simply refused to work, like little children. I have also failed on two occasions to get organisations to replace their furniture; unsuitable for agile practices like pairing.
The best excuse I heard was that the office furnishing was outsourced and, hence, could not be changed. Outsourcing office furniture seems reasonable since these products are basically commodities, but I think this conflates two separate things; the manufacturing of office furniture and office furnishing. The latter, being a context-dependent, creative service is not easily outsourced. By outsourcing furnishing, it became more important that all departments look and stay exactly the same instead of staff having facilities suitable for their type of work process.
Agile project management is basically an oxymoron
Agile project management is a very difficult and sensitive topic. Yes, most projects still need a project manager, even agile development projects. There may be valid reasons for this, for example the coordination of marketing efforts on a major release, but the two main reasons I see out there are not valid nor insurmountable.
The first reason is the way work itself is organised – in projects. The project model is powerful but is riddled with waste, sub-optimisation, and command-and-control thinking. Secondly, agile projects today typically live in non-agile contexts, which leads to a lot of synchronisation and negotiation between the two models. A truly lean/agile company would not suffer any of these flaws and, hence, need very little of project management.
Of course, there will always be a need for coordination, stewardship, and leadership, as in any effort, but the project managers I have met rarely understand their role in an agile environment.
The scope of budgetary madness is endless
I keep returning to the madness of budgets as a way of controlling spending in an organisation. Most consultancies are quickly aware of the importance of company budgets. I was positive, before the year, that we would see less of this, thanks to modern management movements such as Radical management and Beyond budgeting. However, from my point of view, it seems to be getting worse.
This year I heard of one instance, where budget constraints for next year were “met” by asking suppliers to invoice early, before the end of this year. Right, that’s 5% “saved”. I have been told horror stories of end-of-year budget corrections, where managers and employees spend much of their time during the last months of the year adjusting time reports by shifting hours from overdrawn projects to projects that still have “money left”, thereby removing the chance of actually learning something from all that time reporting. It’s just a game that everybody plays. I have seen one project suddenly put down because of “lack of budget” in a company that made a 949 Million EUR profit just the quarter before. On and on. When will the madness stop?
CQRS and Event sourcing
Technically, this year has been less rewarding. I re-started my Clojure effort, but failed to continue once again. I think I need a real assignment to really get into it. The TDD in Clojure course with Brian Marick was good, though. TDD in C# with NUnit and Specification by Example with SpecFlow are two areas where I have learned a lot, not having worked with .Net technology that much before. Most rewarding has probably been learning more about CQRS and Event sourcing, mostly from creative design conversations with project colleagues.
Personal failure: Avoiding giving feedback
Reading my work journal from 2011 it became clear to me just how I have avoided giving people negative feedback in delicate situations. It seems my basic strategy is just to put my head in the sand and hope for the best. I am not alone in avoiding these talks like the plague, but in my book that’s not good enough for the kind of consultant I wish to be. Feedback must be swift, private, and non-threatening. I resolve to practice this at least three times the coming six months.
I wish my readers all the best for 2012!