How to write a good principle or objective

Have you ever seen objectives or principles which are something like this:

“Our solutions are future safe, uses the best of technology and is easily integrated with our other systems”.

Yes.

Sounds well, doesn’t it? My former college professor once said that a valid objective is one that someone could rewrite so the aim was the opposite and someone could also see that as a valid objective. So, “future safe solutions” is not a valid objective since no one would ever want a solutions which wasn’t future safe. An objective is only interesting if it helps us make decisions and these type of “happy” objectives are therefore in principle useless.

So, how do you avoid these useless objectives? How do we formulate them so they give meaning and direction? There are probably many ways, but here are some favorites from the agile dame in Enskede, Stockholm:

N is better than M

Why does the agile manifesto help us? Well, because it tells us something about the relative priority. If I get to choose between following the process and interacting with people, I choose the people. Since someone could say that process is more important than the human (and sometimes this is true, for example in aviation regulations you have to follow the procedure), this is a valid objective also given my professor’s definition. But this is only if someone could be standing selecting between N and M.

Commander’s intent

The Commander’s intent is used in US military and according the the principle you should always in a sentence say “Independent of how everything else goes, we should have achieved X”. This also gives a relative priority. X is more important than anything else there is. This would mean that if we said future safe is the commander’s intent, that should be reached independent of other priorities.

The pronounceable sentence

It’s too common that an objective is formulated in a long, complicated sentence which you have to read many many times before it becomes clear. These objectives are written like law text but cannot be part of everyday life. So, write your objective so anyone can remember it. Both commander’s intents and N better than M objectives can and should meet this criteria too.

Better missing one objective than all

What are the chances that you would remember if you had one, and just one objective? What would they be if you had 100? We sometimes try to cover everything in our objectives so we write too many.

In 7 habits, we talk about 3 wildly important objectives. That is probably a limit. One of the projects I’ve been struggling with for a couple of months now have three objectives and that is too many. It gets confusing. Better focus on one.

Write it down

Do you think that everyone knows the objective(s)? You don’t have to write it down? You’re wrong. Write it down and post it on the team wall. When the guys look up, it should be the first thing they see.

 

One final insight. I love concrete stuff. When it gets fluffy and lots of words, I loose focus. But don’t mistake abstract with not concrete. Just look at Nike’s brilliant logo. Just do it! Isn’t that just a wonderful objective which can give you guidance when you’re wondering if you should really run in that cold rain?

What is the difference between a takeway and a giveaway?

I can gladly admit that I’m not into football. Not even American football. But sports in general is interesting when it comes to leadership and success. Athletics are also special since they act in front of colleagues and fans during the winning and loosing. If my software development team fails a sprint, most people have no idea. But if a football team looses unexpectedly, the whole world knows at once. Many means that this results in a resistance to making big changes to strategies and methods. If you try a innovative strategy and looses, you’re a disaster but if you’d at least stuck to standard strategies, you’re probably better of in fan and media attention.

That’s why this story about The Saints and how they clarified their leadership, changed their vocabulary and focus intriguing. Words are important. Leadership is crucial, clear objectives a winner and sometimes you have to have a go at something radical.

If you want the short answer of how the Saints went from being a 7-9 and 8-8 team in 2007-08, to this year’s “turnaround” 15-3 NFC champions, it has everything to do with Williams and his relentless emphasis on creating turnovers. …

“He came in and he made us obsessed about takeaways,” Saints strongside linebacker Scott Fujita said. “Obsessed.Every day in practice we’re the crazy team that’s picking up every loose ball, every incomplete pass, and returning it for a touchdown. If opposing teams could watch the way we practiced, they’d probably think we absolutely lost our minds. But now the obsession has become a habit.” …

“It was my No. 1 job when I came in the door; we had to do a better job of taking the ball away,” Williams said … “And remember this: They call them takeaways. They don’t call them giveaways. I don’t want to hear that. It’s not a turnover. It’s a takeaway. If you take that approach, you go try and take the ball all the time. It’s not something you just do half the time.”

http://sportsillustrated.cnn.com/2010/writers/don_banks/02/03/saints/

Open agile = Scrum meets 7 habits?

After having experimented with waterfall, MSF for Agile, scrumbut, scrum and now kanban, I’ve still not gotten hooked on one of these methods.

What I don’t like with scrum is

1. the terms – business people don’t understand what a scrum master is, etc

2. Incapacity to react to quality issues, changes in the sprint. When I read Henrik Kniberg’s excellent work on Scrum and during Mike Cohn’s product owner training, it became all but too clear that scrum has a hard time reacting to bugs and quality defects. Not to mention sudden changes to priorities.

3. Problematic when the resources and the number of resources change. A key value is velocity, but which value does this have when the team changes every sprint or perhaps within a sprint?

 

When it comes to kanban, I can see that we address these problems but other arise. My team members have felt that they don’t see the long term objectives and there is no celebration of when we’re done. The sprint review makes a clear finish line and with kanban lacking this, many feel that they don’t know what we’re working with.

 

A couple of weeks ago, I stumbled upon Agile Advice’s description of the differences between Open Agile and Scrum.

Oh no. Not another methodology.

Not that I don’t think we should improve our processes and methods, but I’ve spent too much energy debating methods when the problems have been elsewhere: lacking leadership, quality focus and programming skills. I probably need to clarify what I mean. When the leadership has been failing, the quality has been poor and the programming skills have been too poor, people owning these problems have turned to pseudo discussions concerning the methodology and spent the energy on the method instead of fixing the core problem.

But back to open agile. I left the page open in my browser, trying to find the time and interest to read it and this morning, having woken up before everyone else but the dog, I did.

First, I felt that this was just scrum with other terms and even if I don’t like the scrum vocabulary, I would never consider a new methods just because of this reason. But there were some lines in the description which caught my eye. Especially the values and the ability to react to quality defects during cycles. So, I actually took the time to read the Open Agile primer.

Again, a positive surprise. After landing in an organization with active leadership and value driven objectives and strategies, inspired by 7 habits and Lean, I’ve found that there is more to a method than just terms, process diagrams and artifacts.

I’m not sold on Open Agile. Yet. Because I’ve never tested it and I my experience is that all methods have their flaws and draw backs. But perhaps I get a chance to test this is an upcoming project.

Who is the corporate hero?

Take a good look at these two images.

 

Yes, she looks a bit freaky, but besides this. Which person(s) would you classify as a hero?

Jeffrey Phillips asks in his blog post, Why is fire fighting more valuable than avoiding fires.

And the answer is in these two pictures. It’s not heroic to do the cleaning. For many, it’s very satisfying to feel like a hero. You get a lot of credit and recognition. In many cases, the people preventing fires are considered negative, backwards thinking and boring.

We all know that we need both but how much of you’re time do you spend rewarding the fire fighters and how much time do you spend on appreciating those who are preventing fires?

Being a part of TUI Nordic means that I have the chance to work with TUIFly Nordic, our air carrier. In their culture, the picture is the opposite. Zero tolerance for failure. Constant follow up and process improvement is built into the company walls. There is a sense of constant urgency. An urgency to improve and an urgency to prevent that fire from ever happening.

The curse of the Point

I guess I’m just like you. When that boring guy goes up to the podium and starts that cursed program, I take a quick glance at the number of slides and sighs. Oh my G*d. Given all the stupid warnings in Microsoft Office applications, why is there no warning when you exceed the 10 slides marker:

“You just created your 10th slide. Will you really want to risk boring of your viewers?”

Cancel should be the default option.

So it’s no wonder that this is Dilbert’s view of the cloud:

(Source: Dilbert)

We all love to hate those who love PowerPoint. Or as someone wise said: “With PowerPoint it has never been easier not getting to the point”.

But one important question is: Was it really better before? Were presentations really better on the OH-projector? I remember one of my College professors, bringing a hockey trunk to classes. He gave classes at many places in Sweden and he took all his material with him in the form of plastic sheets from the 1970’s and forward.

I guess that an added problem is that you can run out of plastic sheets but you cannot run out of slides, but I think that is besides the point. There were bad presentations before the curse of PowerPoint struck us, and there are still bad presentations.

So what can we do? In 7 habits we talk about Habit 1: Be proactive. This means that if you have a problem, you decide if you’re going to do something about and then you do. The other option is to stop caring. So, if you cannot drop your distaste for the lousy, uninteresting presentations  in your life, you can choose to do A, B or why not both.

A. Give better presentations ourselves.

B. Give feedback to people giving presentations which could be better.

In both cases, you need to focus on the Point. The point the presenter is trying to make. Set that as the objective and just add the slides/information which leads to that Point. Cut the rest. If you have the privilege to work with A, your own presentation, this is easy. You know which point you’re trying to make and you can look at each slide to see if it gives more value to the viewer, trying to understand the point. And afterwards, ask for feedback. What helped and what didn’t? Explain that you’re trying to improve your presentation skills.

When it comes to B, it’s harder (at least for me) since it involves negative feedback. Again, 7 habits helps us with a template. If you’ve experienced a bad presentation and you think that the person giving it has the capacity to improve, you should help. “In your presentation X resulted in Y for me.” This is not an absolute template since it has to be applicable to the presentation. But here are some examples:

“When you showed slides 3-10, that really got me confused. I think I would have understood the problem better if you’d focused more on slide 11 which summed it up nicely.”

But don’t forget the positive feedback. There are many good presenters out there and I must say we are not praising them enough.

Remember the Dilbert strip. There are two monkeys, one is talking and the other one is listening. Which one are you?

The agile leader – a master or a servant?

I guess Depeche Mode didn’t think about Agile leaders, product owners or software development when they wrote the lyrics for Master & Servant:

There’s a new game

We like to play you see

A game with added reality

You treat me like a dog

Get me down on my knees

We call it master and servant

But when you have titles like “scrum master” and “product owner” you might think that people holding these positions are the masters, trying to squeeze every drop out of the developers.

The example from Ester Derby’s blog about such a manager is probably not that uncommon. A new manager, eager to “cut costs” killed her team in the long run:

People who were confident in finding new jobs left. The people who were afraid they didn’t have the skills to face the job market hung tight. There were rumors of layoffs. Fear lead to people to choose CYA over do the right work the right way. Competition undercut cooperation and collaboration. The VP to an ax to department budgets. The balance sheet looked better (in the short term), but costs went up.

It is always tragic when you here these stories. What we need is leaders who wants more. Leaders who takes pride in the team. Leaders who don’t have to be the master but leaders who can be the master (no, don’t whip your scrum master, I never said that ;-).

When I and Sally Elatta started discussing leadership during an e-mail conversation yesterday, she introduced me to the concept of the Servant Leader. The term was coined in 1970 and described as [cite from wikipedia]

The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature.

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society? Will they benefit or at least not be further deprived?

The idea is older, for example Chanakya wrote 400 BC. [Cite from Wikipedia]:

“the king [leader] shall consider as good, not what pleases himself but what pleases his subjects [followers]” “the king [leader] is a paid servant and enjoys the resources of the state together with the people.”

We’re pretty far away from The Prince!

The key question for any manager is : Are they there for you or are you there for them?

The servant leader knows that he’s there for the team. The whole scrum idea of removing impediments is based on this idea.

It is therefore so interesting that more agile leadership trainers like Sally Elatta are talking less about certification, the techniques of method A or B, and more about these key character traits of the successful leader. If the introduction of agile methods have revolutionized software development, I believe the introduction of the servant leaders will be an even bigger win. How many “agile” projects fail because of failing management?

What’s up for 2010?

I’ve just completed the first two days of work for 2010. This is a hectic period for my company. Traditionally, January is a month for summer vacation planning, and this year we’re exceeding the previous year’s booking by a wide margin: last week we had 40% more bookings than the previous year. Great news and a real test of our web sites.

But it’s also a time to think about other challenges. On the personal side, my son is going to preschool this autumn. Myself, I’m planning to complete the short version of La Marmotte, a amateur cycling race in France. 76 km, 2500 m gradient will give me something to work to complete.

Work wise, I know I will be working with 7 habits, empathic leadership and our ongoing struggle to improve our business using our processes and software solutions. I will probably experiment more with kanban and behavioral economics. Finally, my line of business is of course struggling with the challenges of sustainability and the climate question.

Do I need something else? Probably not. I guess I have stuff to do.

The most prioritized things

When we now move into 2010, I get to summarize my first year at TUI Nordic. It’s been a wildly interesting year and to be frank; I had no idea that I would change so my views, ideas and focus in such a relatively short period. To keep it short, I’ve come to believe that the main focus for product owners, project managers and such should not be in the techniques and methods of software development.

Yes, the product owner should be deeply involved in scrum or kanban and work daily with the team. The product owner should be as fluent as the best of the team members in the chosen methodology, but the methodology is not what brings the ultimate success. What brings ultimate success is understanding what brings business value, find ways to prioritize and to make developers, stakeholders, sponsors and customers understand why we prioritize in a certain way and how things will work. When I say that this should be the product owner’s main focus, I say that this is where his heart should be.

What brings business value?

In so many positions, I have after a while revaluated what the business is. Too many times, the by the management canalized  description of the business has not been the truth. Not that they lied, it was more like they didn’t understand this fully. Sometimes they don’t understand the complexity, sometimes they are way off the truth, focusing on the wrong stuff and things don’t bring business value. But the truth is often more complex than first perceived.

When I moved to the leisure travel business at TUI Nordic, I had no idea what the business was. Yes, I knew it is about people, free time and holidays away from home but I had no idea it would be so complex. Just before Christmas I was given a research assignment by my boss and while completing that task, my views were overturned again.

The road to learning what truly brings business value is empathy and social intelligence. Empathic listening to people outside your comfort zone can change your paradigm. Everyone can place a priority number besides a product backlog item but it’s only the empathic listener who can make the best priorities.

How to make propositions a reality

Software development is all about bringing ideas to life in the form of software development. Using a software development methodology is all about techniques to make things becoming built. But developers need to build the right things so that they do the right stuff the right way and everyone else involved need to understand what is built, why and how. Scrum and kanban gives you tools but no tool is better than the person holding it. Again, the leadership and empathic listening is in my view crucial.

It’s not about being the office clown

Don’t understand me wrong. I don’t think that product owners should be dancing about in the halls of the office trying to become the most popular guy on the block. I’ve had such a boss who acted like a speeded rabbit, trying to be cheerful and optimistic. Since he had no depth, it was actually more depressing to see his faked smiles and hollow laughs.

It’s about being like Gene Kranz, here depictured in Apollo 13. You’ve probably seen the movie, but even if you have, sit down and think about the leader in this short sequence. Wouldn’t you like to work for this guy and don’t you think he would make an excellent product owner?

Mistaking group thought for collective intelligence

Sometimes you become a part of tightly knit team. You seem to almost think the same things and solutions just comes flowing. What you probably have felt is something Daniel Goleman in his book Social Intelligence refer to as Rapport. It’s one of the most rewarding social connections and the ability to Rapport is a crucial part of social intelligence and well being. And often a team with Rapport can be very productive.

But there are also risks. As James Surowiecki points out in The Wisdom of Crowds, this forming of the tight, homogenous group gives ground to group thought in a negative sense. Surowiecki gives a lot of examples of when group thought stops innovative ideas from being realized or even thought or expressed. The fear of breaking the group thought is perhaps not obvious or even realized, but is there. If you break that precious bond, you lose that comfy feeling. We’ve all been in that situation too. We have that small, tight group and in comes the Outsider with the Outsidish idea. What an idiot. He knows Nothing. We’ve already tried that. But we are the experts. And so on. The outsider must in many cases chose between aligning and thereby just provide ideas which are in line with what is acceptable ideas within the group or stay an outsider.

What can be elusive is that the tight group might not be without conflicts or debates. The principle is that the alternatives are just within the acceptance range of the group. And thereby many great ideas are never explored.

According to Surowiecki, it is key to keep groups heterogeneous to harvest the collective intelligence instead of the narrow group thought.

These books really got me thinking about groups and teams. Agile software development is all about creating the most business value for the least effort and here is probably an important key factor. How to use the collective intelligence and still have the comfort and calm which Rapport brings. And how to minimize the negative effects of group thought. Working with the 7 Habits gives me a lot of tools but I will probably struggle with the Scrum team idea. Scrum teams are supposed to be cross border but how often are they really? And if they become true teams, how homogenous will they not become? Not that Kanban or other methods are better in this perspective.

Well, I have something to work with next year!

What you don’t evolve is being terminated

The quotation is better in Swedish, “Det som inte är under utveckling är under avveckling”, but still. Christer Olsson lectures in management and spread his idea that if you don’t evolve, you are becoming extinct. You cannot keep status quo without improvement. You can see the world as ever moving and if you stop still, you will not stay in your place but you will loose your position.

This is obvious to everyone who is struggling with agile or lean values, with the rule of constraint or Kotter’s sense of urgency. Evolve or die! But at the same time, it is easy to slip.

Some weeks have passed since my first 7 habits class, and during the first two weeks, I worked the habits, went through them in my head. But then they became mainstream in my head. I started taking them for granted. It is almost scary how little time it took. I came to a stand still. And I didn’t even notice it.

But one of the strengths of our 7 habits program is the learn through teaching part. As a part of our own training, we’re training others. I’ve picked two really talented developers with whom I’ve previously worked with and who are interested in management and leadership. And I know they are not just interested in a superfluous manor, they want to evolve in this area. This, alongside us sharing some experience around leadership in different flavors has made them interesting partners in this project.

I think I’ve tripled the gain of the class by having these discussions. Having worked with training for most of my professional career, this should have been obvious, but now it’s staring me in the face. I’ve covered all the habits with one of these guys but yesterday, I started with the first habits with the second guy. So, I had to turn back all those pages. Go back to the first habit. And I saw that I’d lost it. I’d let habit 1 go. By simply taking for granted that I’d already worked with that habit, I didn’t work as hard with it. I was not back on the level I was on when I started taking the class, but I was not as strong in this area as I was two weeks ago.

If I hadn’t looked back, reflected and understood that I was not evolving, I would soon have been back there again. This is a lesson I must not forget. And today I could again see the difference in my handling of a specific situation. My soon got too much vaccine when he got his flu shot today. I directly saw this as something I couldn’t do anything about. So, instead of badgering the staff, I instead kept calm, focused on Peter and awaited the information from the Swedish authorities. As I kept calm, I could see that the woman who gave the shot was not feeling well. She felt terrible about what happened and I could place myself in her situation. I tried to calm her by thanking her that she told me and I later called and confirmed that Peter didn’t seem affected. I did what I could about things I could affect and left the other things in the bin. Screaming about it would not have made the thing undone.