“Agile workplace” is a red flag to me. I immediately start to worry if it implies that I am expected to participate in a lot of meetings and rituals, even though I might be on pins and needles to get some bug fixed, or to tweak this or that feature.
Is it just me?
Actually, I like the idea of making it easy and cheap to adjust and to correct directions. I’ve been working with software development in one form or the other for 35 years. I know full well that it is possible to do it in a rigid, heavy, and awful way, ensuring that as many people as possible suffer from anxiety. When I have been given enough influence, I have even nimbly arranged for things to be that way.
“Peter, can I talk to you about something?”
It was Mike, a senior developer in the project where I was appointed responsible for development. He was holding a book. A white book. This was the year 2000. Together with the entire development team, Mike and I had been visiting hell. In fact we were still there. I could not shake a strong sense that I was the one who had led, forced, us down here, kicking open the gates, ignoring the heat and the satanic stench that was greeting us. Right now I suspected that Mike wanted to confirm that worry to me.
Of course this was the case. Curiously enough, Mike wasn’t angry with me. He calmly, and with a friendly expression, relayed to me that I had just been scolding team mates who for months had been working harder and more than anyone had ever before been seen to work, in order to make “my” project succeed. He wondered if I wanted us to continue on the path I had brought us to, or if, maybe, I was ready to listen to a suggestion?
As you might have guessed, the book in Mike’s hands was Extreme Programming Explained, by Kent Beck. I can’t recall if Mike and I stayed to have this conversation in the room where I had just been letting my frustration hit the people who least of all deserved it, or if we took it outside. Regardless, we had the chat and I was now the one with the book in my hands. Mike's friendly objection, and sincere advice, constituted the genesis of one of Sweden’s first XP projects.
We did it By. The. Fucking. Book. Literally! Everyone in the development team was fully onboard. We all read the white book. I think most of us also read the pink and the green books too.
First priority was to refurnish. We even had a very large table built on site. Putting together many small tables, and also a few big ones, was considered, but we concluded that there would be too many legs in the way for us to move freely around the table and to sit close to each other. We were going to do pair programming!
Pair programming was one of the practices that I had to put up a small fight in order for our boss to allow us to try it. Something like that was largely unheard of in Sweden back then. Though, his resistance was not very hard. He was noticeably curious about the whole extreme programming move and he had faith in the team. I think mostly he was making it a small battle in order to harvest our arguments, so that he could defend to his bosses why he allowed us to let two people do the work of one. (Even today I still face attitudes like that, in case someone thought we had evolved as a species to a state where the people who have a problem are also allowed to design the solution.) By the way, this with two people doing the work of one reminds me: we also read The Mythical Man Month, by Fred Brooks.
Anyhow. We succeeded in turning the project. It happened gradually and was quite bumpy, with a whole lot of two steps forward and one backwards. But it was quickly apparent, to us as well as to our stakeholders, that the hellish march was over and replaced by a reliable string of improvements to the product. With time we had all 14 XP principles in place. We delivered value to the customers daily. Firefighting was now something rare. We were enjoying ourselves. Maybe most of my teammates even forgot about the asshole I had been. Be that as it may; they wholeheartedly forgave me. I could tell. And I had found a new faith.
Extreme programming or die!
My copy of that white book is very thumbed through and worn. I brought it with me when I continued my career, using XP as one of my most important tools. It always delivered. After a while it started to be referred to more as that we were Agile. I didn’t think too much about the label. To me it was always founded on the XP principles and to apply the ones which seemed to solve our most immediate problem at hand. Until we had it contained and some other problem was more pressing. Then we stopped and asked ourselves what principles and practices should now be taken into consideration. Rinse and repeat.
My enthusiasm for improving cooperation was hard to miss and our results invited curiosity. Somewhere on the way I started to work actively with spreading some of the principles and practices outside the development team. I just loved to tip-toe my way through the office, past the support, economy and marketing departments, in order not to disrupt their morning meetings, which were held standing up, out in the corridors. We were on the path to become an agile company!
Halleluja!
Maybe I contributed. Maybe not. But with time the direct results from the various tools I and others had incorporated had become less tangible, almost diluted. We started to confuse our actions to tackle the underlying problems with the principles that called for them. For example, I have participated in a lot of standup-meetings which have not contributed to – could not contribute to – increased insights around where the team should be focusing their work today, who needs help with what, or even why. Planning games, which used to be able to inform us about our possibilities and what risks we were facing, degenerated and derailed into meaningless arguments around details of which we did not have enough information. The plans started to get more important than the planning. The share of people whose work it was to manage and preserve the agile work practices grew. It was no longer driven by those who were expected to do the actual development work.
Somewhere along the way I started to realize that if I joined a company which labels itself as Agile, it most often means that they are super happy with the overarching structures dictating how they worked and that only local optimizations within provided, tightly protected, conditions are permitted. It meant that there were agile structures in place, and people employed to preserve the structures. In such conditions, every day a small part of me died. Little I couldn’t contribute to meaningful change when there were whole departments of agile experts deciding and designing how we should work. The rituals must be honored!
Demo! Retro! Standup!
Of course I still know that those could be good ingredients. I have seen them spark magic. Why do I get the rashes from environments where they are stationary institutions? Am I going through a process of backwards evolution, about to return in the shape of that asshole I had once been? Oh, I pray that is not what is going on. For my own part, I deal with the state of affairs by examining the organizations I consider working for/with. I ask more and I listen more intently. I ask targeted questions towards how it really is to be working inside there. I’m on my toes and wary of signs of rigid agility. My first screening sieves away companies that label themselves as Agile. That’s a red flag. I do not thrive with the agile yoke on my shoulders. It does not spark joy. I have shrugged it off of me.
Nowadays my work days are mostly about me doing what I want to do. I do great stuff together with others. Most of the meetings I participate in are booked because I or someone I work with needs it, not because the process needs it. It doesn’t even feel like meetings to me. Besides, they are not plenty. Most often I can just be coding away, sometimes alone, but preferably pairing, or in a group consisting of several stakeholders.
I feel good and I am having fun!
Peter Strömberg 
Peter Strömberg is an autodidact programming nerd living in Stockholm, Sweden. He has been all over the (coder) place for a long time. After some 20 years in the profession he made an attempt to leave it for another passion of his: Product. That attempt ended when Peter was introduced to Clojure and he felt how it gave him back all the joy of programming, and then some.
You can contract Peter for remote Clojure/ClojureScript gigs up to 80% of an FTE. The other 20% Agical pays him to spend doing open source work. Most often this is about maintaining Calva, a popular Visual Studio Code Clojure IDE extension which Peter created 2018.
- E-mail: peter.stromberg@agical.se
- LinkedIn: Peter (PEZ) Strömberg
- Twitter: @pappapez