Mastering Motivation

Autonomy, purpose and mastery - three sources of intrinsic motivation. I have recently been reading Daniel Pink's Drive. I've been familiar with the concepts for a while, but now I finally obtained the book. Really interesting!

The truth about the drop in motivation due to monetary rewards is really surprising. I suggest reading the book, it is good. I won't pay you anything for doing that though. ;)

As a coach and supervisor, I'm really interested in motivation. I'm passionate about learning more about it and how to increase it. Agile methods have some of the sources of intrinsic motivation almost built-in. Self-organizing teams have autonomy to do what is necessary to reach their goals. Depending on where you work, your work may have a noble purpose (connecting people, increasing passenger safety at sea etc.) And as a software developer, if you truly take honor in your craft, you may strive for mastery. I'm actually very proud to use this video as an example of mastery. It was made by one of my talented team members.

As Pink states in his book, business doesn't always do what the science knows. It's not easy. Unlearning the old 'truths' about carrots and sticks takes time. And making peace with the fact that you are not in control. In software projects people have never been in total control. Better accept it sooner than later. Management can and should set goals and targets. If you have the right people and you support them and give them room, they will find a way to reach those goals.

As an example of 'walking the talk', I arranged a self-organizing workshop on renewing the Definition of Done. In my role I could just dictate the contents, but what good would that bring? So, instead I gathered a group of people and summoned them to a meeting room (or as this was a multisite setup, several meeting rooms connected via teleconferencing.) I explained the situation, showed them the current version and expressed the boundary conditions. I told them they were empowered to come up with a new version and I would accept it. Then I set the time-box and left the room.

I can assure you this approach has not been very common. But the results were great. When I came back after 45 minutes, I was handed a brand new Definition of Done. It was crafted by the people who will be using it in their daily work. As I had promised, I accepted the results. People were generally surprised how smoothly things went. I wasn't. Maybe I trust them more than they themselves. Most of them were my Scrum Masters.

Finally, I'd like to promote a very interesting article (unfortunately only in Finnish). It's about the culture at Futurice. It is a Finnish IT company that has been awarded as the best workplace in Europe twice. So if you know Finnish (or want to use Google Translate), I could suggest reading it through. 

Changing is Hard

I have come to the conclusion that resistance to change must be somehow built into us. Or at least it seems to be very natural. That's probably why there are countless of good and bad management books written about the topic. One of the best I know is Who Moved My Cheese? by Spencer Johnson. The plot in short is rather simple: there are two mice and two little people in a maze. Every day they go to a specific place in the maze to eat cheese. Until one day the cheese runs out and they need to adapt to the changed circumstances. Now I found out that there are even multiple videos made of the book. Here's one that I found:

Another short book about change management is John Kotter's Our Iceberg is Melting. This book is a fable telling about a penguin society. The penguins encounter a crisis when one of them notices that their iceberg is probably soon going to shatter. The book describes the steps for one possible way to carry out a change initiative. Amusingly, the reader may be able to recognize certain stereotypical (penguin) characters also in his/her own work environment.

Of course here I could pull Systems Thinking from my sleeve and simply say that it's the system that resists the change. The organizational culture developed during the years and the practices that people have gotten used to. Yes, true. It is the system that resists the change. And just like entropy, getting order to the chaos takes a lot of energy. The opposite happens without any extra effort.

In Systems Thinking management is responsible for the system, since they are the only ones who can modify it and change the rules. But sometimes it is hard to change the system even from the management direction. People are very reluctant to adopt to new ways and need constant reminding, gentle pushing and coaching. Repetition of the message seems to be really important. Otherwise people inevitably will revert to the old habits.

Books aside how do you carry out this in practice? I don't know. What I do is simply experimenting. Trying new ways of doing things and seeing how people react. Feedback is the key and sometimes a little provocation is required to wake people up a bit. And it is good to have a pragmatic colleague who pulls you out of your daily routines and reminds you to think about things that really matter: the big picture. (But it's so soothing to be busy and work on all those tiny details...)

Finally I'd like to share a video that tells about an interesting Agile organization. For me it could serve as a vision of where I'd like to steer my own organization. I think we are going to right direction, but Spotify has just taken a couple of more steps. Thank you Henrik Kniberg, you are an amazing fellow! (Also, just earlier today bought his latest book: Lean from the Trenches.)

Importance of Trust

It's fascinating how important trust is in Agile software development. It appears in many studies as a characteristic of effective teams. And trust can also be found as a decisive factor in whether distributed team succeeds or fails.

It's easier to trust someone you know. Even meeting a person once can make a big difference. After that one contact it is much easier to continue the conversation via some other tools like VoIP. That's the reason why even teams that are destined to work remotely should have at least some time under one roof in the beginning. This investment will pay off in the long run. (Face-to-face conversation is the best form of communication (co-location). )

Another place where trust is needed is the interface between business and development. (Close, daily cooperation between business people and developers.) The lack of trust from business can be perceived as too much attention into implementation details. Management should only decide what is being built and why and the teams should decide how it is built. It's also not uncommon to hear that developers are slacking off.

But I think the deal needs to go both ways. If the developers don't want business people to meddle with their work, they should provide them with visibility and concentrate on working on the issues that make most sense from the business point of view. Not necessarily on the things that are coolest, can be built with latest tools or offer the biggest mental challenges. Hopefully in many cases these can be combined and making the things the users need can be fun. But in reality this is not always the case.

To me, one essential thing in Agile software development is the acceptance of uncertainty. The only certain thing is the fact that things change. If you want to stay successful, you need to be able to adapt to different circumstances. And you need to have people around you who you can trust. Show them the direction and trust that they will find the way. (Projects are built around motivated individuals, who should be trusted.)

(The sentences in parenthesis are quotes of principles behind the agile manifesto.)

Finally, I want to share a wisdom my father used to say: "Trust is extremely easy to lose and very difficult to win back." Works both in business and in personal life.

Excellence as a Habit

I'm a big fan of quality. It's not that hard to understand that the user visible quality of the software is a necessity. If the customer is constantly disappointed, (s)he won't be a happy customer. And probably quite soon not a customer at all. But the visible quality is not all. Most of the time it's just the tip of the iceberg.

With software also the internal quality matters. How well your interfaces have been defined, how long/short are your routines and how much coupling there are between modules. If you know what you are doing (and you are the one who wrote that code) you might be able to navigate efficiently in a bit hairier spaghetti. But for the other non-swamp guide developers it can be much harder. Yesterday's code will be tomorrow's legacy. Keep that in mind.

But writing good quality code requires another kind of quality also. Quality in operations. Into some extent I believe this equals having skill and discipline. Again, I'm raising up the need for craftsmanship. For software development with multiple programmers and teams quality in operations includes also commonly agreed coding standards.

I have always found it much easier to define rules than to actually get people to follow those (although I'm usually working more in the implementation side than in the definition). People either forget, they haven't cared in the first place or simply haven't even been informed about the existence of the rules to begin with. So, there's value in both crafting the rules and in making people understand the value of the rules. Many times the rules are enforced by different actors than their creator, which is fine. Different people have different strengths. And finally: there's value in reminding people about the rules.

Systematic built-in quality in operations requires someone to take good care of the big picture. Practicing wishful thinking is not enough, someone also needs to see the evidence that agreed things really happen. Quality systems and audits are a practical way to see if the organization really plays by the rules it has set for itself. Some see them as heavy or bureaucratic, but frankly I think those people usually lack some self-discipline. If you play by the rules then someone watching over isn't hindering your progress. And if the rules suck, please help improve them instead of whining!

And it's also all so natural and fitting for Agile ways of working. Working software should be the sole measure of progress. And for example in Scrum it is shown at the end of the Sprint. Talk and PowerPoints are cheap, demonstrating new functionality rocks!

Instead of sometimes succeeding and most of the time being unpredictable, make excellence a habit. Learn the rules, break the rules, be the rule: Shu-Ha-Ri. And apply the same principle on all levels of the organization. Self-discipline is needed in the Development teams but also in the management. Dare not to expect something from the people working for you that you are not willing to do yourself. If you want people to walk the extra mile, be prepared to walk in the front.