We Are Always in the Sixth Grade

I spoke the truth. It was about a boy and a girl – of course. What I saw was real. What I said became the focus as if I had done something wrong. I didn’t do anything wrong. I told what I saw to the wrong person. The girl was popular. As a result I got un-friended. This was not in the virtual sense. We didn’t have virtual then. I was un-friended in the real sense. In the “everyone else is invited” but now I wasn’t. Voted off the island. Alone.

Here’s the thing. I wasn’t in the sixth grade. I was in my 30s. It felt the same.

What is different is what I did afterwards. I invited every single woman who worked at the company (there were 20 or so) to lunch. Including that one. She had an excuse not to come.

One of the women cried when I invited her. She said nobody had ever invited her to anything. This was the first time. She was the receptionist and we ignored her.

It may have been a little late to learn this lesson but we are very aware of how much it hurts to be excluded. We are less likely to be aware of who we are excluding. Same as in the sixth grade.



MBOK – A team making themselves agile

Let Teams Figure it Out” by John Cutler.

This article proposes that a team could launch their own “continuous learning adventure”.

I have to admit one side of me finds this uncomfortable because I like to think that my knowledge and ability to facilitate is useful and if people can do it without me, what is my purpose? However, that is something that I need to get over because I know people come to me for what they need.

So, the confident side of me says “This is actually the way to find out what the team actually wants from you.”

The idea, facilitate an activity.

  1. read the article

Ask the following questions:

  1. “What do members of the team already have?”
  2. “What’s stopping you?”
  3. “How can I help?”

MBOK – Why?

I’m constantly reading or hearing things, thinking “wow, that’s really interesting.” Followed by “I can think of a really interesting way that I can use that myself”. Followed by promptly forgetting the original source as well as what I was going go do with it.

So the Melinda Book of Knowledge is about that. I couldn’t figure out where to collect this stuff and decided to go with my website because I can get to it from anywhere and there is a chance somebody else may find something interesting in what I say. This is different from my regular blog because it’s more like an index of sources with a small amount of commentary on why I found them useful.


Dangerous Metrics from an ‘Ineffective’ Scrum Master

Imagine if someone on your team told you that she had just been diagnosed with a serious illness.

Then she said: “It’s the last day of the Sprint and I need to stay late because we have not completed all of our points.”

“No, you need to be home with your family. The points don’t matter.”

In this situation it is easy to see that the people are more important than the points. I would argue that is the case in every situation. Or, as you may have heard it before, “Individuals and Interactions over processes and tools.”

Somebody in our organisation looked at our team’s velocity and remarked that our velocity wasn’t consistent. That, he said, is evidence of an ineffective Scrum Master. No, that’s evidence of inconsistent velocity.

There have been times when I have been a Scrum Master for a team with a velocity that goes up and down. I know it shouldn’t. A team aims to be predictable. An accurate forecast is important. Nevertheless, we don’t always achieve what we set out to do. Those hills and valleys are our triumphs and our scars.

Over the years, my Scrum teams have dealt with a lot. We have had peaks when half the team volunteered to work over the holidays. One team decided that they were going to smash their record one Sprint. Those valleys were when beloved family members passed away. There have been babies born. There have been holidays of a lifetime. We didn’t complete as many points when one of us brought his family to Australia to live with him for the first time.

We want to keep our team the same size for a long time. We want to fund products not projects. Those factors will help us reach predictability. Yet, we compromised both of those ideals when I had a team that welcomed two new team members. Another team was disbanded because their project came to an end. Two of them joined us. Our velocity changed.

To be fair, I don’t always get it right. This isn’t always about tragedies or things outside of our control. Teams need to be predictable. They need to get better at estimating and forecasting. I need to coach them in that direction.

That particular up and down was mostly attributed to a mistake that we made more than once.  Here’s the pattern: we take too much in one Sprint. Say we try for 120. However we only finish 80. So 40 of those points spill into the next Sprint. This time we take in and finish 120 (because 40 of the points were practically done). Now we get ambitious. We know we can do 120 – we just did. We do 80. 40 of the points spill into the next Sprint. Around we go again. That was a new team. They learned.

If being an Effective Scrum Master equates to having consistent points in our Sprints, I can do that. If that means I get a badge, or a bonus or a job, I will. Rather than letting the team find their own way, I could force them to only take in 80 points each Sprint.  Our velocity will then look like this:

The team has been commanded to have a consistent velocity.  This probably means that we are predictable. It could also mean that we are focusing on the points rather than our Sprint goals. Maybe we are gaming the points. Can’t tell.

Let’s look at another option. We are not complacent. Every Retro, every Sprint Planning, we talk about it. We try things. Sometimes they don’t work. Sometimes they do. Eventually we hit our stretch goal. We keep hitting our stretch goal.  Our velocity then looks like this:

This might be what happens. It might not.

What does the Scrum Guide say about a consistent velocity? Absolutely nothing. Those words do not appear. That doesn’t mean it isn’t good Scrum practice. Scrum is set up to optimize predictability. We want to know what we can achieve in a Sprint. We want to use our past experience to guide our decision making in the future.

Don’t get me wrong; a team with a consistent velocity is a good thing. It is something to aim for. However, like any metric, it doesn’t tell the whole story.

You can’t look at the velocity as a single metric by which to judge the success of a Scrum Master. If how many points the team completes and whether or not they are consistent from Sprint to Sprint, is the measure, I am an ineffective Scrum Master.

That’s not what I believe. I believe an effective Scrum Master recognizes that people are important. The things that people produce are important. Achieving our goals is important. Outcomes are important.

Counting points is a metric that helps us understand our capacity. Over time it helps us understand our consistency. However, the important thing is that we are consistent. Both with what we say we will deliver and how we treat each other. Take care of the people and they will get things done. As a team, we will continuously improve. If some of the points spill into the next Sprint, we will cope. We will be there for each other.  We value what is on the left more. In doing that, we will achieve what is on the right.

Although we value the things on the right, we value the things on the left more


Cycle Time – Visiting the Baum Factory

You know your life has changed when you leave a factory tour enthusiastically telling your friends and family:

“There was a real LIVE kanban board”

For the benefit of those (like my friends and family) who don’t understand my excitement, in Agile software development we have digital representations of kanban boards. We make them physical by writing things on Post-Its. However, they aren’t tangible things. The one at the Baum Bicycle factory was a physical thing. The “board” was a series of big wooden boxes that slide from right to left.

If you are new to agile and lean thinking you may not realise the connection between building software and building something like a bicycle. Actually, the fundamentals for agile software development started on the factory floor.


Boxes slide on a track


The big kanban board

These big boxes represent the order in which bicycles are being built. In the boxes are the pieces that need to be collected before a bike can be started. On the left are those that are closest to being built. On the right are the bicycles that have been recently added to the backlog. Like a virtual kanban board, this makes the priority of backlog items visible. Seems simple. The concept is simple – but pulling it off isn’t easy. What it represents is a clear focus on the order in which things, in this case bicycles, will be done.

One thing that is interesting (and courageous in my opinion) is that the board is first come first serve. The reason why that’s interesting (and courageous) is because the kinds of people who can afford to buy a bike like this are the kind that aren’t used to waiting their turn.  It’s not easy to change the order and it’s really obvious if you are doing it. That means it doesn’t matter who you are, they aren’t going to stop doing what they are doing to work on your bike. That allows everybody building bicycles to focus on one bike at a time. It also has the advantage of not having too many expensive bike parts in play at a given time.

The factory tour was part of Agile Australia 2016. I am not an expert in building bicycles. Actually, going to something like Agile Australia makes me think I am not an expert in anything. I am, however, somebody who helps teams discover ways that they can be more successful using what we’ve learned from others. That’s why we were there.

Darren was talking about the doubts of some of the people he works with and I asked him about his own doubts. That’s not really the questioned he answered. My take on his answer was that he has no doubts in his product. Nor should he. He had the wisdom to know that he wasn’t an expert in the process. That’s what he needed to learn.

There are some aspects to lean and agile thinking that I found counter-intuitive when I was first introduced to them. I believe in them because I recognise that lots of people have demonstrated that they work. One of those things is the concept of starting the most important thing and focussing completely until it is done. It may seem surprising that there are so few bicycles being built at any time. That is WIP, Work in Progress.  You don’t want things to pile up at any point. That’s particularly challenging when some aspects of building these bikes take years to master – and some people will never get the feel.

One of the things that resonated with me was the visibility of progress for the people who talk to the customers. I wish I had that years ago. I used to work at a company that built adaptive keyboards and the software that accompanied the keyboards.  I worked on the software but I also took the calls from customers who were getting their keyboards repaired. Customers wanted to know when they would get their keyboards back. Sometimes I would wander out the back to see if I could figure that out. If the keyboard wasn’t actually on the table at the time, I couldn’t tell. If I was feeling brave, I could ask the people who fixed them. That made them angry and I didn’t get useful information anyway. So I would go back with a guess. Having a system where everything is visible to everybody sounds fantastic. If you are transparent and honest, customers can deal with waiting. They hate uncertainty. In the Baum Cycle Factory, everybody can see where the bikes are.


Board to visualise progress when painting bikes

In my first software product development job, there was no methodology, we just figured out what made sense to us. Common sense we like to call it. The problem with common sense is that it’s actually just opinion. You might think the same thing happens with a lean, agile approach. That’s not the case. Agile doesn’t mean ”just make it up.” It means learn from others, try experiments (with a specific goal in mind), learn from your experiment, if it works – do more of it, if it doesn’t work – stop.

I recognise elements of what I do in this factory but I could also see that their experiments are specific to this challenge. There are visual boards on the walls – they aren’t the same as the ones I’ve made – but they aim for the same goals of transparency and communication.

Don’t take this the wrong way but when we got to the end and saw the finished frames, I have to say I thought ”Is that it?”  I say that because I saw all the hard work and time that went into getting to that point and it’s hard to see what’s different about these bikes – especially when they don’t even have wheels. I guess with anything when you are not an expert, you can’t necessarily tell the difference. The tour impressed on me how extraordinary these bikes are. Most of us never have things made specifically for us by experts. I know that the magic of these bikes is the way they are built specifically for the individual who rides them. There are some things you can’t see but the quality speaks for itself.

I can understand intellectually that there is a correlation between a factory and working in an office. However, I haven’t tried transferring these skills to a factory floor. I would have pretty scared to take this one on. This doesn’t really look like the work environment I am used to. I think the team that tackled this embodied the agile value of Courage. I would have found it really difficult to walk in there and have the confidence to experiment. Kudos to everybody working on this one.

Courage is also something that comes to mind when meeting Darren Baum. Most of us who experiment with lean and agile aren’t putting our own livelihoods on the line. When you risk your whole business because you believe this is the way to work, that’s courageous. When you deal with the constant doubts of others, it’s difficult to stand your ground and keep believing. More pedal power to you. Thanks for sharing your story.


Header image taken by Sandy Mamoli and edited by me using Prisma.


The Power of the Release Forecast Board

“Can you get somebody from Ops please?”

At the beginning of each Scrum of Scrums, we always used to drag somebody from Ops into the room. It’s an optional meeting but with the whole Ops team opting out, it was losing its effectiveness. Now, they come willingly.  An unenthusiastic Ops team wasn’t even the problem I was trying to solve. That was a bonus. I was actually trying to solve a problem for the Product Owners.

What was the problem?
The problem was clear from the Post-Its on the wall from my retrospective:

“I don’t know when releases are going live.” “Releases are getting delayed and nobody is telling me.” “Other teams are breaking our releases.”

For us, the Scrum of Scrums is the place where representatives from our Scrum teams discuss things that impact other teams.  By and large, the things that impact other teams are releases.  We had a problem with those.

On our path to Continuous Integration and Continuous Deployment, we left a vacuum where Project Managers used to be. Nobody was managing cross team dependencies. Builds were failing because multiple teams were checking code into the same code base. Teams didn’t want to do regression testing with other teams’ code. Our automated code coverage wasn’t great. Releases were no longer going out on time.

My team of ScrumMasters was told we had to communicate better. Communicate? We don’t know when it is going live. Ops doesn’t tell us. We can’t communicate what we don’t know. To be honest, I was a bit annoyed that I had been forced to stop doing portfolio management. It was hard, but it worked. People who didn’t understand the challenge were telling me it didn’t need to be done and now they imply it’s my fault that we have issues.

I was turning this problem over in my mind when I went to Scrum Australia and brought it to my coaching session with Neil Killick.  He brainstormed a visual release board with me. I created the MVP the day I got back to work and introduced it at our daily Scrum of Scrums. It worked.

Here’s how the Release Forecast Board works:
IMG_4911Most of us are familiar with visualisation boards for our teams. These boards show the progress of PBIs, (stories, bugs, tasks, etc) through the sprint. Post-Its are moved from left to right as they are worked on. Our teams have boards like that already.

The Release Forecast board is different. The board has the next two weeks pictured. Each column is a day of the week. Each release is on a Post-It on the day we think it is going to go live. If the date changes, we move the Post-It to the new date. When I first introduced the idea there was resistance. “Hang on,” somebody said “I don’t KNOW when it’s going live”. Precisely. I’m not asking for a commitment; I am asking for a forecast. If you think it is going live in the next two weeks, put it on the day you think it is going live. If it changes, move it.


The Post-Its have the name of the platform (you might call it a component or an application – it’s whatever gets released in one deployment), the expected version number and the team that is leading the release.

That’s it.

What is the benefit of the board?
The board is there for the communication and cooperation it inspires. It’s like the indicator on your car. Somebody may need to know where you are planning to go.

On the very first day, Marcus, one of the ops guys, pointed to a Post-It and said. “That’s good to know, I need to make a change to correspond with that release on Wednesday.” “It might not go until Thursday,” the team representative said. “No worries,” Marcus said.  “I’m not in a hurry, just need to get it ready.”

People immediately started saying things like “We were planning to put Andromeda 1.2 live next Thursday but we see you are planning release 1.2 on Tuesday, can we combine our efforts?” Sometimes we would see eight Post-Its on the same day. “We don’t mind moving our release,” somebody would say. “Just move ours to the next day.”  Another person piped up “Don’t touch ours, it HAS to go live that day.” The Ops guy suggested that we put that Post-It on the top of the list, so he knew to do it first. Awesome. I just stood back and smiled.

It is a lovely thing to come back after a vacation and see that the board moved on without me. It was up to date. It even improved. While I was overseas, a new arrow was introduced to help people focus on today. It’s not my board any more.


How has the board evolved?
After the board had been up for a little while, cross-team impediments started showing up on the board too.  We also found that it made sense to write the actual release dates on the Post-Its when releases went live and leave them in a “Live” column on the right for a little while so we had a record. People naturally started moving Post-Its when it was their turn. They started bringing their pens so they could add information.

What has gone wrong?
After we had been using it for a while, a member of a new team joined. He added a Post-It for the next release and I wrote his team name on the Post-It and whacked it on the board. A few days later he said, “We just have a small item in this release, hoping that another team leads it.” A Scrum Master got annoyed. “Your team name is on that Post-It, that means you are leading that release.” A heated discussion ensued. The new guy was upset. He didn’t want to come back to the meeting. I realised that we had made assumptions about how the board worked without documenting them or sharing them with new people. So I wrote a page on our wiki and I summed it up with the following rules:


Are we living happily ever after now?
Did the board solve everything? Well, as they say in Australia “yeah, no.”  CI/CD is not an overnight thing. There are still many challenges to tackle. We improved communication, transparency and visibility and we all know how important that is.

Thanks Neil, for your gracious coaching.


Background Stuff – if you are interested in history and detail

We used to manage the tasks in releases manually in JIRA. A Project Manager would create a set of fix versions.  Andromeda 1.2 is scheduled for May 4. Andromeda 1.3 is scheduled for May 18, etc. Each fix version would have a bunch of tasks. Prior to a release, Project Managers would make sure that everything was on track across all the teams. If anything wasn’t going to be code complete and tested by the release date, either we would delay the release or we would kick things out. We would constantly communicate the status of releases so that everybody knew what to expect. Of course mistakes were made in our old system too but we had a shared understanding of what we expected to be in the release.

Now the earth revolves around the sun, we follow Scrum and we respond to a lot of change. We don’t Project Manage. We do, however, still plan. Given that most of our teams run two week sprints, two week release forecasts make sense for us.  Like a weather forecast, it’s not all that accurate a week in the future. Nevertheless, you still want to know if you might need an umbrella next week.

When we used to put JIRA tasks into releases manually, we knew what to expect weeks or even months in advance. Now, when the code is committed it is flagged with the JIRA task number. When the release branch is built, a script adds the next fix version to the task automatically. This is more accurate and it is saving us a lot of double handling. However, we don’t know what is in the release weeks or months in advance. We know when it is ready. That’s why we needed the board.



Pat Reed, Bas Vodde and Brené Brown inspired me this year, here’s why.

I had never heard of Pat Reed but last year I decided that I would average at least one MeetUp a week so I go to a lot of things that I know nothing about. Some are worth it, some aren’t. I try to pick out at least one thing that I learn each time. Pat was a pleasant surprise.

What inspired me about Pat was her humility in spite of her amazing accomplishments. She had an uncanny ability to evoke participation from the audience. I had the exact opposite experience at another MeetUp where a presenter kept saying ‘’I am an expert in presentations.’’  Pat didn’t say that.  She showed it. What I learned from Pat is to let the audience talk. I was preparing a presentation for the following week and I changed my presentation after watching Pat. I added space for people to speak. She only had a few slides. She really listened to what people had to say. She actually walked over and looked directly at people. Even those people who are prone to go on and on didn’t.  Because they were heard. Most of what happened was in the room. Amazing woman, amazing experience. She was one of those people who made me think “Hang on, what am I doing with my life?”

Bas Vodde inspired me because he had walked the walk. His book is based on hundreds of experiments. What he says is, “This is what we tried. It might work for you too. It might have failed for us and work for you.” I absolutely loved the simplicity in his approach. His story about “I want to go very fast in the wrong direction” was brilliant. If you haven’t seen that one, Google “Fireside and Bas Vodde”. The Sydney one was great but he has done the same speech other places.

Brené Brown has one of the most watched TED talks ever. I kind of thought maybe I shouldn’t bother going because I can just watch her online and I don’t have to sit in an uncomfortable chair at the end of a long day. I’m glad I did. You do get more out of it when you make the effort in person. She started interacting with the sign language interpreter on the stage; it was hilarious. Brené takes her own personal experience and combines it with an admirable amount of study and experience. I loved her story about thinking that she had totally screwed up her talk and her husband saying “don’t worry, nobody will ever see it’’.  Of course it now has over 24 million views. After watching her talk I was inspired to be more vulnerable. Those real, human moments are what make her so memorable.

Thanks to all of you for your inspiration.


Courage and Leadership

(Doodle by Martyn Frank @frankletsbe – hope he doesn’t mind me using it but I absolutely love it and he captured my talk beautifully).

This all started with a quiz.  Give it a shot.  What is the correct answer to the following question?

According to a recent item on the Scrum Alliance website blog*, there are three benefits that companies see during a transition to scrum. Select the option that is not one of these.

  1. Faster delivery
  2. Communication 
  3. Transparency 
  4. Leadership

The correct answer is a) Faster Delivery. What surprises me is not just that virtually everybody who answers this gets it wrong, but that they all pick the same wrong answer, Leadership.

Somewhere along the line, I found myself saying.

“Everybody is missing leadership.”

Is that just in the quiz? Or does the quiz reflect an actual lack of leadership? First, let’s go back to the answer that wasn’t one of the three. Faster delivery. This is why I hate multiple choice tests. If you gave me a good explanation for why faster delivery is a benefit, I would give you credit for it.

The important thing about this quiz is not the answer but the conversation we have about it. Faster Delivery can be a benefit of agile.  Here are some relevant quotes that make this point:

“more frequent delivery of only the highest-value items.”

          Luke Walter

“shorten the time to feedback”

          Ryan Martens

“Scrum has been proven to deliver value to the end customer 30 to 40 percent faster than traditional methods.”

          Mark C. Layton

“Reduced cost of value”

          Pat Reed

If we interpret faster delivery as a shorter way of saying faster delivery of value, there is no question it is a benefit.  Perhaps not a benefit during a transition to scrum but definitely a benefit.

However, I am a debater.  Let’s turn this around. Why is Faster Delivery wrong? I’m going to give you the most obvious reason.  It just wasn’t in the article. The article mentioned three things and Faster Delivery wasn’t one of them. It was not the point the author wanted to make.

Let’s have another look at these options.

Put on your CEO hat and let’s have a look at this list:

  1. Faster delivery
  2. Communication 
  3. Transparency 
  4. Leadership

If you are the CEO, what do you have to change for faster delivery? It depends on how hands-on you are as a CEO, but it’s possible that you don’t really have to change at all. You just have to encourage the team that delivers to deliver faster.  So if you see faster delivery as the benefit of agile, you may see that as something for the delivery team.  “Off you go, deliver faster.”

“As a coach, I’m getting truly tired of talking to managers and leaders who’s sole drive to adopt agile methods is for…More, increased capacity, to go Faster! “

          Bob Galen

“A common misunderstanding of agile is that it is cheaper and faster than waterfall delivery. The truth is much less clear cut – it can be cheaper and faster, but only if it is suited to the organisation and project in question.”

          Matthew Du-Feu–1283876

If you are only looking for faster delivery, you might get that by changing some practices and processes but will you really get the benefits of agile? What about communication, transparency and leadership? If you are the CEO, are you involved with those?  I certainly hope so. If you focus on those, will you get the real benefits of agile?  Absolutely.

So that’s relatively easy to get my head around.  Faster Delivery might be a benefit of agile but ideally we focus on more than just going faster. We can probably get consensus on the fact that actually delivering value quickly is a benefit.

If we look at the other options, if you don’t pick Faster Delivery, what do you pick?


Not only do most people get the question wrong but most people who get this question ‘’wrong” – pick Leadership.  Because I asked everybody to talk through what they were thinking, I found people saying

‘’I don’t think leadership is a benefit of agile.’’



Early in our agile journey, we had one of those planning poker moments when everybody in the room had a number like 2 or 3 and one guy had an 8. The guy who had the 8 was one of those guys whose English isn’t great who never used to say a word before we started doing scrum. One of our louder members said “this is easy, we just did something in our last sprint that was exactly the same, it should be a 3.

“When we did it in our last sprint, it was an 8” the quiet guy said. “Remember, our agile coach said we shouldn’t revise our estimates for things we have done before or our velocity will not truly reflect our improvement.” Everybody else changed their numbers.  That’s leadership. When I talk about leadership, i don’t mean management. I mean the kind of leadership that comes from everyone on the team.

I am a leader because everybody is a leader. As they say in Kanban “Leadership at every level.”

Let’s see what the original article said:

3. Scrum strengthens leadership

Agile management often results in a shift in power relationships — in the best possible way, says Tom Ulrich. “One of the brilliant things about Scrum is that it removes title from the equation,” he says. “It’s not about your position, it’s about real influence.” And that influence, Ulrich says, arises from expertise, experience, and respect — especially the kind of respect that develops from a history of working together interdependently.*

When we say that Leadership isn’t a benefit of agile, I think what we are often thinking is that we aren’t getting more leadership from the top.  That’s good if we are getting it from everywhere else.  Here’s another question:

“So why do they pay me the big bucks?”

That sounds like a joke but it’s not. It’s a real soul searching thing. I spent a really long time getting to this position. As a Manager, it’s hard not to be concerned when the things you used to be responsible for are now distributed to the team.  If everybody is a leader, what am I supposed to do?

I’ll just defer to Kenny with some answers to that one.

“Traditional Leaders in Scrum organisations continue to provide leadership in their area of expertise.”

If you haven’t read Essential Scrum: A Practical Guide to the Most Popular Agile Process (Addison-Wesley Signature Series (Cohn), by Kenny Rubin you should.  There is an excellent chapter on Managers.

Leadership is not the same as management.

In traditional management, managers tell people what to do.  That’s not the case in agile.  This is where the second quiz question often comes in:

Which of the following are scrum values? (select all of the correct ones) (Source = The Scrum Guide).

  1. focus
  2. courage
  3. openness
  4. commitment
  5. respect

It’s a trick question. Actually they are all scrum values. We are so accustomed to multiple choice that most people assume one has to be wrong.  The one they pick is courage.

Why aren’t we seeing courage? Are we not recognising it? Or is not there?

Courage also comes from every level.  Not long ago, a VP asked one of our developers to do a quick project for him. “We are working on what we agreed to work on this sprint’’ she says.  “You will have to talk to the Product Owner if you have something you think has a higher priority.” He wasn’t just her boss, he was her boss’s boss. That’s courage. It takes some courage to stick to what you know is right.

Go forth and lead with courage.



Thank God You Are Here

On the “Thank God You Are  Here” TV show, a famous person opens a door. Behind the door, everybody is acting out a scenario where they are waiting for an expert to arrive and save the day. “Thank God you are here, doctor, now what should we do to stop the bleeding?” It’s scary for the actor opening the door because they don’t know what is going on. They have to figure out what is happening and how they can help. For a person like me, scenarios like that are very gratifying. I love being able to help. I want to use my skills to quickly figure out what is happening and to solve problems.

In 1998 I was looking for a job and my brother suggested I try web design. So I got my first job as a Project Manager in web design. I really didn’t know much about the web so I was trying to learn quickly. In my first week somebody mentioned Active X. I asked my brother what it was and I remembered that he said it was platform specific.

The next day I was sitting at a board room table with the client and Active X was mentioned.  “Yeah, but it’s platform specific.” I said.  The techies nodded. Fortunately nobody asked me a follow up question because that was all I had. I like knowing the answer. As a Project Manager, that was an important part of my job.

Years later, when I started at a new job, I was eager to get my hands into one of my new projects. However, I found it difficult to deal with a woman in the meetings who was scathingly critical of me. She was very negative. She shot down any of my suggestions and seemed intent on discouraging me. “You don’t understand how difficult this project is” she would say. Why would she do that?

Now I know why. After I worked at the company for a few years, I detected a pattern. New people would be hired and asked to work on projects. However, nobody talked to the people who were already working on them. The existing team wasn’t asked if they wanted help. No credit was given for the success that had already been made. People would judge their work without asking why it was done a certain way. No attempt was made to ascertain if they felt proud of their work. What impact is there on somebody who takes pride in their work when that responsibility is taken from them without consultation? In fact, they usually weren’t even informed.

As time went on, that started happening to me. As a result, I found myself acting like the woman that I met. I didn’t want to recognise somebody else’s contribution. I was doing perfectly well before you came along, thank you very much. If I am missing something, talk to me about it.  I might have a very good reason for my approach. If I’m overlooking something ask me about it.  Don’t just step over me because you think it should be done a different way.

In an agile environment, the expert scenario is dangerous. Rather than being an expert, you can help the team see what they are capable of. You gently guide us in the right direction. But we aren’t looking for one person who can swoop in and save the day.

Thinking back to the Thank God You Are Here show, why are the people in the other side of the door waiting for somebody to come along and fix the problem? They are the ones who know what is going on. Why aren’t we empowering them to do something? Why doesn’t anybody ask them for suggestions? I guess it wouldn’t make good tv. It does make good work environments.

Those of us who are used to opening the door and saving the day need to learn a new way of working. We need to recognise the skills of the people we work with. This is a very different kind of skill that is hard to master.  It can be done. When we do master the art of recognizing the talents of the people who work with us, do you know what they will say?  Thank God you are here.


13 Things That Surprised Me About China

I took a small group adventure tour to China so I didn’t do much research. I just showed up with my wheeled backpack and followed along. So everything was a surprise, some things more than others. These are some of the aspects of my trip to China that I found most surprising.

People seemed reasonably open

China is changing extremely quickly. Young people – like our guide – are actually really positive about it. I felt that our guides were sincere and open. We heard a range of opinions from our guides – didn’t feel like a rigid party line.

Luxury Stores

On one of those tourist busses in Shanghai we passed a Prada store. A few minutes later, we passed it again. Actually, no, it was a different Prada store. And another one. It wasn’t just Prada either. Not only is every major luxury brand there, there are multiple stores for each brand.

The explanation I heard was that not all Chinese citizens are allowed to leave the country. So for many wealthy Chinese, Shanghai is where they get luxury goods. Our guide pointed out that while his parents generation is concerned about saving for retirement, the young people are buying luxury handbags.


I am sure the air pollution is terrible but it didn’t seem that bad to us. We happened to hit some days with blue skies. Just for the record, I grew up in LA in the seventies so it is all relative. Are the skies as beautiful as Sydney? Absolutely not. Would I worry about raising children in Beijing? Absolutely! But spending a few days there it wasn’t as terrible as I expected.

I know there are environmental disasters in China. But we didn’t see them. In general things were cleaner than I expected

In saying that, I didn’t drink the water.

Hole in the ground toilets aren’t really that bad

Well, let me clarify that. CLEAN hole in the ground toilets aren’t that bad.

I made a few rookie mistakes the first few times but once I got the hang of it, it wasn’t as bad as I thought.

Don’t expect toilet paper. Carry toilet paper or tissues everywhere. I found it hard to teach myself not to throw toilet paper in the toilet. Also hard to get used to the smelly bins.

It was rare to get decent sinks with hot water, soap and paper towels. I found myself using antiseptic wipes to clean my hands.

Going to the supermarket by myself was really challenging

How hard can it be? It’s a supermarket! But I wandered the aisles for ages trying to find food for our overnight train trip. It was just really hard to figure out what everything was. I bought some cheese that tasted like a combo of white chocolate, cheese and something fruity. Didn’t eat much of that one. Everything – naturally – was labelled in Chinese and the pictures weren’t always obvious.

Tiananmen Square

We went to Tiananmen Square on the anniversary of the “June 4th Incident” of 1989 but the only evidence of that was our guide asking us not to speak about the protests. One of the people in our group saw a news story abruptly stopped on the BBC channel when they referred to the protests. Other than that you wouldn’t know it had happened.

You have to go through several security checkpoints to get in to Tiananmen Square and sometimes you have to wait a while but I didn’t find that surprising. When we went it was really hot. There is no shade. Just a big, mostly empty place.

Lemon Chicken and Sweet & Sour Pork

I always heard that the dishes we eat in Chinese restaurants in Western countries aren’t authentic. On our small group tour we only went to local restaurants. So I thought we were cheating when we ordered Lemon Chicken and Sweet & Sour Pork. Maybe not. Apparently those dishes are authentic in that region. Food varied a lot in different places. Generally it tasted like – well – Chinese food.

Security on the subway

It was also surprising that they had security checks (airport style metal detectors for your bags) at the train and subway stations. I have a passport bag that I wear around my neck with my passport and wallet. I took a lot of subways and trains and only once did they ask me to take it off. Also noticed a lot of people walk straight past the security without putting their bags on. But it was there.

I can live without Google

Think about that. No Google. One thing I realised is that Google is not just It’s how I get to all the other websites. I don’t remember the whole URL anymore. I just type some of it in. It’s google that’s completing my words. Google is embedded in all sorts of sites and apps.

In saying that, I didn’t really need google on the Great Wall. Or anywhere else I visited. Instead of using my phone as a constant entertainment device, I paid attention to where I was (novel idea). I talked to people. There was a moment on the train when I realised every one of us was reading a book. An actual book! How retro.

I used paper maps. Actual paper. Pens. I wished I had a highlighter. An actual highlighter.

I did use the internet in hotel rooms. Every hotel we stayed in had wifi but it tended to be quite weak. Without Google, I found myself using Wikipedia a lot. I do have VPN on my iPad but getting VPN and Internet access working long enough to actually accomplish anything was rare. I usually wrote emails off line and just sent them when I connected. The pictures I tried to send just failed.

No Facebook either by the way. I didn’t think I used it much. But I was travelling and I wanted to show off my pictures. I only got one posted on the whole tour.


I was flabbergasted by the infrastructure. Highways were well designed and had manicured plants along the edges. Subways led to pedestrian bridges and tunnels that got us where we needed to go. Particularly in Shanghai and Beijing, everything worked.


Seriously, some of the train stations were more modern than a lot of airports I have been to.

In major cities, they add new subway lines constantly. We complained that the maps they gave us at the hotel were old. Turns out the subway line near the hotel had just been added this year. I shrugged and drew it on the map.

The bullet trains were amazing. Our itinerary included a 13 hour overnight train but since a new bullet train was just added, the overnight train was replaced by a 3 hour bullet train.

We did take one overnight train which sounded a bit daunting but we had a great time. It wasn’t new but we had what we needed and we slept well


Honestly I was nervous about the internal flight we had. I was expecting a third world experience. Instead, I found myself at gigantic, modern airports. Everything was new. New planes, professional staff.

I only thought of Xi’an as a place where farmers found the legendary warriors. We were all surprised to arrive in a gigantic airport. Xi’an is a city of 10 million – of course it makes sense that it has a big airport. Walking through baggage claim was a huge eye opener.


Apparently you can’t register a car that is older than ten years. So much for my 18 year old Honda at home. Not the best environmental decision but it means the cars on the road are new. Our guide told us that one of the things that surprised him about Australia was all the old cars. Go figure.