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.

Leading SAFe

Since sharing personal impressions about SAFe trainings has become almost a norm in the field, I also want to stick my spoon in the soup.

I participated in a Leading SAFe training given by Maarit Laanti from Nitor Delta. After reading many rather critical blog posts about these trainings (actually they have mostly been about SPC trainings), I was very curious to get some first hand experience. Probably the quality of the class depends on many things: the trainer, the participants and the chemistry between the actors.

I was very positively surprised! We were given opportunity to ask questions and share our expectations at the beginning of the course. Some were more interested about the Portfolio level, some about the Program and the Agile Release Trains. Contents of the course were customized according to the participants' interests. I think all the questions were answered in a credible way and the shared real life experiences were the bread and butter. Maarit also demonstrated a very healthy criticism towards some of the contents. I don't give big credit to people who just preach without understanding what they are really talking about. I think our trainer displayed profound understanding of the topics she taught us about.

And (good) videos are always nice. I was already familiar with some of them like the Daniel Pink's video about motivation

and Henrik Kniberg's excellent animation about Product Ownership,

but for example the video about Deming's willing workers and the effect of the system was a new acquaintance to me. Served as a good eye opener.

In the end, Leading SAFe course (and the Scaled Agile Framework) includes topics about Scrum, Lean and Systems Thinking. The highest Portfolio level doesn't seem to be that mature yet, but I see that and some of the more prescriptive parts mainly as extra tools. If you set those aside, the rest is something that not many Agile gurus (= people who manage to stay successful in ever-changing environments) could have anything against.

Sami Lilja has criticized that scaling in itself is solving the wrong problem. But I don't think people and organizations always have a choice. Decreasing the size of the system or splitting it into smaller pieces could be the ultimate goal, but personally I think having this toolbox at least helps to cope with the current situation in many organizations. Every path starts with taking the first step.

Owning Products and Owning Companies

In the corporate world mergers and acquisitions happen. A start-up first has a dream which the people working there actively pursuit. If everything goes well, there might someday be a financial success and possibly another company will decide to buy this start-up. This might take a short time or a longer period, but the fact is that most start-ups fail to see this day all in all. But what does this have to do with Agile? Maybe something, let's see.

I'm sharing here an example where I think an acquisition happened as smoothly as one can ever imagine. The buyer is not looking for a short term profit. They have a solid cash register and they invest according to their values. And they value quality and reliability over anything else. Getting dirty hands is OK. It's a sign of being a professional. You are ready to do what is needed.

I like to map things to a smaller scale because it's easier to apprehend. I think above mentioned acquisition compares nicely with a Development Team having a new Product Owner. And in this case the Product Owner is clearly stating that instead of feature creeping, the PO is more interested in getting solid increments of working software. What more can a team ask?

The bought company will also stay independent and can continue operating as they have done before. Talk about empowering the team. And this message is delivered by a very senior executive with a background in culture where losing your face is avoided by all means. And he wants to deliver the message personally because he sees the face to face interaction as a must. I think that builds trust.

Just a few hours after the announcement the people in the company are able to carry on their work and with a rather high spirit.You know something has been done correctly. Or at least not totally screwed up.

Build trust. Empower teams. Strive for quality over quantity. Envision the shared dream. These things scale.

Agile Poem

This time something completely different...

Let me amuse you for a while

and let's talk about Agile.

In this game if you intend to win,

you need a lot of discipline.

World around you changes,

you meet unhappy faces.

But you can still do great

just start small and then iterate.

You can occasionally even beam

if you have a trusted team.

And when assessing results do take care

the only measure is working software.

Telling like father to a son:

it's not finished until it's Done.

And the only solid fact

is that you need to inspect and adapt!