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.

In Defence of Target Setting

I have read multiple blog posts about how bad it is to set annual targets and even worse to tie them to monetary rewards. I agree with most of those writings. But still I find myself motivated by targets.

Maybe this depends on how the targets are set. I see a sales budgets as a suboptimal solution (for the company). As a salesman, why on earth would you care how much it costs to develop something you sell? Even if it doesn't exist yet. And you can even give the customer a big fat discount. It's anyway better for you to close the deal than not to.

For sales teams I'd definitely like to have some targets that take into account the overall situation of the company better, the big picture. In addition to the money received from the customer, also the amount of work needed to deliver the product should be taken into account. Preferably the sales bonuses would be counted AFTER the product has been delivered and measured how much the sale really affected the bottom line of the company.

But let me get back to those individual targets that I was excited about. I can openly admit that I have plans for the future. In my role I get to actually affect the operations in my company rather much. I have a vision how I’d like to see things happen. And I spend a lot of effort to make that vision come true.

Then let’s say this vision is well in line with the overall company vision. Both aim to make the company profitable while delivering high quality and desirable products for the customer. In this case I see the target setting as a win-win deal. My internal ambition and the benefit of the company go hand in hand. That's why I have a good feeling that we will both will help each other out.

In short my message is: targets aren’t bad. They are like chainsaw. You can use one to cut trees or for a massacre. Let’s hope the chainsaw is in good hands.

Realism in Software Development

I have earlier written about how hard it seems to be to understand the reality in software development. This time I'd like to share some more examples I have either shamelessly copied from different sources or come up myself.

It is possible to create releases very often without taking them into deployment. Of course this is not something you aim to do, but it is somewhat easy none the less. There can be various reasons, but probably most common is some bottleneck in the process or in the interface between two processes.

If you have a conveyor belt that transports boxes, what will happen if you don't move the boxes away from the other end? They will pile up. Before you know it, if you don't stop the belt, you'll have a mountain of boxes. You probably react in time before this happens. (Also in software development you can utilize for example Kanban to visualize things and to identify the bottlenecks.)

Another example. Let's say you participate in a testing of a new mobile phone model. You get a brand new toy to play with. But then you find out there is a nasty flaw in your product. An irritating bug that destroys your user experience. Naturally you inform the manufacturer. And then they send a person to your home to fix your phone.

Or maybe they will not send anyone to repair it. Probably they will actually just send you another phone. With software products we sometimes don't operate as pragmatically. Instead of just sending a new version, we make a correction to the existing version. This is called patching. Sometimes it just cannot be avoided, but the need should always be carefully assessed.

Keep things visible. Aim to increase transparency. Think carefully about what is really happening and how you could tweak the system to reach a whole new level in efficiency!

Personal Communication and Decision Making

Individuals and interactions. Customer collaboration. I find it really hard to do that without meeting the other person. And if at all possible I prefer meeting them one on one. Or if that is not possible, I usually call using phone or voip. Why? Because it is so much more efficient than writing emails! ..or instant messages or anything else in writing.

I use such tools as JIRA, Lync and Flowdock quite a lot during my days. They are all great for asynchronous communication. And so is this blog post. But getting feedback for anything is a bit too slow to be really agile. Maybe one of the most frustrating features in instant messaging clients is to see that the other person is writing. Then you look at that and wait. If the other person has lot to say, you wait for a long time. But if you go and just have a quick chat it will all be done in no time. Simple and you get to do some nice human interaction also. I count it as a plus!

Well, you cannot always win. Sometimes the face to face conversations may not be pleasant. Sometimes you and the other person just disagree and there might be no getting past it. Or you need to give the other person some feedback that is not so easy to swallow. During those times I suggest just to focus on the facts. Don't get angry or frustrated, just deliver your message. Then you might want to let the other person to cool down before attempting anything mentally challenging. Because frustration simply blocks down our ability to think clearly.

Another interesting topic is the decision making. If I haven't totally misunderstood things, it's actually rather central topic in Agile. Empowering teams gives the teams (and individuals working there) power to make decisions. And thinking about it with some common sense, it does seem wise to do the decisions where the best knowledge is: in the teams. In Scrum the role of the Scrum Master is to remove impediments. A pending decision is an impediment. It's better to make a decision and move on than to waste time in pondering. So, Scrum Master can help facilitate decision making in order to keep team moving.

And I think the same principle applies when going "up in the food chain". Management should provide people with decisions. That's their job. Creating a better working environment through making decisions. Or empowering other people to make those decisions. But that's already a valid decision (and often a very good one.)

Finally I'd like to share this interesting link. Cult of Done. So simple yet so powerful! Starting things is easy. Anyone can do that. But what really counts is getting things Done! Finish starting and start finishing. Have working software as your only metric of progress. Done is the engine of more!