More storypoints completed = More effective?

Here are 2 stories…

Story #1

Manager (to team): “I would like you to become more effective!”
Team: “No problem, we’ll just double our story point estimates, then we will complete twice as many points next sprint.”

What will the manager answer?
A. “Great! I’ll say that to my boss”
B. “Well, that really don’t make you more effective, only the metrics changed”

Story #2

“In my team, we use estimates. After the sprint, the manager says: “You did not deliver all you promised”. The team feels bad and decides to increase the estimates as a buffer, to ensure they won’t take too much into the next sprint – without telling the manager. The team completes everything the following sprint and the manager is happy. The next sprint the team silently increase their estimates a bit more, only to complete a higher amount of points at the end of the sprint. The SM and the Manager is really impressed because this team now completes more points than any other team.”

Story 1 is one I made up (kind of), and story 2 I was told by a friend of mine, when he wanted my opinion on the topic “Storypoint inflation”.

Putting it as simple as in story 1, most people will believe B is the best answer – without hesitation – and will not accept the suggested solution to just devalue the story points. But story 2 seems to appear more often, even though the only difference compared to story 1, is the speed of story point inflation. So why does it happen?

Before I elaborate on that I will say that I see indications of a company not having an agile mindset – They might be “doing agile” rather than “being agile”. That will be wrong for me to conclude with my limited knowledge about their situation, and it will be naive to think that a few words about “Storypoint inflation” and “Commitment” could solve their challenges. Having said that, I still believe that these few words on the topic, could be a first small step, to changing the mindset in an organization like that. And here is how I would go by it as a ScrumMaster.

  • Coaching the team and the manager to believe the “sprint commitment” is a forecast rather than a promise.
  • Ensuring storypoint estimates are for the team, and the team only!
  • Fulfilling the managers need for measuring effectiveness.

Coaching the team and the manager to believe the “sprint commitment” is a forecast rather than a promise.

If the manager, the product owner, or a team member, or anybody else for that matter, treat sprint commitment as a “promise of delivery”, “commitment” is not used as intended. In software development we never build something that we have done before. Therefore I find it difficult to believe that we can foresee everything, and that makes it hard to make a “promise to deliver”. Though, it should still be the goal to deliver. We should have the intention of delivering, including considering and talking about what makes it possible or not.

Theres a good read, of why “Commitment” was changed to “Forecast” in the 2011 Scrum Guide. Commitment vs. forecast on Scrum.org

If you think this means, commitment is no longer needed, you might want to read this as well: Scrum values – Commitment from Scrum.org

Coaching the team and people around the team to use “Forecast” instead of “Commitment” (as a promise to deliver) can give the team the space they need to focus on developing good software. If the manager is still in a need to know about progress, and when the team can deliver, Invite him/her to join a demo, so he/she can see the product. After all, the primary measure of progress should be working software.

Ensuring storypoint estimates are for the team, and the team only!

Storypoints is NOT a metric for measuring effectiveness, and it should NOT be used for reporting to management. I can’t state this clear enough. Nevertheless, this seems to be the case a lot of places. I think it´s because storypoint estimates are numbers, that are easy to work with, if you come from a traditional way of working with projects. But this way of using storypoints, causes some uintended problematic behaviour.  So, what to do about it?

Storypoint estimation is a tool for the team. It serves two main purposes. It is a tool to get a good dialogue going in the team, and it is a tool for forecasting. Everybody around the team must understand that the estimates made by the team, is for the team only. Any interferences with the estimate and/or estimation process from someone outside the team, is in risk of resulting in storypoint inflation.

Does a team even need storypoint estimation? No! If the team have sufficient dialogue, and is able to make forecasts to managers and other stakeholders, the team does not need to do estimates at all. One way of finding out, if the team needs it, is by stop doing it, for a fixed timebox, and then evaluate. If not all aspects are covered during team dialouge, it might be a good idea to use Storypoint estimation.

Fulfilling the managers need for measuring effectiveness.

So now we have made the manager and other stakeholders understands that a “forecast” is something we aim for, which is not the same as a promise. The team are now estimating storypoints only for the purpose of the teams own dialogue, and as a tool for forecasting, and only if they benefit from it themselves. But the manager still needs to report to his manager how effective the team is working and now we’ve just left him hanging there. Some might argue that is should not be needed for the manager to know this, or that managers are not needed at all, but I’ll bet you will have a hard time explaining this to the manager. And if we cannot change the organisation, we have to deal with it somehow.

So, what if the manger asks: “How effective is the team at this point?”, and the team could answer “We’re at 87%”, Would that work?

My good friend and ScrumMaster colleague, Lars Buhl Schamaitat, made this short presentation, and if you can relate to some of the challenges in this post, this might be of your interest. Enjoy

ScrumMasters are stupid

Are you a ScrumMaster? Have you chosen to build your career as a ScrumMaster? Yes? Well, that’s stupid! I mean: It is a job where you will always face resistance to change either from your team or from the organization around the team, or even both. They may not even understand the role. In the beginning you might not even truly understand it yourself. The successcriteria of a ScrumMaster is vague, and difficult to navigate after, so you will constantly question if you are doing a good job.

To some, a job like this is self-torture. It can be sometimes, but other times it is the most satisfying job – at least in my opinion. So if you are as stupid as me, and keep on trying, because you think it is the right thing to do, this blog post might be of help to you.

The purpose of this post is NOT making you capable of avoiding the traps I fell in, because I believe you must learn from your own mistakes. Instead I hope it will ease the fight of getting out of the traps, so the learning process for you, will be shorter than it was for me. Or as a minimum you can identify with the challenges, making you aware, that you are not alone – which can give you some energy to hang-on and continue what you are doing.

Trap 1: Believing you have the skills to change the world after a 2 day ScrumMaster course

How could I be so naive to think that a 2 days ScrumMaster course would solve all the challenges I faced in my team? Writing this sentence seems so stupid, but nevertheless, I felt I knew everything, and I had it all figured out – If just my colleagues would do as I instructed them to.

Looking back now, it was not surprising that I faced a lot of confrontations, when I told businessowners, that have been in business for many years, to change their way of working, based on the 2 days course I have attended.

I learned, the hard way, that being a ScrumMaster is an area of expertise, and I didn’t have the skills at the time to change anything, so my ScrumMaster career could easily have ended there. But my belief, that this way of working would mean better products and higher jobsatisfaction, was still intact, and it kept me in business. I was longing to dig deeper into Scrum and other agile practices to gain knowledge, and experiment with my team to change the world a little by little – Starting with the “world of the team”.

Be humble and let your lack of skills, be the motivator to develop yourself.

Trap 2: Being afraid of “Scrum-buts”

I met the term “Scrum-but” on slide 2, on my Certified ScrumMaster Training. It could be due to my lack of knowledge at the time, or the communication skills of the trainer (or both), that let me to think that deviating from Scrum was dangerous. “Dangerous” like somebody would die. I went home from the training believing that I needed to implement the entire Scrum-guide, word by word. At any cost. When entering Scrum forums and debates online I also get the impression that some other people went home with the same feeling.

Guess what? Nobody dies from deviating from Scrum. In worst case you won’t get all the benefits from Scrum, if you’re leaving things out or doing it differently than prescribed. That doesn’t mean that deviating won’t be the right thing to do in your team. The team might not be mature enough to cope with a full implementation. If the team hate a specific ceremony, or don’t get it – then don’t do it. Show them you care about their valuable time. Introduce the ceremony again when the team feels a need for it, or it can help the team solve a specific problem.

Of course, you should know what Scrum is, and what is isn’t. And of course, you are not allowed to state that Scrum doesn’t work until you have tried a full implementation. And if you are stating it doesn’t work, you are most likely doing something wrong.

Don’t be afraid of Scrum-Buts – be aware. Don’t be afraid of deviating –  experiment, inspect and adapt.

Trap 3: Getting too excited about a tool

During the journey of building your ScrumMaster toolbox – I’m not talking about the physical box of sticky notes and markers, I’m talking about the toolbox of agile tools, practices, methods, theories, activities etc. – you occasionally run into a tool that inspires you so much that you cannot help introducing it to your team. Only to find out that the team hates it and/or find it useless and resists using it.

It is frustrating to see your teammates don’t “see the light”, and the backbone reaction of a ScrumMaster is often to try to convince them. I have done this several times, and unfortunately I don’t think I have done it for the last time. Preaching is not helping – You will waste your time like a Christian trying to convince a Muslim to convert (or vice versa).

The reason for the team not wanting to use the tool, could be either because they don’t see the problem, the problem doesn’t even exist or simply because they don’t think the tool can solve the problem.

Therefore, when trying out new tools, ask yourself: What problem is it going to solve? Does the rest of the team share the same problem?

If you can’t answer the first question, don’t even bother implementing the tool. If the answer to the second question is no, then either let it go, or help the team see the problem before experimenting with the tool.

Trap 4: Not acknowledging peoples thoughts or perspective

As a dedicated ScrumMaster you are most likely a few steps ahead on your agile journey compared to your teammates. This can easily end in a situation where you say: “Yeah yeah, I understand, but here is what you should do”. Your suggested action might be the correct one, but it slips over the head of your teammate and nothing happens.

In the beginning I was getting frustrated of why my teammates wouldn’t listen – after all I studied this subject, so I knew what I was talking about. I tried to explain solutions to problems I spotted. But I couldn’t solve the problems I spotted, and even worse, my teammates felt I wasn’t solving their problems either. After I started caring more for what they saw as problems instead of what I thought was the problem, it was a lot easier to help the team. Asking questions to my teammates rather than explaining solutions helped me identify and solve the real problems. It also helped me selecting the right tools to solve problems. I still see problems the team doesn’t see, but I tend to prioritize doing something about the problems the team sees. Simply because the effect is greater.

Acknowledge your teammates thoughts and perspective and care about them as if they were your own, will help you become a great ScrumMaster. If you spot a problem, ask you team if the see the problem too. If they don’t, acknowledge it and let go, for a while.

Final thoughts

If you made it so far reading this post, I assume that you are still hooked on a career as a ScrumMaster. That’s great. You have at least showed persistence to some degree – keep it up, you are going to need it. But I’ll tell you, the reward of seeing your teammates or organization benefit from your work, even in small scale, makes it totally worth the effort. I have even come to a point where I enjoy the resistance and see it as the next hurdle I need to jump – but it may also just be stupidity in disguise.

Agile or Not – Retrospectives is key!

As human beings, it is our nature to learn. We start learning when we are small, we learn as we grow up, and even as adults. We learn about life – to make decisions. We learn more – to make better decisions than previously. We do it all the time. It’s our nature. We are hardwired with this skill.

Regardless how natural this come to us when it’s about daily life, and only ourselves involved, it becomes something extremely difficult, for many many people when we put ourselves in a workplace together with other people.

This could be the result of “management” – The command and control kind of management, that manages and control people. It kills initiative from individuals and it kills creativity.  Which again will result in poor performance, for the individual, the team, the department and the company.

If you have been studying “agile”, whether it’s Scrum, Kanban, SAFe or any other agile framework, you will notice that when you cut it to the bone, it’s all about creating environment for – you guessed it – learning. It is about learning as an individual, a team, a department or an entire organisation, learning about  your product, learning about your work processes. Learning, so you can make better decisions in the future.

Implementing an agile framework prove to be “not as easy as it sounds”. Not because it is of no value, but because it requires change. Change in behavior, change in mindset, organisational changes and more.

Maybe you have tried agile methods and found “it wasn’t for you”, maybe you are already in the process of implementing agile methods, or maybe you just don’t see the point. Nevertheless I believe you would like, your team would like and/or your organisation would like learning to make better decisions in the future. Luckily there is a very powerful tool, which you can implement regardless of which agile framework you are using or not using.

It is called “Retrospective”.

It is a powerful tool which is about gathering people, for a fixed period of time and have them reflect upon and learn about “they way we work”, and based on that decide small things that can be done differently next time. And then keep doing it.

If will foster individual initiative. It will boost creativity. Empowering people through well conducted retrospectives will eventually make you team, department, product, projects and/or organisations better. Nice!

To get started you need:

Doing retrospectives does not solve your problems by it self. But it will help you uncover known and unknown circumstances that have impact on whether you perform good or bad. Based on your findings (learning), you can decide on what to do differently.

Visualisation of “Very very important tasks”

“I have this very important task that needs to get done. Who will do it?”
This is a phrase often heard, and every ScrumMaster eventually will have to deal with. A mature agile team will have it’s work agreements and processes to deal with this type of request in an efficient manner. However, not so mature agile teams, and teams in a early state of their agile journey, should be very alert when hearing this sentence, as it maybe a symptom of an underlying and more serious problems.

But why should we be alert? It’s just <someone> who wants to get this task done, what is wrong with that?

There is nothing wrong with the desire to get things done. After all, this is what companies live from. But there are many underlying problems that this particular sentence can be a symptom of.

In a software development team of mine, we faced failed sprints. Every 2 weeks. Mostly due to this type of requests. Ever changing priorities was one reason for not meeting sprint goals. The solution to this, according to the “Scrumbook”, is obviously to lock scope of work for a sprint, and move the incoming requests to succeeding sprints. This just didn’t work for us. Developers felt this was the same as saying “No, your tasks is not important”, and product management did not like to hear that. It worked for nobody. We did not have a full time product owner, which was also a part of the problem. I have written about this subject in another blog post https://agilereflections.dk/2016/10/12/lack-of-product-owner-what-to-do/

All tasks are important, otherwise it won’t be a task in the first place. Therefore the argument “I have this very important task” is not an argument for getting the task first in line. Believe it or not, adding another “very” or even “very very very” doesn’t make the argument better. So let’s stop discussing if a task is important, let’s discuss how important is it compared to the other task we have, seen from a company perspective. This may sound simple, and result in what we know as a “prioritised backlog”, but it can prove to be difficult to understand for some – even people with agile training.

It was a big issue being part of a team who got “slammed in the face” every other week with “The sprint failed – Again”. So to keep our motivation up, we decided to kill “sprints”. With that decision our board turned into a plain kanban board, where the highest priority was on top. This gave instant advantages such as:

  • As developers we could say, “We can do the task, it will be placed on our board”
  • Product management no longer felt their tasks was not taken seriously.
  • Priorities became very visible, and a constructive dialogue instantly began.

Even though the amount of task on the board exploded, it was a relief for the team, because, we were able to focus on the task on the top of the board, and we could be flexible. As product Management experienced that the tasks on the top of the board got done quicker that the others, they began discussing priorities from a company perspective rather than a personal perspective.

The visualisation of work was the first step towards managing the flow of work, rather than managing people to do the work.

 

 

 

 

 

 

Doing Scrum – Leading the way – Learning agile

“I have heard Scrum is ‘the thing’, please google it and implement accordingly!”. This was the exact words from a previous boss of mine, when he wanted me to make our team deliver on time and with the desired quality. This was the beginning of my career in “doing Scrum”.

I have learned quite a few lessons since. In this blogpost I will deal with a few of the hardest challenges I have faced. You will most likely not learn from my mistakes, but being aware of them, may help you overcome them faster when you face them. Continue reading “Doing Scrum – Leading the way – Learning agile”

Need more details!?

Product Owner: “Please code this feature”.
Developer: “I can’t code this, until I receive a better spec”.
PO: “Just go ahead, I want your input to this as well”
Dev: “Alright”
— Developer codes it like he believes is the best, and show it to the Product Owner —
PO: “Why wasn’t _this_ included?”
Dev: “It wasn’t a part of the spec”
PO: “Well, I think it is kind of obvious, and I wanted your input as well”

Continue reading “Need more details!?”

Lack of Product owner – What to do?

I often hear from ScrumMasters and Agile Coaches stating, that you cannot have a succesful Scrum implementation without a Product Owner. The importance of the Product Owner can not be discussed, but there are “everyday situations” out there where a Product Owner for some reason is not available, as much as desired, and for sure won’t be for  period of time. Telling the Product Owner to be more available won’t help anything, and calling off the desire of becoming more agile, doesn’t seem to be the solution as well.

Continue reading “Lack of Product owner – What to do?”

Let’s call off Scrum!

A software development team, had been “doing Scrum” for years, since it was decided that Scrum was the “way to go”. A classic. All meetings were conducted, but gave no or little value. It was just accepted like “that’s what happens when Scrum meets reality”. Failed sprints were the standard, frustrations were building and unfortunate leadership mecanisms were “needed” to get things done.

When I was appointed as the ScrumMaster, I quickly realised that I had to do something drastically to gain the team’s trust to Scrum, and to build the team’s trust in me, as a ScrumMaster. Especially because I do not have a developer background. I had to relaunch Scrum in a way I had never tried before…

So I said: “Let’s call off Scrum!”

Continue reading “Let’s call off Scrum!”