3 January 2012
Learnings at Work in 2011
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.
19 December 2011
Breaking through the Wall of Release Mediocrity
In my last post I discussed the problem of overestimating the quality of your software development and release process. In that scenario the time period allotted for a release is simply too short for a successful result. Of course, you can go wrong the other way as well.
Let’s say that you are the new configuration manager at a small software house. The managers feel that their release management is conducted a bit “ad hoc” and they have brought you in to restore order. You, on the other hand, Mr Big Shot CM, have been trained for years on how to perform professional release management at the big enterprise with lots of engineers. Real engineers, mind you, not fakey information ones. After you have assessed the situation you dictate that releases may only occur at most twice a year with a two-month stabilisation phase each. The developers shake their heads, but you are the professional so hopefully you know what you’re doing.
Let’s think about it, was this a wise move? Yes, this probably makes releases more regular and dependent (for a while at least), but is that really something the customers have requested? They will get their software later. The organisation will also have to take on the challenges of coordinating big batches of work and a lot more work going on. This is unnecessary work and costs money. So maybe the only thing you managed to create with your “professional” release process was a loss of customer and business value?
16 December 2011
The Agile Wish
Update: Apparently, the idea that iterations may have to be prolonged if your process is not advanced enough, was given to me by my colleague Måns Sandström in 2007, which I did not remember as I wrote this post. I wish to correct this and give thanks for that insight and many others, Måns!
You are the lead developer of a team writing a new, enterprise-wide web application and you are finally getting close to release. The project manager has done what he could to push those last features in. There is just one week left for acceptance testing with stakeholders and the week after that, you’re supposed to be live. It sounds tight, but doable.
But there are problems up ahead. (You knew that, right?) Annoying bugs keep appearing. As the acceptance period starts, change requests arrive. Lots of them, actually. By Wednesday you have so many RFCs that you actually feel it would have been a great idea to store them in TFS instead of on index cards. (In case you don’t know TFS, that basically means you’re panicking.) Bug fixing is frustratingly slow. Some fixes seem to create new defects. By Friday, you taste the bitter fruit and delay the release “indefinitely”.
As you go up to the business guys the Monday after, you realise, by their frosty stares, that you are now persona non grata. They really hate you. Who can blame them, really? They bet their careers on you and promised their bosses that this new thing would redefine “awesome”. But it didn’t and now you’re done for. You think to yourself, “It’s not fair!” You just wanted to help. You did your best. How on earth did you end up in this mess?
31 October 2011
Threatened by Extermination: Swedish Leadership Style
LESS 2011
The first day of the LESS 2011 conference is over. I am sorry to report I am not ecstatic after the first day. There were some nice talks and some not-so-nice ones, which is to be expected, but generally I felt that the speakers spent too much time on discussing models instead of working hard on making their talk come alive and be interesting and understandable for their audience. As J. B. Rainsberger (@jbrains), a Canadian master developer, put it one of tweets during the day: “Speakers, please tell me stories. They entertain me more, and they help me understand more”.
There is much to say about the topics of the conference (Organisational Transformation, Lean & Agile Product Development, and Complexity & Systems Thinking), but tonight I am just going to settle on reflecting a bit about something that the last speaker of the day, James Sutton, author and software-systems architect, said in passing during his keynote. He mentioned that from what he had heard about management and company culture in the Scandinavian countries, they were much further along than in other countries. Basically, what he implied is that the these countries have a more sophisticated style of management. Less command and control and more people-orientation.
16 October 2011
Experimenting with Daily Standups
The Importance of Format
I have been doing morning standups for many years now. For the most part I really like them. At their best, a team can find a peaceful place to talk honestly about the work, get a quick and accurate feeling of where they are and a feeling of being in the same boat. On the other hand, at their worst they can feel corny, pointless, boring, like reporting to a manager or just something we are supposed to do.
Why does it work sometimes and other times not? Mostly I think it is about the people, their relationships, and the company culture. A broken team conducts broken meetings. The facilitator is another important factor. For example, if she cannot guide the team in finding a fruitful path between skimming over problems and irrelevant detail, the standups will feel pointless or dull, respectively.
Finally, I do believe that the format of the meeting plays a significant role as well. Think of it this way: If you knew there was a format that would increase the likelihood of that great experience and minimise the time spent in the bad one, would you try to find it? I really want to urge people to experiment more with your standups.
