Adequate Introspection as a Growth Enabler

After some recent conversations with my colleagues, I'm more and more convinced that identifying and accepting flaws in one's own behaviour and skills is a big requirement for self-improvement. During my life I've met multiple people who tend to find the reasons for failures always from circumstances, environment or from other people. This might be a good psychological coping mechanism for safeguarding one's self-image, but it's also pretty bad for self-improvement. People who do not find anything to improve in their own actions rarely do anything to do things differently. Because why would they? It's the other people who should change.

 

Life is hard if you cannot trust others. 

This might also be related to trust. Probably it's not a good strategy to admit and advertise your weaknesses to people that you do not know well. They may use that information against you. That's why building trust is also key for unlocking personal and shared learning possibilities. 

As an example of how things could optimally go, let's think about a well functioning team. When people trust each other and are ok with showing their own vulnerability, they can expose ideas or plans to others and get feedback.When everybody knows that the team is building something together, it's no longer about individuals and their ideas. Ideas are criticised, bent and stretched and built on top of each other. When the best possible solution is found as a result of combined effort, everybody benefits from understanding it. And everybody grows and learns. This is the one of the biggest benefits of well functioning team.

 In a well functioning team people collaborate.

But everything starts with trust and safety. People need to be able to be vulnerable and tell if they do not know something. If they need to wear a psychological armor all the time, (working) life is hard. As a leader you can enable trust by leading by example. Trust others. Tell if you don't know. Ask seemingly stupid questions (that often are not that stupid. No-one else just dares to ask them.) Before you can trust others, you need to be in peace with yourself. And admit that if things that you participated did not go perfectly, maybe you need to do something differently next time.

Complexity of Multiple Development Locations

There are multiple reasons why companies spread research and development activities into multiple countries. In some smaller countries it might even be that the job market is not big enough to cover all the needs or that at least talent is really hard to find. That's why it is many times natural to spread activities to locations where the talent pools are bigger. Also the salary level can be a tempting factor especially in cost competitive countries, like India.

But there are certain challenges that are good to keep in mind before taking the step. I have no hidden agendas, my intention is to simply state some things that you might want to consider before starting activities in a new location.

Time-zone differences are good to take into account. Of course they can even be a positive thing if you are looking for 24/7 response times in services and you need to follow the sun. But if you are attempting to have distributed teams (members in more than one time-zone), they will have a limited number of common hours. There are some 'sharing the pain' approaches to this, but none the less it's a real challenge.

I think that if at all possible, people who work together should meet face to face at least in the beginning of their common journey. That helps to build trust and makes the team work easier. It's also easier to explain things and build understanding while being physically close. While this is nice, it will of course create some expenses when people need to travel. Again by far no show stopper but something to consider.

Having multiple development sites has an effect on the communication also. With one site you can rely mostly on physical boards and getting people together, but with multiple sites you need to have proper technology. Things like online backlog tools and communication software become a must. And I think many will find chat tools like Flowdock or Slack beneficial. Internet connection speed will also prove to be important. This depends also on your products, but if you need to transfer gigabytes of data there's a big performance penalty if moving files takes hours rather than minutes or seconds. Thus the local infrastructure also plays a large role.

Job rotation pace also varies between countries. Somewhere it might be possible to stay with one employer for the whole career (maybe not realistic nowadays anymore) whilst in some countries people tend to switch jobs every couple of years. If employee turnaround is really rapid, tens of percents annually, building silent knowledge might be difficult. I mean such information that slowly accumulates while you learn more and more about your field. I think rapid job rotation is also where bad for good team spirit. It's not easy to build trust between people who often change.

Cultural differences should be also taken into account. Countries differ in many things. For example Finland, USA and India are really different. To better understand one another it is good to study a bit what kind of things are valued in the other culture. One nice site to check the differences between nations is here. There you can check how the six pre-selected factors differ. It might explain why your colleagues behave as they do.

Inflation rates are also really different between nations. For example in Finland the tech salaries are high, but there's hardly any inflation. In India it's vice versa. Salaries are in general smaller, but they are raised in bigger chunks and more often. And one of my guidelines is that in the global economy talent is cheap nowhere.

Final thing that comes to my mind is the local laws and amount of bureaucracy. I guess many times the amount of bureaucracy can be bundled with the amount of hierarchy, but that's just my assumption. (What I mean is that if you always need to get bosses bosses boss's signature, you are probably in a hierarchical and bureaucratic setup.) Having a local representative who knows the culture while starting activities up is probably priceless.

Well that was my not so short list of things to consider. Topics are not in any specific or prioritized order. But hopefully they will be useful for people who are pondering about spreading activities to new locations. Make sure you understand the challenges. Some are just risks that may or may not realize, but some of these you will encounter for sure. But if your plan is clear and you are doing it for the right reasons, you have a good change to succeed.

By the way, if you are academically interested in the topic, you might want to check out DD-SCALE project.

Using Scrum for Strategy Work

I'm continuing with the same subject I wrote about last week. Repetition is key to learning. And another important way to make things stick is to tie new information to previously obtained knowledge. At university I noticed the same thing with equations, groups of equations, matrices and linear operators (and functionals). Once you study enough maths you see how beautifully many things are connected...

But getting back to the point. I'm participating in our strategy work. Probably going into details about it would be wrong in so many ways that I won't even consider such option. But I think the (Agile) process how we are producing the new strategy is so interesting that I'd like to share it.

One way to produce a new strategy is to assign the task to a couple of persons. Then they spend some time (X months) to gather data and make relevant analyses and present resulting strategy to CEO and/or Board. Then the strategy might be accepted or some modifications are requested. Process is effective, because the people working on it don't need to negotiate much and they can move fast. On the other hand, the result is produced by the mental energy of only a couple of people. And these are also the only people who know the new strategy at the beginning.

In our case the work is split into work streams. Each work stream has an Owner, a Facilitator and a dedicated team. Teams produce their own piece of the general strategy puzzle, but they need to make sure they are aligned with the other work streams. This is achieved via cross-team communications (which is always non-trivial) and facilitated through weekly Facilitator Calls. Teams also have regular sessions when they all meet, present their current findings, challenge each others current results and generally push each other forward. This is also a session that feeds the overall strategy which will be the crystallized result of all the combined efforts.

If you have used Scrum with multiple teams you might spot some similarities. I think the work stream structure is a one-to-one match with a Scrum Team. It contains (Product) Owner, Facilitator (Scrum Master) and a (Development) Team. The Facilitator Calls are like weekly Scrum of Scrums sessions that are used for cross-team synchronization. (Of course this close relationship with Scrum is not that much advertized.)

I can't think of a good Scrum match for the session that combines the results of the different work streams, but there's one in SAFe model. These regular sessions bring to my mind System Demos. All in all the work is like traveling on board an Agile Release Train. The end result will be full-fledged strategy that is already well understood by the people who have been crafting it. And although this probably costs the company a lot more in the short term than a strategy crafted by only a couple of persons, I think it's a clever investment. If we have N work streams with M members, it totals N x M people who are already quite familiar with the new strategy. I think that is already a really nice sized Guiding Coalition.

And maybe still one thing that I want to add (because I'm so proud of it): the strategy process is out there in the open! Not in the basement, nowhere lurking in the darkness. Anyone is free to give input. People are encouraged to discuss and even the meetings are held in open space. Transparency. A cornerstone in Scrum. To me it signals trust.

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. 

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.

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.

Children are Excellent Teachers

I recently had a discussion with my son's kindergarten teacher and she told me how my son's group has been teaming up very nicely. They play together and everyone has found their place. Some are carrying sticks, some build things from those while some of the others are more involved with the planning. When, inevitably, there's conflict, they say they are sorry and the situations resolve quickly. And when they do sports, everyone is rooting for the others like crazy!

If preschool children can do this, why is it so hard for us grownups?

When the organization is still going through the agile transformation, it's probably not uncommon that people only think about their own tasks. "I have done my part. It's not my fault if the others don't keep up." But in an cross-functional Agile team you are not merely accountable for your tasks. There are no "your tasks". The team has goals and the team members are ALL equally responsible for the results.

This will probably become clearer over time. But in a bigger organization, I'd like to reach the next level. I see an analogy between one team and a Sprint and between several teams and a Release. My personal vision of a larger organization is such that teams working on the same product pull one rope. If one team is struggling and the others have finished their commitments, they will help. No team is left behind! And maybe in a larger organization this would scale up still one level, but I have no first hand experience about that.

Great things are achieved through doing things together!

Respecting Other People

I think one key ingredient in forming a working team is the respect of other people. People may have different skill sets and they may live in different countries. For as long as we see each others as individuals and equals, we can achieve great results.

I think some people, and maybe more often people with academic backgrounds, have a tendency to look down on others. With distributed or virtual teams this is even easier than in normal teams, since you don't have to see the others face to face so often. It is easier to start thinking about "us" and (or even versus) "them".

I would place respecting individuals and trust as the top characteristics to look for in people who are supposed to work in multinational distributed teams. And of course willingness to learn. But that's probably a must have in knowledge work anyway.

I think in a Scrum Team the Scrum Master should be the champion of these values. Constantly showing example of respecting others. Architects or newly graduates, it doesn't matter. Everyone in the team brings their contribution and help pursuit the common goal. And everyone deserves their place.

Live as if you were to die tomorrow. Learn as if you were to live forever.

Building Trust

One thing that I find very interesting in Scrum is the fact that the Scrum Master doesn't have any power over the team. So there's genuine need to persuade the people. Motivate them and get them to do things through leadership. And I think this lack of power is the key in expert organizations.

In case you are dealing with complex products, you probably have very intelligent people working with you. And usually those people know their value. If you boss them around and manage them too tightly, they will just pack their things and move to another company. So you need to have a light touch. Leadership is required.

And I think one key thing in leadership is building trust. Let's say there's a building on fire. Everyone is exiting the building in a rapid fashion. Who knows, the building might even be collapsing soon. But there might still be people trapped inside and they might need help.

a) You are always telling people what they need to do. They don't usually like it and people talk behind your back. You don't care since you get the job done. Who cares if you have to cut a few corners or lie in a couple of places? And if you hear something useful, you usually take advantage of it without thinking about others too much.

b) You always treat people with respect. You see others as persons who have their own hopes and dreams. And you realize you spend a lot of time with these other people, so you like to make sure you all enjoy your time together. If someone needs help, you offer assistance. When someone tells you something private, you don't spread that around. And every time you are true. Whatever happens, people know that you are telling the truth.

Okay, there are now these two persons: a) and b). Which one would you follow into a burning building?