Reading the book
I recently read Kent Becks Extreme Programming Explained. It’s a really good book, it took me some time to learn that though. When I started reading it I read it like this: Blahblah, Pair Programming, more blahblah, TDD, blahblah again, 10 minutes build, blahblah … Finally it came to me that I need to invert my focus. I don’t mean that those technical things aren’t important. On the contrary: they are the very essence of software development. It’s just that those practices aren’t new at all. They are simply the basics, as Jason Gorman put it. You can call them the principles of software development.
Hearing about agile
This isn’t the first time though when I heard about XP. It was back in 2006 when I was an exchange student in at TKK, now known as Aalto University. I attended to a class called Software Processes. It covered every known approach of this topic in 31 articles: there were papers about Waterfall, RUP, CMMI, Scrum and XP. Those who could speak Finnish, discussed them in the classes. The rest of us drew our own conclusions. It became clear that Waterfall is in favor for managers: it tries to fit software development to their decision-plan-execution process. On the other hand, agile methodologies (more about it later) accept the fact that software development just doesn’t work like this.
Note that I don’t hate managers. My wife is a manager too and it’s amazing how she can organize the things she does. She’s also the first reader of these posts and she points out many things to improve. Managers have an inevitable role in software development, although that role is different from the role they usually assume.
I wish I could tell that I was drawn into agile right after reading about it. Unfortunately this is not the case. In 2006 I wanted to have some sort of IT job and write poems in the rest of my time. It took me some time to decide that I wanted to be a developer. Actually, I wanted to be a good developer so I started to learn stuff. Among other things, I started to learn a few agile practices. For instance, now I know how to do TDD in a new project.
So what is this book really about?
So what is this book really about? This sentence got me: “Dictating practices to a team destroys trust and creates resentment.” Commanding people to write clean code just won’t work. Commanding them to write unit tests for setters/getters of entity beans will make them your enemies. Forcing them to comply to certain PMD rules makes them hate their jobs. XP is just not about it.
If you give it some thought, all those XP principles are about company culture – so is this book. Agile is not about methodologies, it’s more about attitude. (More about it here and on slide 55 on this slide show). However, it’s not only the agile movement who advocates autonomy at work. Daniel Pink wrote an excellent book about it: the Drive. No matter how we call it: agile, lean, ROWE: company culture matters a lot.
Such a work culture facilitates communication between the team members. It makes people trust each other. It makes people interested in their jobs. They will participate more actively in what they are doing. Which, in turn, makes people continuously improve the ways they are doing things. The XP practices are simply the result of this approach. An autonomous team is likely to customize those practices to fit their actual problem. Which is exactly what a company needs.
Individuals over processes
Whenever you’re building/joining a team it’s worth to check how much autonomy the team members can assume. Joel Spolsky suggests: hire smart people and give them something to do. This is rhymes with what the Agile manifesto suggests: Value individuals over processes. As far as I can tell Prezi puts great emphasis on maintaining such work culture. On the other hand, financial companies tend not to focus on this too much.
While I’m suggesting companies to give autonomy to their developers I’d like to uncover my motivations. Deep down inside I’m like an anarchist with little respect to authoritative figures. This is something I suggest myself to work on: No matter how much autonomy an organization provides, there will always be some limits.
Autonomy is not the only keyword here. I believe in collaboration too. Like the author of this article, I also think that teaching is a two-way street. I cannot tell how many times I learned something from somebody whom I was teaching/mentoring. When I helped new team members to gain their initial momentum I always found something that they did better than I did. One of them showed me how beneficial it is to organize the unit tests into given-when-then sections. The other guy showed me a way to eliminate boolean parameters, etc. Sometimes even a “wtf” face is a good feedback: you need to explain it more deeply. It might even require you to understand it more deeply. On the other hand, I find it hard to trust technical leaders who expect me to learn from them but they just won’t learn anything from me (except those who know everything that I know and believe in the same fundamentals I do).
Once again, culture and attitude
I could give you lots of hints on how to offer autonomy. But I won’t because each of those techniques are too easy to fake. E.g. I could suggest to ask for the opinion of your subordinates. However, if you ask them after you made your decision, then it just won’t work. Those techniques will work only if you believe that the team has good ideas on how to do the things they do. On a company level it is culture, on a leaders level it is attitude. These things influence software development more than I ever thought.