All Posts By

Melinda Harrington

Life

With Love and Respect

One of my treasured possessions is an inscription Professor Rassias wrote for me which continues to comfort me in times of doubt. He signed it “with love and respect, John.” With love and respect. That was how he treated everyone.

At night when the cleaners came in, we would be the only ones in the building and John was so supportive of their work (even though he would whisper to me that they didn’t do a very good job). The team that worked in Wentworth Hall told me he was the only professor who knew their names.

I consider myself fortunate to have worked in John’s office for years while I was at Dartmouth and after graduation. I had a rare glimpse behind the curtain of the most hard-working and loving man I have ever known.  I saw countless students come to Wentworth Hall looking for inspiration and understanding and receiving what they sought.

It means so much to me that he was able to see something in my twenty-two year old self at a time when I couldn’t see it myself.

“To Melinda, A truly authentic human being whose energy brightens our lives.”

Right back at you John.

With love and respect.

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

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

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

Life

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.

 

Work

Why a traditional IT project is like an elevator

I have never re-designed an elevator. But the elevators in the building where I work were recently redesigned at the same time that I was working on some website re-designs. It struck me how similar the process was.

The arrow points up; the elevator goes down

Since the upgrade of the three elevators in our building, the indicator triangle above the middle elevator has pointed up when the elevator is about to go down.

The analytics department studying the impact of the button pointing up may determine that the user experience hasn’t been greatly affected. Users, after all, are adaptable. Although a few people may have gone up when they intended to go down, they have adjusted their behavior. Essentially we have all learned that if we push the button to go down and the middle elevator arrives, it will point up but go down. New people may accidentally go the wrong way but they end up going down.

I think anybody in marketing would have no problems explaining that this was in fact a successful upgrade. People just needed some time to adjust to the new, superior interface. Any complaints are just resistance to change.

As a user of the elevator I want to get down five floors as quickly as possible so that I can go home

Experiencing the upgrade of the elevator as a user, I suppose the first thing that strikes me is the lack of consultation with me and – as far as I know – with any of the other users.

Had I been asked, I probably would have said that the elevators provide the core function that I want. They go up and down from one floor to another and I would want to retain that. However, they are prone to stopping in between floors. I think that is a bug that should be addressed since the people stuck in the elevators don’t like it. So if there is going to be an elevator re-design, making it more stable would be what the users would request.

So we got music

Music? Yes, it’s kind of tinny and it kicks in halfway through the journey. Nobody really wanted it and we don’t quite know what to do with it. I don’t know anybody who would have actually asked for the music. But it’s there. We can’t turn it off.

We got the arrow that points up

I did point out to the people working on the elevators that the arrow pointed the wrong way. They didn’t seem too interested. They were just doing what they were told. I suppose it wasn’t in the requirements. Nobody said that the arrows had to point the correct way. Now, the project has been delivered and that will have to go in a future phase. I don’t know if there is a future phase. It has been a few years now.

The doors open really slowly now

You can tell that the elevator has arrived at your floor because it stops. And then for a few seconds you begin to wonder if maybe it’s between floors because nothing is happening. Then just when you are ready to hit the panic button, the doors open slowly.

I don’t know if anybody has any metrics for how quickly the doors opened before the upgrade but they didn’t feel slow. Now they do. We can’t provide any data about the slowness so apparently we will just have to live with it.

So in short

The elevator upgrade is like a lot of traditional projects because:

  • Nobody consulted the users
  • New features were introduced that nobody wanted
  • Critical features that used to work no longer work
  • New issues were introduced that haven’t been fixed
  • The people who sponsored it consider it a great success
  • The work was all done at one time and wasn’t ever revisited.

We’re getting used to it.

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.

Life

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.