The purpose of a PMO

No, we don’t have a PMO on TUI Nordic, not according to the general definition anyway. But we have a central team of project managers. This is not the first time in my career that I’ve been part of a team which consisted of other project managers, but that has been more of an organizational thing – we’ve shared the same boss and gone to the same group meetings.

When I read about the definition of a PMO I see a lot of words about standardized processes and templates. In other words making the choice of the individual project manager less important. It’s like the borgs in Star Trek The Next Generation:

Resistance is futile. Your cultural distinctiveness will adapt to serve us.

Wow. Doesn’t sound like the best day of my life. But there is another part of the borg which IS of interest to me:

We will add your biological and technological distinctiveness to our own.

Now were talking! We’re talking sharing learnings. Everyone that work with agile values know the importance of retrospectives and adapting. But if the retrospectives are kept within the project, well the team might flourish but chances are that the same problems arise in another project, especially if the projects don’t share resources.

In our project manager’s team, we spend a lot learning from each other. We share happy stories and not so happy stories. With the purpose of evolving ourselves and upcoming projects. I can use learnings from another project in my current project.

 

This shouldn’t be something magic and sharing knowledge is hopefully part of many project manager teams out there. But what is core here is that this is the purpose of our team – learning is our core value and not just a bullet on the agenda. After almost every discussion point we add – what can we learn from this?

When I read the Wikipedia article on PMO’s I don’t see a single word about evolution and learnings but I think that this should be the main purpose of a successful PMO which does not only serve project manager’s longing for standards and processes but are there to make projects successful.

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.

Hug your kid

Today I was reminded of the fragility of our happiness. A friend of mine has come upon hard times and when I today just had a glance of what he has gone through and what he's going through makes all my troubles seem so small. When I this afternoon picked up the kids from daycare, I was struck again with the agony one must feel when the things we take for granted are shattered. Knowing my friend, he would today be glad if he could struggle with the kids boots and laugh at their silly jokes while evading a parents efforts to get them all home for supper. He would love to be able to struggle to get everyone to their daily routines and he would smile if he could hurry, too late again, to daycare.

I once worked with a research pre dialysis nurse. She worked with kidney patients who all suffered the process of failing kidneys. For many of them, it was a circular process. They were fine, got on pre dialysis, then dialysis, and then if they were lucky; a transplant. If they were lucky, the kidney lasted 10 years and then they had to go through everything again. And still, her studies showed that the transplanted patients were even happier than healthy people. Even if they knew that had about 10 years before they were back on dialysis and that they might not get a new kidney then. But they had seen hell and returned. So they knew how to appreciate life and their families.

Hug your kids this evening. There are people for whom this would be the ultimate dream come true

Comparing productivity

A couple of months ago, we were given some to fill in concerning our son. I took one look at it and was at once ill at ease with it. I usually don't duck for tasks, but the form ended up on the Todo-board in the kitchen. I don't know if this is only common for Sweden, but here we have these checkups for our kids and this is the final checkup before he starts school this autumn.

Since the checkup is next week, I finally this weekend took the time to fill out the form. And I was amazed by the questions. How could I possibly answer these questions? Example:

How has your child's language skills evolved?
1) Faster than or average
2) Slower than average
3) Much slower than average

Which average? Well, I can admit that I'm not that kind of mother who reads all books on child development and who can tell you the average age for everything and a little bit more. I never subscribed to any mommy magazines and the only blogs I read are about software development, leadership, agile and lean. But even if I did that? What would I compare with? The kids in his group at kinder garden? All children in Sweden? All children in the world?

But then I stopped and thought. What do they want to know? Perhaps they want to know how worried I am about Peter's language skills. I don't know, but I do know what these questions leads to; mothers comparing their kids and mothers worrying about their kids. And this brings us to project managers; they are the worried mothers of software development. There is no form out there but the same type of questions are discussed. The question can be of how successful a project is or how productive team members are.

How productive is your team members?
1. More than or average
2. Not as productive as average
3. Much less productive than average

I know that this is stuff you want to know, but there is no intelligent answer to this question. Try answering this question:

How much do you love your kids?
1. More than or average
2. Less than average
3. Much less than average

If you're asking questions concerning how productive your developers are compared to other developers, stop and think. Why are you asking this question and is there really an intelligent answer? And finally; is it worth the trouble finding the true answer and will the productivity increase by you chasing these numbers?

The power of emotions

The image above is said to be the most successful and powerful customer letter ever written. But what is the strength. To the musical genius, it might be a mystery but for all us who never successfully played an instrument we can just read the headline, close our eyes and immediately get a strong scene in our minds.

The letter is discussed in the brilliant blog, http://www.neurosciencemarketing.com/blog/articles/your-brain-on-stories.htm, which focuses on Marketing and Neuro science.

But what is a product without it's market image? Nothing. You might build the best software /product in the world but if no one has ever heard about it or if people thinks badly about it, what is that worth. Here are some well put advice from the blog:

Clearly, the narratives in the successful ads resonated in some special and universal way with their readers. We’ve all experienced moments of social discomfort, much like the would-be pianist who sits down at the piano only to have his friends laugh. And we’ve all had moments of pride when others acknowledge our skill or accomplishments. Is the narrative nature of the wording in “They Laughed When I Sat Down…” bringing these deep-seated memories to the surface to produce a more profound effect than had the ad simply suggested that we could impress our friends if we could play the piano?

My advice: to engage potential customers, write a vivid story involving your product. It’s worked for the best copy writers and most successful ads in history, and it can work for you.

There is so much emotions involved in user and customer experience. I cannot help but be amazed by this week's discussions concerning the IPad. Those who are talking about it simply loves it or they hate it. Not that they've touched it or used it but the emotions are already sky high because of the emotions that the brand Apple means for many. Apple are great at telling stories and yes, those stories do not apply to all. Quite the opposite; when you tell intriguing stories, they tend to either affects you positively OR negatively. If there is no chance of that high negative emotion, the chance of the positive one is slim. Just look at HP's design notebook in pink and red.

A really cool solution

I guess few people turn to software development because they hate the new, cool stuff. I guess there are not a majority of software developers who hate making that intelligent, impressive solution to the problems. But what can we learn from this video?

http://www.chilloutzone.de/files/player.swf?b=10&l=197&u=ILLUMllSOOAvIF//P_LxP92A42lCHCeeWCejXnHAS/c

Impressive, isn't it? I guess you developer guys look and that and are amazed by the smartness, the cool details and the automation. But even if it's a really clever solution for solving the problem of opening the blinds when you're going up in the morning, is it really the smartest one? Even if the individual details and solutions are really smart, the overall result is just an over complicated system which is impossible to maintain or scale.

Up or down?

When I've been working in projects which involve integrations between systems (which projects does not include that, I wonder), I often think about how developers refers to the integration and most specifically how they describe the direction. In my department at least, you have your own system on top, and then you send stuff down to other systems.

Dev System A: – We need info BB, so you'll send that up to us.
Dev System B: – Yes, and you also need info BBB, so we'll send that down to you.

For me, that is so confusing. What is Up and what is Down in an integration? I've up until now seen UI as above the business and database layers, but these discussions are making me unsure. Or perhaps it's just my developers pulling my leg and having a laugh on my behalf.

What are you focusing on?

It’s winter here in Stockholm and I’m pretty tired of the cold and most of all; icy pavements. Since I run to work at least twice a week, the icy roads are an annoyance. To put it mildly, I get pissed every morning when I try to spot which areas are the least icy in a dark, unlit, Stockholm.

What I could do is try to solve this problem. I would get involved politically and work for these roads being winter kept. That would solve the problem, but it would take years, would perhaps never be realized and a big risk is that if I focused my time on this, I would perhaps not have time to run. And my objective was to be able to run to work.

Another solution is to continue running, using studs.

I don’t say that the first solution is wrong, but as Dan & Chip Heath points to in an extract from their new book Switch, it is easy to loose the goal if you try to solve the COMPLETE problem. This is of course one of the core values of agile software development. Trying to make the complete specification before you start implementation is just one other example.

It also goes hand in hand with one of the ideas presented by Anders Colstrup on Friday’s seminar on Inspiration – you need to focus on the objective and every day take a step towards that objective.

If the problems in your project seem unsolvable, and hopeless, read the story of a man, struggling to help undernourished children  in Vietnam. Your problems have never seemed more trivial.