Values and Principles

Last week I participated in a SAFe SPC 4.0 training. I was already somewhat familiar with the framework after previously attending a Leading SAFe training. After that I have been acting as a Release Train Engineer and heading a System Team for the past couple of years. But never the less, there's always room for learning more and the training was really good. Jennifer Fawcett has an overwhelming amount of experience and she's also really inspiring teacher. Maarit Laanti also shared interesting experiences from her past. I think these 'war stories' are always the most exciting content in any training.

My interpretation of SAFe is a map or definition of a complex system. Or a collection of practices that can be utilized to bring structure to an organization. So I don't consider it as a silver bullet or a project model that should be fitted 100%. And then again, this is just one possible view out of many. Reader is welcome to use SAFe in any suitable way.

But please remember that SAFe and other scaling frameworks are just frameworks. What is really important is the people and interactions that take place within the framework. I find also values and principles to be more important than specific practices.

SAFe Core Values include

• Built-in Quality
• Alignment
• Transparency and
• Program Execution

If you find for example transparency to be sore topic in your organization, then SAFe won't help you out much. In the end you might come to a conclusion that 'SAFe is broken', although the organizational dysfunction has just been uncovered by the transparency. I think the same has been pointed out about Scrum.

Then the SAFe House of Lean contains the following pillars:

• Respect for People and Culture
• Flow
• Innovation
• Relentless Improvement

As we are all unique, we have different biases. I for one emphasise the first and last pillar most. For me one of the most important things is that people respect each other. This regardless of gender, race or title. Constructive disagreement is ok. It even drives innovation. But respect and trust should be in place. Then you can take a humble look in the mirror and start the relentless improvement.

I'm not going to repeat points of Agile Manifesto here, but I'd like to point out a bit less known framework. Trust, inspirational motivation, intellectual stimulation and individual consideration are the corner stones of deep leadership. It was taught in Finnish army's leadership training and it made a lasting mark on me.

Sometimes we get lost in silos. It is easy to mentally divide people to 'us' and 'them'. Seeing the other person as a human being with hopes and dreams may help to respect the other person. And remember, even though you think something someone else is doing makes no sense, it probably makes perfect sense to him or her. Our past environments and experiences have molded us and we all see world a bit differently.

My own management/leadership methodology is based on making things easier for others. Instead of sub-optimizing things for yourself, try to make things better for others. Do not make others wait. And increase transparency as much as you can. When everyone works according to this very simple rule, the combined results can be huge.

Importance of Environment in an Agile Transformation

I attended today a SAFe 4.0 event arranged by a Finnish training company called Nitor Delta. As a guest speaker they Michael Stump from the Scaled Agile Inc. The event was also a good meeting place for SAFe practitioners. I must say that I saw quite a few familiar faces. And met many new people who I can hopefully later exchange experiences with.

After writing a case study, my company has drawn a lot of attention from other (potential) SAFe adopters. I have a bit mixed feelings about it. Of course I'm happy and proud about the attention, but being a Finn, it's difficult to handle the situation. And then again, since I see all the daily difficulties we deal with, I sometimes feel tempted to say "..but we still face these difficulties". But maybe there's no need. I guess everyone understands that things are in reality much more complex than in theory.

From http://finnishnightmares.blogspot.fi

But from the conversations that I participated after Michael had finished his presentation I learned that environment matters a great deal in SAFe/Agile adoptions and transformations. First I was somewhat against the idea of training everyone at the beginning of the adoption process, but maybe my first impression fails me there. In some cases I think even training is not enough, but some people should get their brains totally rewired. I mean, if you have done something in the same way for decades (or even years), it could be overwhelming to modify your daily routines.

If I think about possible factors why the transformation was successful in our case, I could easily list at least a few. There was a big management support. Previous and current heads of R&D were supportive for the idea and also the Chief Quality Officer. I think also the CEO saw potential in the new practices.

We had already been trained in Scrum when the big organizational change was initiated. All developers had received training in Scrum essentials and every Scrum Master and Product Owner was certified. Scrum Master and tester Communities of Practice were also formed right at the start. So good practices had distribution channels.

Release Process was established even though at first we didn't plan the releases. But the decision to shorten the release cycle was made. Release Manager, a person who would facilitate the release planning and execution was also appointed right away.

Then I think a big deal of the change can be credited to a couple of champions. People who were in key roles (RTE, Owner of Software Development Process, Chief Portfolio Officer, line management of R&D) made big contributions. Having a vision of how things could be done was important, but just as important was the support from these champions. And finally the support and engagement of employees. Everyone wasn't eager to embrace the change at first, but enough many were.

During the conversations with other companies I have realized that there are other, more subtle things that supported the transformation. Some that I had never even thought of since they are rooted so deep in the culture and operations. The organization is not flat, but there are exceptionally good possibilities to access information, suggest new ideas and to participate in the decision making. Also the developers are treated as experts. And there's one company value that I hold in the highest respect: Enjoy Working Together.

In the development money is not an issue. I mean, there's no unlimited budget, but people in development get to fully concentrate on the contents. If something is considered worth doing and there's clear potential, it will be done. There's no sharing of the blanket between different business units. (I have never needed to worry about CapEx or OpEx.)

As a conclusion, I think there were quite a few things that made the transformation possible. Some are such that people living inside the system do not even perceive. In a way I'd be tempted to say they don't realize how lucky they are. So let me conclude my post with a few pictures.

Office Breakfast

Foosball table

Hackathon trophy

Loops of Learning

I'm currently reading a book about Organizational Patterns of Agile Software Development. In addition to the interesting patterns I was especially attracted to the chapter about anthropological foundations. The book also opened my eyes to see that processes alone are not enough. I've written about this before, but my view was reinforced once more.

Continuous improvement with processes usually only deal with Single-Loop Learning. We inspect the results of our immediate reactions and then make corrections. Usually this is ok for a team that is building software in iterations. It's about following the rules. But when we go a bit higher, it maybe isn't enough anymore.

The second level, Double-Loop Learning was introduced to me by the Lean Startup book. In that method we still make small modifications as often as possible to learn fast, but we also can choose to either pivot or persevere. Do we want to keep on chasing the selected goal or should we select another target? Already this felt to me like something really awesome. Someone has even described the ideas of Lean Startup as possessing super powers. (I wouldn't maybe go that far, but it's a good book.) On this second level we create more insights about our actions. It can be also characterized as Systems Thinking.

But I wasn't aware, at least consciously, of the next level: Triple-Loop Learning until now. Jurgen Appelo writes about it in his blog post and Thorsten Gragert's wiki site offers a nice a summary including the below figure. The 3rd level deals with principles. In organizational context I'd associate it with company values and learning about learning.

Figure adopted from www.thorsten.org

By digging a bit more I found this article about Learning organizations. Interesting concept. They have the following five main features:

• systems thinking
• personal mastery
• mental models
• shared vision
• team learning

I think I need to give this a lot more thought. And try to lead my organization further on this path. Maybe I will coin a term #BeyondAgile. :)

And finally, as a somewhat sidestep, I'll share a some tips I have spotted from many successful organizations:

1. Dream big
2. Hire the best people (who share your dream)
3. Stay out of their way
4. Share the success

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?