I usually make fun of the “become a scrum master in 3 days”. I mean, what can you learn in 3 days?

Glad you asked.

Once a year or so, I get a chance of going through an exercise with my army unit. These few days are plentiful of agile post material. I’ll try to cram them into one.

Contract negotiations

Take for instance the software we work with. This is an old mainframe program, that is now at the end of its life, so no changes are going in. Of course, the last set of changes broke something very important in it.

Before we continue with the impact of the broken feature, let me explain that the GUI is ASCII, terminal-style. That is not a problem by itself, but a clue to how hard it is to make changes in it. We’re in the 21st century, and graphical UI is pretty prevalent. Getting modernized features is just that hard. Why? Because the software was not developed internally, and the contractor cashed in on every change request. Things to think about during the build vs outsource discussions.

Customer collaboration?

As with every software we use, the keyboard to set data, then press Enter. If I press Enter again, and didn’t change the data, I get this message: “This Enter did not have an effect”. (This is directly translated from Hebrew, except for the Enter word).

I can read a lot into this error message. Apart from the low language skills, the guy or girl who wrote it was probably a developer. Semantically the message is correct (apart from the annoying beep) – I pressed Enter, and the data did not change. But from a product point of view, it doesn’t help me get what I want. I was trying to refresh the screen. If nothing has changed, at least tell me something like “No changes in data”.

Messages like these are symptomatic of waterfall development. I can extrapolate from this message, and on top of what I know about the development of the software, that product people were layers away from the developers. The developers got specs, and filled in the blanks. The developers didn’t met the customers, and didn’t speak their language.

Working software?

So a major feature is not working. The kind of feature that is not only important for the exercise we’re running, but also for the main functionality of the software. The kind that sends the message you can’t trust the software anymore.

By the way, if you hear something like that from your team, you should replace the software. That’s what they are doing in my unit going forward, by the way. But that’s in the future. We couldn’t stop the drill.

What happens when something doesn’t work, but you still need to get the job done? You create a bypass.

The bypass was complicated to do, since the software is so rigid, and not designed to work in a certain workflow. In order to go around it, we needed to piggy-back on another workflow that wasn’t designed for that purpose. I think it took us 5-6 times more to get the job done, then what it would cost us with that feature working. But we got the job done.

We can apply the same to processes as well: If your team has a goal they need to accomplish, and they are faced with debilitating processes, they will find a workaround. You may not like the solution, because it’s wrong, or ineffective, or inefficient, or of low quality, but they will meet that goal.

Individuals and interactions

It wasn’t a complete mess, though.

Our unit is a small team that works together for 5-6 years at least (some of us around 10 years). We know each other, we know the job, we know how to handle problems, and sometimes anticipate them and manage them successfully.

Out of the 3-day exercise, the commander was not there almost half of the time. He could do this, because he trusts the team to do the work. He let’s the team make decisions, because they are closes to the work. The team escalates problems only when we need to, and there weren’t many of those.

A team that gets the job done, and doesn’t stop criticizing the system in the hope that it gets better.

These are the attributes of self-organizing, professional team. The team you want.

All this in just three days, and a whole lot of learning.