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.

Factory settings

Coding practices generally are not something that Scrum pays attention to. Also, teams should probably have  as few outside dependencies as possible. But there are certain support functions that can be centralized. Or at least we have.

We have one special team that takes care of our constant integration server. Automatic build scripts do the compilation and linking and run the unit tests. If the build or some of the tests fail after checking in new code, teams get a message automatically.

Each of the teams have their private playgrounds. In addition we have some integration builds that combine efforts of multiple teams. And some builds that generate data about code metrics: cyclomatic complexity, routine lengths, nesting level etc. These are extra services that save time for all the teams. And they can concentrate more fully on producing value for the customers.

This one special team handles also the packaging of the product. Putting together executable + manuals + creating installers. This knowledge is scarce so we have decided to do these activities by one team. Again, a compromise, but in a multi team environment saves lots of manhours.

If you are familiar with Scaled Agile Framework, this team would be called System Team.

Deep Thoughts

Some of the mnemonics from code writing work in coaching also. For example KIS = Keep it simple. Extremely good thing to always keep in mind. On the other hand, I think DRY = Don't repeat yourself doesn't work that well. Many times (well, always) repetition is the key to learning.

That's why I sometimes find it odd that there are so many different frameworks that basically teach you the same things you usually learn at the playground. Be polite. Say you are sorry. Play nice with others. Everything starts with the way of being with others.

Since we usually forget many of these important lessons, I'm going to mention here one framework that I've been especially happy with. It's called Deep Leadership and at least a couple of years ago Finnish army was using it in the military leadership training.

It's based on four cornerstones:

• Building trust
• Inspirational way of motivating
• Intellectual stimulation
• Meeting people 1 on 1

(I remember these only in Finnish so they could probably be translated in a better way.)

And although people generally seem to think that leadership skills taught in the army cannot be applied directly in working life, I'm a strong believer in this framework. And I think it's well in line with agile values and how I personally see that expert organizations should be lead.

The framework also includes extensive feedback from three directions: superiors, peers and subordinates. And you can never have too much feedback, right?

Scaling Scrum Beyond Teams

Our teams do Scrum. The lowest level of inspect-adapt-loop is the Daily Scrum. Above that are the Sprints that usually take one to four weeks. Most common is probably two weeks. This level is planned solely by the Scrum Team.

Our Sprints belong to Releases. We are currently satisfied with a pace of four releases per year. That means that a release comes every three months. With two week Sprints it means that we can fit six Sprint per one Release.

I know that in the most pure form of Scrum, teams produce each Sprint potentially releasable content. And there are probably no bugs. Unfortunately my version of reality contains a legacy product that has some known bugs. And since we have a long history and some dependencies, we really need to do some integration testing at the end of the Release cycle.

So we carry out an extensive Release testing at the end of each Release cycle. Currently we have reserved the whole third month of each Release for this, but the teams are free to use their best judgement on this. If they have everything tested in time, they can start new development already before the Release period is over.

The idea of four releases per year is actually taken from Scaled Agile Framework. We do not want to re-invent the wheel, so we rather use practices that someone else has found useful.

Release planning is carried out between Product Managers and Product Owners. Of course in the end the team needs to "accept" the plan, so we iterate until a mutual agreement is found.

Beyond the Release level are the Product Managers Roadmap and product Vision. And even above this is the Strategy. This whole setup is rather new, so I'll tell more once we have experimented a bit further.

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?

Communities of Practice

During our Scrum adoption we first started by assigning people to teams. Afterwards it's easy to say that it wasn't maybe the optimal solution, but it was what we did. There was not too much steering from above, so the teams were left to figure things out on their own. There are both good and bad implications from this.

Teams were free to choose how they wanted to do different things. On the other hand, the implementations between different teams could possibly vary a lot. But variance is good. Let all the flowers bloom!

After some time the Scrum Masters saw a definite need for collaboration. We had a Scrum of Scrums, which was first only for the Scrum Masters. After starting as the Chief Scrum Master I wanted to modify this practice slightly. I wanted all the team members to have access to the SoS, but the Scrum Masters could still meet on another forum.

This other forum was named Scrum Master Community of Practice. We meet weekly (and if something urgent comes we have an email group and a Flowdock flow) to discuss impediments that go beyond team boundaries. CoP meeting is also an excellent chance to spread good practices. I think this image by Mountain Goat Software gives a clear idea of what I think a CoP is:

Some approaches that have gained popularity through these meetings are Emergency Guy (one person puts down the fire and others can continue working uninterrupted) and more recently a practice that for each story selected for a Sprint every Development Team member writes at least one test. I'm especially fond of this practice, since it has quality assurance built inside.

Leadership is not telling people what they need to do. It's about helping them realize they want to do those things.

Starting the Journey

This blog will paint an image of a small to middle size software company on a journey from chaos to enlightenment. Inspired heavily by the books of Henrik Kniberg. Also, it will be my personal war story as I navigate through the stormy waters of change resistance and try to coach the organization to maximize the added customer value.

Maybe I'll first begin by telling a bit about myself. I have always liked mathematics. And for my whole adult life, I think I have enjoyed challenges. Either physical or mental. Due to my love of mathematics and also in pursuit of challenges, I went to study Engineering Physics and Mathematics. It was great! The guys who tell you that studying is the best time of your life, well... they aren't lying.

After university I started getting paid for solving problems. I did it via programming. My days were filled with adding more features to a legacy product, maintaining the codebase, fixing bugs, etc. I really liked it. But it didn't feel adequate. Something was missing.

During my studies I wasn't really interested in participating student association activities or other networking stuff. I was actually thinking that was more aimed for people studying industrial management and other business stuff. I didn't care about that kind of easy stuff. I was looking for REAL problems. I was young and stupid. (Nowadays not that young anymore.)

Things changed after I started my work career. I have always felt very strongly about people being treated fairly and equally. No-one should be judged by their looks or gender. If they act like idiots, then that's a different case.

Something clicked when Scrum was introduced in company. I was selected as the Scrum Master of my distributed development team. It was awesome! Then at the latest I realised that software problems are not where I get my kicks anymore. It's the people problems. Those are orders of magnitude harder than dealing with (in most cases) predictably computers. But as a Scrum Master I was removing impediments that were slowing my team down. And helping the team to realize how much power there is in a team when everyone is pulling the same rope!

That's how I started my agile journey. Next time I'll tell what happened then.

Take it to the team.