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!

Agile and Military Methods

"What? Dude, your out of your mind! Agile methods emphasize individuals and are cool. Military stuff is all about hierarchy, command and control. Yuck!"

Well, that's one view and I don't really argue about the hierarchy and C&C. But I do find a lot of similarities also. If you need to lead people in battle, the level of trust between you and your team needs to be high. You need to show example and as a leader you go always in first. Would be nice to see the other people following. Your people need to trust you and you need to trust your people. I believe that's a characteristic of efficient Agile teams also. Although in an ideal Agile team everyone is a leader.

And really army and the command and control part is not so black and white. Setting goals instead of giving specific instructions works best in both worlds. In software development requirements change and the only reasonable thing to do is to embrace this change. In his book Management 3.0 Jurgen Appelo summarises agility as

"Staying successful in ever-changing environments." 

In the heat of battle it is probably also safer bet to adapt to the current situation than to follow a predefined plan. US Marines and special forces like Navy SEALs operate with small yet effective teams with no centralized control.

The final example is maybe a bit more far fetched, but maybe just for amusement. If you are familiar with close-order drill, you know that it is a training where certain action is trained repeatedly. After each command the trainer will give feedback about the execution. Now my boldest comparison is between these drills and Sprints/Releases. After Sprint, there is a Review where the results are inspected and the team should get feedback. Improving the actions of the team happens in Retrospective. Iteratively the team improves its execution. Only in this case the whole team acts as the trainer (Scrum Master can catalyze the process).

And finally, practice and discipline are the basic requirements in both. Real professionals keep their heads cool and write those tests before making changes! Regarding discipline, I think the people in software development should take inspiration from the world of military. Lack of discipline in implementation seems to be a common stumbling block for many Agile adoptions. I think the pragmatic programmers and Clean Code movement have understood the significance of practice. Mastery doesn't just appear. It is earned through practice.