Author: Melinda Harrington

A few background details. First off, our organisation has Principles that really resonate with us; we are on board with our purpose and it guides everything we do. Individual Scrum Teams also have their charters. Nevertheless, what we were looking for was some principles that would help us make decisions for our Product Team (a group of 6 Scrum Teams). When we use the term “Product Team” that is inclusive of Engineering, Product and Design.

We started with inspiration from other organisations. Principles are easy to find. Lots of organisations and teams post them. I won’t share all of the examples that we found because I think it’s useful to find your own. I wasn’t 100% convinced that starting with a list from others was the right way to go but it’s what we had agreed to do so I went with it. Generally, it’s nice to brainstorm your own things but these are so theoretical, I found it really useful to have a starting point.

For an example of what to look for, these IT Revolution DevOps examples really resonated with me. Interestingly, they actually call them “Ideals” but they were the kinds of things we were looking for.

https://itrevolution.com/five-ideals-of-devops/

We compiled a list of these from a lot of different sources, just think about organisations you respect and search to see if they have published something. It actually ended up being a really big list, about 70 things. Each thing had a short description in the spreadsheet and a link to further reading.

First thing we did was ask everyone on the Product Team to rate each of these items based on how important they thought it was for us to address them right now. 1) means “This is important, would help us make different decisions and I am extremely keen to include this” and 4) is “Unimportant or irrelevant to us right now”. Everyone rated the items in a spreadsheet individually. We also asked them to add any additional Principles they felt should be included.

The next challenge we had was with terminology. Although we had agreed to do an activity around Principles, many of the things that ended up on our list didn’t feel like Principles to me. Although I struggle to explain the difference, I thought it would be useful to separate the Principles and Practices. I’ve also been using the term “Values”. There is probably an actual difference between “Values” and “Principles” but in practice, they all seem the same to me so I use those terms interchangeably.

To help people understand one way of differentiating between Principles and Practices, I added these slides with XP Principles and Practices. (I got them from this blog post https://www.altexsoft.com/blog/business/extreme-programming-values-principles-and-practices/ but ultimately the source is XP)

Each Scrum team had their own workshop. We are all remote now so we used Miro for our workshops. In real life, you could use actual post-its for this. Miro has a feature where you can create virtual post-its by just copying from a spreadsheet and pasting into Miro so that’s what I did.

The Scrum teams divided these 70 things into two buckets “Principles” and “Practices”. I also had an “I don’t know” for things they just couldn’t figure out. At the same time, I asked teams to group items that were the same. The Post-Its didn’t have much detail but the teams had the spreadsheet to refer to for more info. Everyone works at the same time, if anyone disagreed with the placement of an item, I asked them to put it into “Don’t know”. We actually just left the “I don’t knows” alone because I figured if we didn’t know what they were, they were unlikely to be something we wanted on our list.

Once we had the two categories, the team took a few minutes to reflect on the data. Then they dot voted on the values that resonated with them the most.

After that we ranked them and picked our short list. I didn’t enforce a strict number of items – around ten. I also told teams it didn’t have to be the items that got the most votes that made it to their short list. If there was something that mattered to them, they could put it on their short list even if it didn’t have a lot of dots.

One of the interesting results of this activity is that I found that some of the things that I assume are just the way everyone works now didn’t resonate with everyone on the team. Why wouldn’t you just do Continuous Integration? Now I know I need to ask that question.

As an Agile Coach, the fact that they didn’t rate “Agile Software Delivery” gave me some pause but it’s actually not that surprising. I’m always teaching the teams to do things because they provide value to us not because they are branded “Agile”. So basically they picked all the “Agile” things, they just may not have realised that’s what they were doing. Looks like I have to do a bit more teaching on the origins of these concepts.

After we were done with the Principles, I asked the team to have a look and share any observations or insights. Does it look like a good list? Are we missing things? anything we don’t want other? When they were comfortable, we moved on to the Practices.

The Practices went into two categories “Just do it” and “Debate it”. If they couldn’t agree, it went into debate it.

For our leaders, this is great insight. If they want to implement a change that all the teams put into the “Just do it” category, they know people are already on board. If, however, they pick something from the “Debate it” section, they realise that there needs to be more discussion.

Who is going to make the decision about these Principles? Our leaders will take the team input but ultimately they will make the decision. It’s not 100% democratic. For example, a team may not have chosen “You build it, you run it” but as an organisation, that may be the choice we make.

The way I see it, we don’t have to do things my way. However, I want a chance to express my opinion. This activity gave everyone that chance.

WHAT PROBLEM ARE YOU TRYING TO SOLVE?:

Teams that just go with the first Action Item they think of in a retro without considering other possibilities or the consequences of the one they picked.

SCENARIO

The team has had a lively retrospective conversation, complained about lots of stuff, reminded each other what a great team they are and now it is time for an action item. Unfortunately, they only spend a few seconds coming up with an idea and a few more agreeing to go with it. Of all the things they could do, why have they chosen this one?

Let’s say the problem is that someone on a higher floor has requested weekly updates. Noisy person on your team suggests that we schedule a meeting once a week to provide a status report. All in favour? yep, off you go to lunch.

You are biting your tongue because you have been here before and you know what the pitfalls are but you know your team needs to figure these things out for themselves. But how long is this experiment going to run before the team figures out that it is not a good idea? Sometimes you might need to step in and teach but before you do that, try to get them to think it through. If you can encourage the team to think about consequences before they try an experiment, they might not have to make every mistake for themselves.

THE ACTIVITY

This activity is not one I designed but I have been doing it for so long that I don’t know where it came from. Originally, it was introduced to me as a good activity for teenagers because teenagers are notoriously bad at thinking of consequences. I have repurposed it to use with Scrum teams.

DEFINE THE SITUATION

In my example, the situation is that someone has requested weekly updates. The situation is whatever came up in retro that you want to do something about.

BRAINSTORM OPTIONS

This is the part where I tell people to go wild. One option would be to ignore this person. One option would be to give up and quit your job. Make sure to also include things that you would actually consider doing. You could: Invite the person to your Daily Scrum and Reviews. Teach the person how to read your Burn-Up Chart and show them where it is. Talk to the person to truly understand what it is they need.

Ask everyone to do brainstorm a few options.

BRAINSTORM CONSEQUENCES

Do this together. I like to start with the crazy ones. Let’s say we ignore an important person, what could happen? Maybe they are the kind of person who will forget about it next week. Maybe this a toxic person and we know that he will go ballistic. Then what will happen?

The magic here is in the conversation. Once you have spent some time really thinking about the consequences, it’s much easier to pick an option. The team has agency, they can decide what they want to try. However, they are responsible for the consequences of selecting that option.

Scheduling a weekly meeting will cost you a lot of time. Talking to the individual is likely to result in a compromise. Now he knows where to see the information radiators that are already available to him so he can get the information he needs.

Here’s hoping your team will pick the option that is likely to result in the best consequences. If it doesn’t, you’ll have a topic for the next retro.

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.

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.

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.

Note: this was published in “Agile Today” but the web version is not live any more.

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

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

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.

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.

 

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.

(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