Fighting Neptune

When it comes to leaders, I cannot help thinking about Gaius Julius Ceasar Augustus Germanicus, better known as Caligula. He was seen as the salvation after years of horrible leader, Tiberius. The people of Rome saw Caligula as their savior. His names in themselves promised a brave and successful leader.

It is said that Caligula started off well, but after two years, things were bad. He ruined state finances, killed and tortured his subjects. Of course, we don’t know how much of the stories around Caligula is true, but one of the stories which are thought worthy is the story of Caligula’s military “victories”. Carryingng all those fancy names, Caligula wanted to be seen as a great military leader. He wanted to celebrate a triumph, just like his predecessors. But the problem was that he cared less about being a great leader.

So, he went on a quest for a battle. But Caligula was not a military genius. The northern campaign had to be abandoned. According to Suetonius, the historian, Caligula had no problems claiming that he conquered both Germania and Britannica, but the prisoners displayed during the triumph were gauls, dressed as Germans and Britons.

But a mere triumph with mortal enemies was not enough. He decided to make war with the God Neptune. Having declared himself divine, he had no problems fighting this enemy. The story tells about the soldiers fighting the waves. They of course didn’t believe in Caligula’s delusions, but they all knew that questioning the ceasar meant certain death.

Today, we don’t know what is true of Suetonius story, but there are many lessons to be learnt.

Working with 7 habits, we discuss the core of a leader. A leader is not only a manager but also a person giving direction to others. I’m currently struggling with this in one of my projects. We have too many objectives, and it’s an ongoing task to describe, explain and discuss. Leadership should never be taken for granted. It’s a difficult and ongoing task.

What Caligula learns us is also that the name and the title does not make you a good leader. Yes, people tended to do what ever Caligula told them to. And for too many managers, this seems to be the essence of leadership. But what it can lead to is people fighting the waves with their swords and the celebration of false victories. A team victory should not be like the triumph of Caligula, just a show to fit his ego, based on a false history. A team victory is a victory which is felt in your bones, when you know that YOU have been part of something important and the real objective has been met.

In a couple of months, I hope my team will have that feeling; that we worked against that objective and that we reached it together. It was not easy, but it was all worth it.

The mandatory stuff

When I have a story writing workshop or some other brainstorming activity, one important task is of course to learn what is really important. Since I’m in the mental moving from scrum to Kanban, this has become more than important. It is crucial.

So, these are my phases of a story writing seminar:

 

The objective

During this part, we discuss the overall objective of the project. What we’re doing and why. I try not only to explain what the customer wants but I want the team to really make the objective theirs. I want them to form their own Commander’s intent so they not only know what the objective is but also what it’s not. We don’t have time for nice to haves. Most of the time…

 

Brain storming stories

This can be divided into a number of separate parts. If it’s a new group or the developers are not fully aware of the business, this should start with the discussion of the different user groups or personas.

Then we move over to the brainstorming of stories. Presented with the objectives and the user types, everyone gets to write their own stories. A tips here is not to push the user story format. When you make it mandatory, people will debate you, but if you instead say that you want to know not only what but why and for whom and that this is an excellent form for that, you get more in a story format. Don’t be afraid to see developers and operations as users. Some stuff you need for these groups too. And writing stories with yourself as user type makes developers learn how to use the format.

 

Grouping stories

After everyone has written their stories, I usually send two or three team members to the whiteboard to group the stories. I let them decide on groups.

After that we say the stories out loud. We select the stories we need, sometimes write some more and some of the stories are discarded after we explain why this is not necessary.

 

Highest priority

I then get everyone to mark on each story if it’s mandatory or not. Everyone get’s their saying.

We then sit down and I pick up the stories which at least one person said was mandatory. I then ask the following question about each and every story:

– If we don’t do this, the project will be worthless and unsuccessful?

This will make the number of mandatory stories much much smaller. When I was more junior as a product owner/project manager I thought the mere asking if the story was mandatory was enough. But the important question is if the story makes the difference between success and failure.

If a story is still considered as mandatory we look at the objective. And I ask the question:

– So, how will this help us reach the objective(s)?

A number of stories will lose their status as mandatory right there and then.

What is the first thing to do?

The next phase is to understand what we need to know where to start. If you have multiple sub groups, you should ask each group what they want to start with. Now the team often remember The Other Stuff, as development and testing environment, setting up build scripts and all that so be prepared for some extra story writing.

When every sub group has identified what they want to start with, they must say if they are dependent on another group to start with their first task.

If the groups depend on each other, use The Theory of Constraints to specify the priority. With that I mean that you should try to optimize the usage of the bottleneck resources.

Is this it?

This is an exercise which should be done regularly. As long as you have stories, you can focus on the next most prioritized items but you will need to go through all phases many times during a long project

Why user stories are not silly

I’m currently reading The Goal, an experience not unlike reading Godel, Escher, Bach in my youth or Sophie’s world a couple of years ago. Using the novel form to explain Business improvement (The Goal), Mathematics (GEB) or philosophy (Sophie’s world) seem like something impossible, but in these three cases the form (which, I grant, is only partly used in GEB) is truly successful. The reason is that the story format probably works well with human brains. It’s like it’s described in Made to Stick; by presenting a story, the information sticks better in our brain.

And yet, it doesn’t seem natural to even consider writing something so important in the novel form. It’s almost like if a subject is grave or important, the presentation should “fit” that. Perhaps this is also the reason for why so many question the user story format. Just the name is probably a hindrance.  Are we going to write “STORIES”. Are you going to gather all developers in a room and write stories. I guess the postits add to the kindergarten feeling most perhaps feel when presented with the user story idea in the first place. I mean, we need the developers to work (AKA, create code).

But stop and think. Like the main character in The Goal does. What’s the goal?

Well, the goal of every IT department should be the same as the rest of the company. And all companies must make money. Perhaps not today or tomorrow, but if you don’t make money, you will never survive.

OK. If the goal is to make money, what do you do next? Well, you should start moving in the direction of making that money. That does not mean that you should only focus on the things that bring in money now. That can, as you probably know, even make you lose money in the long run. Taking on customers who you can’t handle can cost you in the long run. Skipping that training for the developers can make them make simple mistakes. Etc. What is important is not taking the steps in the directions that doesn’t make you earn more money. OK, a company can of course participate in altruistic programs for help organizations, but this is just an exception. When you are at work your tasks should lead to your company making money.

But now the old lady has gone bananas. Starting with some strange books, moving over to user stories and now she’s rambling about making money. Where’s she going with all this?

If we now take that notion of making money down into the deepest corners of the developer’s department and sit down with Greg, the geekiest guy on the block. And we sit there and ask him – How will that piece of code make us make more money? What are the chances that he has no idea or worse; a false image? But why? Because some consider developers just working when they crunch code. That is what makes the company making money. If a developer is not crunching code, he’s not productive.

But what is a productive developer. Well that should be something like this:

Yes, there could also be something that could be disabled and then the two end boxes switch places, but the principle is the same. Now consider these two scenarios.

A: A user wants to do X in system Y and a change request is formed by him and the tasks are handed to a developer, who develops the functionality and delivers to the user.

B: A user wants to do X and discusses this with a developer. The developer informs the user that this functionality is already built into system Z and the user starts using that instead.

So, how was the productivity of the developer in these two scenarios?

How common do you think that this is. Or the scenarios where stuff is built more complicated than needed, or wrongly because something was misunderstood? Or the thousand other cases when the developer simply didn’t know what the user wanted and the user didn’t know his options. When presented with options (not too many but a handful) an intelligent user can often realize that he himself didn’t know what he wanted either.

So, how can we best inject the knowledge into the developer? Well, giving him that specification is a clear path to failure. And in the case of our two scenarios, the specification in itself was waste since it was never needed in the first place.

What we need are more stories. So, is it enough just to use the user story format and give the developers that bunch of story cards?

Have you seen the Dead Parrot sketch by Monty Python? When the sketch was first presented to BBC, they simply wrote down the dialog but no one could see the joke (well, perhaps you don’t like Monty and then it’s never funny) and it wasn’t until they played the stuff the greatness was spotted. And it’s the same with user stories. The actual text is just a reminder, it’s the forming of the story which brings value. Remember that the objective is making money and if we can do that without writing any code at all, we can spend that time on something else. But to enable this, we must use the competence of the developers and the business people at its maximum. And user story workshops are an excellent tool.