Browsing Category

Work

Work

MBOK – A team making themselves agile

Let Teams Figure it Out” by John Cutler.

https://hackernoon.com/let-teams-figure-it-out-eefbf1a44ae8

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?”
Work

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.

Work

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

Work

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.

Kanban_Track

Boxes slide on a track

Kanban_board

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.

Paint-board

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.

Baum_the_end

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

Work

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:
postits

“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.

Post-it_explained

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.

Engagement
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.

arrow

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:

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.

TheEnd

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.

 

Work

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 http://blogs.collab.net/agile/agile-wont-make-you-faster#.VuyuuxjXLi8

“shorten the time to feedback”

          Ryan Martens https://www.rallydev.com/blog/agile/how-does-agile-deliver-time-market-savings-50

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

          Mark C. Layton http://www.dummies.com/how-to/content/10-key-benefits-of-scrum.html

“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 http://www.velocitypartners.net/blog/2014/05/06/read-my-lips-agile-isnt-fast/

“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 http://www.techradar.com/au/news/world-of-tech/management/busting-the-myths-of-agile-development-what-are-its-real-benefits–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?

LEADERSHIP

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.’’

Wow.

Really?

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.

*https://www.scrumalliance.org/employer-resources/top-3-benefits-companies-see-during-the-transition

Work

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.

Work

Cult of the New Person

Let’s say you are in management and you hand over an idea for the “Galaxy” project to somebody who has just arrived at your company. The response is usually: “yes, absolutely we will figure this out. No problem, leave it with me.”

You present the same idea to somebody who has been at the company for years and they’ll say “yeah, but remember when we tried to introduce the ‘Aurora’ project three years ago and half of the customer service team quit because they couldn’t cope with the onslaught of complaints? And, are you sure the flux capacitor can handle all that data? With the ‘Life Star’ project five years ago, it was brought to a halt and we were up for three days trying to get it going again. There are still some issues we haven’t resolved with that.”

No wonder that management likes new people. They are really positive. They are also usually more expensive which no doubt means they are better.

So the new person forges along with their new project. Well they take a few steps forward confidently. Then, they sidle up to the old person. “I just have a quick question, about that flux capacitor…”

The new person continues and it turns out that they bump into the same kind of challenges that the old person does. The flux capacitor can’t handle the data and the customer service team is overwhelmed with all the complaints.  Over time, they become like the old people. Experienced, skilled and undervalued.

Like most people, I have been a new person before. But I have been an old person a lot more. That’s why I am grumpy. I am really loyal to companies. I don’t just jump around in search of something better. I focus on delivering the best I can where I am. I don’t spend a lot of time telling everybody what I am working on. I just quietly deliver. But I get a bit irked when somebody new comes along and says “we’ve never done this before.” Well, yeah, you haven’t. But we have and we did a damn good job.

New people in positions of authority often want to change things. They want to fix everything. Problem is, people who are already there don’t always want to be fixed. They might actually be doing a really good job. Experienced people have a really good insight on what could be improved. Let’s say you are getting things 90% right. Might make sense for the new person to talk to the 90% people and figure out how to address the other 10%. “Hey, how can I help you with the little stuff?” That’s not usually what happens. Lots of babies and bathwater flying everywhere is what usually happens.

Don’t get me wrong, we have had some fantastic new people join us lately. When you are under the gun for a long time, particularly if you are understaffed, you don’t really have time to look at a better way to do things. Our new people have been able to look around and make a few suggestions that are really helpful.

New people have the opportunity to focus. They aren’t being distracted by the old, messy stuff. They have a blank slate. They aren’t clouded by the complications.

It’s not unusual for a new person to start asking the old people to do something. I had something to do. That’s why we hired you.

The people that matter (management, executive team – whatever) tend to concern themselves with the bright, shiny things. That makes sense. Focus on what is important. Except, of course, that sometimes the existing team is so busy with the not so shiny stuff that it’s really hard to find some time for the important stuff.

The longer you are there, the more of the existing stuff you are still stuck with. They don’t give that stuff to the new people. So you waste people with the most experience on all the dross.

That’s the way it is. Until I decide to be a new person.

Work

Indicate and Check Your Blind-spot

Years ago I picked a fight with my best friend’s boyfriend because he wasn’t looking and indicating when he changed lanes. “There’s nobody there” he replied. I learned to drive on the LA freeways and I know that in the blink of an eye there can be another car next to yours. You always look. You always indicate. Most of the time you are right, there is nobody there. But that time you are wrong might be the last time.

Fortunately for everybody I am not a driving instructor. I work in software. But the same rules apply. If you are going to pivot, you need to let people know. Don’t assume it doesn’t impact anybody else.

Recently I was working on a re-design that wasn’t going particularly well. There was one area of functionality where we could choose to retain the old design or forge ahead with the new design. There were a lot of edge cases and secondary workflows in this area so different developers had tasks that were impacted by this change.

So I sent out an IM @all to let anybody who wanted to be part of a quick catch up to join us. We ended up with two POs, our QA lead and a few developers getting together to agree on the overall approach so that they could each go forward with their individual tasks. Stick with the old design or continue on with the new one.

Half way through our meeting the Director of Engineering sent us an IM to say that the Vice President had already made that call. The decision had been made to go forward with the new design the week before.

It wasn’t a bad decision. I probably would have made the same decision myself. I think he made the decision assuming we were mostly done when in fact we were only mostly done with the ‘happy path’. Nevertheless, we could deal with the edge cases and secondary workflows and we all agreed the new design was better.

The point is the VP didn’t indicate. He didn’t look to see who would be impacted if he changed lanes. He didn’t update any of the tasks to let the POs and developers know of the decision that had been made. In this case, none of the people working on the tasks knew of the decision that had been made.

It’s not always practical to have everybody in every meeting. Nobody wants endless documentation and discussion but if we are going a different way, everybody needs to know.

This happened early in our Agile transformation.  I’m not saying that it never happens any more but Agile practices are protecting us more now. Agile ceremonies may sometimes seem like overkill but they are actually a good way to indicate your movement to a wider group rather than assuming that you aren’t impacting anybody else.

Work

I don’t think this way any more

Disclaimer:  I was going to get rid of some of my early writings but I decided to keep them because I realize they show that I have changed. ”Journey” is over-used but I have to remember that I am learning and others are too.  You may be here.  Or you may be reading what I am writing now and smiling because you know I will move on from there.

Scrum principles may seem like a radical departure from how projects have traditionally been run but ultimately the big picture is pretty much the same. Comparing ‘waterfall’ to ‘agile’ often assumes a pure implementation of both when I find my own practice of Project Management to be much closer on the spectrum to agile without being strictly agile.

Methodologies aside, as a Project Manager, I take the requests of stakeholders, distill them into reasonable tasks, list those tasks in order of priority, estimate how long the project will take, agree on how much we are going to deliver and do what it takes to deliver the project by the deadline. During the project, I answer questions, make decisions about the scope and remove obstacles so the team can deliver. If we can’t meet the deadline, we decrease the scope, increase resources or negotiate a later deadline. As a Project Manager my responsibilities can vary greatly as I do whatever it takes to get the project delivered.

Within a scrum/agile framework, when playing the role of PO, I facilitate user stories from stakeholders, arrange them in order of priority (backlog). The team breaks them down into tasks, estimates the relative scale of each task and agrees on what is included in each sprint. During the project, I answer questions and make decisions about the requirements and remove obstacles. We deliver work that is tested and potentially shippable in completed sprints. As a Product Owner, my role is clearly defined.

Throughout my career I have been a Project Manager, a Program manager, a Producer, a Director and a Consultant. Regardless of which title I have, it is important to me to be involved in the strategy – not just ‘what are we trying to deliver?’ but ‘why are we trying to deliver it?’

PS:  How have I changed? Since I wrote this, my thinking has evolved. I now believe that agile is a radical departure from how projects have traditionally been run.