Dec 08

Make sacrifices if you want to change

zurbaran-agnus-dei-lamb-of-god-madrid-1339x800“We only do scrum where and when there are problems within the company” the guy said on the other end of the table.”Otherwise we just keep doing what we are doing”. I almost dragged his ass across the table. I often hear this. People think that Scrum is something you only do when you want to solve a problem, as if it is a short term fix. The silver bullit you can fire and then all is solved. Well I hate to bring this to you but it is not. Scrum has to do with organizational change. Once you start to implement, the effect will be noticeable throughout the business. I agree that Scrum is not something you do just for the fun of it. You have to realize why you need it and what you hope to achieve by implementing it. But once it is running it is very difficult to go back.

I also agree that Scrum is not something you do when things are going great. It is something you do when things are not going great. When revenues from developed work are not up to the standard or could be better. It is not so a team can perform better and management can lean back in comfort. And when suddenly things change and work is not delivered as planned by sales, you stop Scrum and go back to the old way of working with micro management. I also see this a lot. “We really have to deliver on that deadline so we quit Scrum until things are smooth again”.

The biggest challenge is to get a business to see that when you want more revenues, better quality work and delivery of work that really has value, you can work with Scrum but you need to go all the way. It is organizational change. Everything needs to change. People have to start working differently. The old ways will have to go, and if that means that people have to change or even have to go, then so be it. I’m a big fan of Ricardo Semler and he said, more or less in these words, that a company is not a family. People come to work, provide a service and get paid for that. The company needs to grow and make profit. And when it doesn’t, you need to change and improve where you can. The company is not for providing jobs, it is to make money. If your company is doing the right thing then people delivering the right thing together can be happy in doing so.

So if you embrace Scrum you need to be willing to change everything. To radically reorganize everything. People who are willing to see this and want to move with this change, keep them and help them where you can. But as soon as you stumble upon conformism, act with your goals in mind. You want to make money and be a successful business. You want people to work together on things that matter so they can produce a good quality product so you can satisfy customers. You do this with people who are willing to do so. You don’t want to do this with people who are out there to save their own ass and their own job.

It may sound a bit harsh but keep in mind why you want change. Why you want departments and people to start working differently. What is the goal of what you do. Is it keeping people within your company happy by solving problems when they occur or is it to be successful and change so problems won’t occur? It’s not why you want to do Scrum. It is why you want to change. The you can look at what you want to change and the how can be with Scrum (thanks Simon). You need to see this first and make sure the people who are at the helm see and understand this and know that you need to change and make sacrifices in order to excel.

Permanent link to this article: http://agilethings.nl/make-sacrifices/

Nov 18

Predicting the future by force

Lately I see it a lot. Scrum teams who plan a session to look at the product backlog and the items in it. It is named a Product Backlog Refinement. It is always a great idea for a team to look ahead at what’s coming next and to be prepared. It the past it was knows as product backlog grooming, but for obvious reasons it was renamed. But often two things happen at a refinement.

The refinement is just to be prepared for the next sprint(s) and to get more insight for the PO so he or she can determine if the userstories are well defined and clear for the team. But do you need a refinement session? In a well organized and running team, every member should be up to date with the product backlog. There should be time to look at it during the sprint. And there should be a kind of ownership for every team member that ensures that everybody knows what is going on.

Often I see a refinement and the team is discussing on how they are going to build stuff. And I have even seen sessions where the team provides estimates. Sure it makes the planning session go a little bit smoother, but it is again a new meeting and it can be a tedious session.

Teams should communicate all the time about items in the current sprint and stay up to date with what is coming. Also the planning session is for new items based on insights provides by the review. The product owner can change the items in the product backlog bases upon information coming from the review. So a refinement session is a bit unnecessary. After all, thing may change so why look at things that are not sure.

Often a Refinement session is a great indicator that a team is doing Waterscrum. Dividing all the set work over various sprints and not take into account that things will change over time and keep the option to adapt to these changes.

Does that mean that it is not needed to look ahead together? No, it is mandatory that the team should know what coming up next. But it is not a planning session. It is not a how are we going to build it. And it is not to please the business. The idea that you can estimate all the future work is interesting but it is not Scrum. It is so management can keep deadlines and customers happy they way they did in the old days.

You can try to make it work, but if you really want to be agile and work with the flexibility that Scrum provides. And you work with delivering actual value. Solve problems as they popup. And build what is needed and not what is demanded. Then you don’t need it. But it demands from a team that they are all involved and look ahead together and own the product they build.

So refine, please do. But don’t make it about predicting the future. It is just to clarify things, nothing more. If a team needs this extra meeting, then there is something wrong with the communication, knowledge sharing and ownership. Refinement is to make user stories smaller by providing insight and knowledge, and nothing more.

Permanent link to this article: http://agilethings.nl/refining-future-force/

Aug 20

What drives a team and each individual member?

What drives a team and each individual member?Curiosity
To answer this question we must know how we can acquire this kind of information.

For that I have read ‘Management 3.0 workout edition’ of Jurgen Appelo, especially the part that describes Intrinsic Motivation (chapter ‘Champfrogs Checklist and Moving Motivators’). This book is currently online available for free.
Jurgen speaks about a lot of motivators in life and that there are ten motivators related to work. He explains what each motivator does and how it can affect you, your team or your organization.
These ten work related motivators are:

  • Acceptance
  • Curiosity
  • Freedom
  • Goal
  • Honor
  • Mastery
  • Order
  • Power
  • Relatedness
  • Status

 

How can you make use of this as a facilitator?
That’s where it becomes interesting!
Personally I wanted to use this into a retrospective to answer the following questions:

  • What moves each team member?
  • What is the main motivator of the entire team?
  • Which coaching opportunities do I have?

 

This is how I got my answers!Goal
I conducted a retrospective which consisted of the following structure:

  • Happiness metric (10 minutes)
  • Moving motivators (75 minutes)
  • Compliments (5 minutes)

 

 

 

What’s needed for this retrospective?
Preparation time: Several hours of reading Management 3.0 workout edition and printing and cutting the moving motivator cards.
Maximal amount of persons: 9
Time needed: 90 minutes
Materials:

  • A printer, thick paper and a pair of scissors to create the motivator cards.
  • Excel for generating the charts. I can send you the Excel I used by mail on request.
  • A room with tables so each person has enough room to lay down their cards.

Let’s skip the explanation of the start and the end of this retrospective and let’s get right to the ‘Moving motivators’.

 

Moving motivators!
Before you are able to start laying down the motivator cards, there must be some explaining and understanding amongst the participants. To achieve a common understanding I explained each of the ten motivators plenary. As soon as we reached a common understanding, we continued to the next step.
The next step consists of actually laying the cards in the ‘correct’ horizontal order. Because there is no right or wrong, your order is always the correct order for you. The most important motivator should be on the right and the least important motivator should be on the left. I explicitly explained this to the group, because we have a ‘leftie’ in our midst.
When everyone understood the assignment, I gave them a question that they needed to answer with the ordering of the cards, each member by themselves on a separate table. Because of the importance of this part there will be no time-box for it. In our case the question was: What do you find important in your job?
As a facilitator you need to sense if someone needs a little direction or not. Therefore, get off your ass and walk around, do a sneak peek at each table.

As soon as the group finishes ordering the cards, you will be able to continue to the next step.

Example of ordered motivators

Example of ordered motivators

 

Now it’s time to generate some insights!
Let’s ask each member a few questions about their cards.
To generate the important insights I have asked the following questions:

  • What motivates you the most and can you explain why?
  • What motivates you the least and can you explain why?

 

After each member answered these questions you may point out to the team what’s noticeable.
In our case most of the team members find the same motivator the most important and they are quite divided about their least important motivator.

 

Let’s start shifting!
Because we’re heading to the next part of our assignment it’s time to do some explanation to the team.
From now on it is forbidden to shuffle the cards. They must remain in place and may only shift vertical.
Let’s give the team members something to think about and let them shift each motivator one place up, one place down or remaining on the same place. For these team members I asked them to think about was the following question: How does your daily work reflect to the motivators? As a facilitator you need to walk around and take a look at the shifting and make sure that each member plays by the rules.

Example of shifted motivators

Example of shifted motivators

 

Once again we are going to generate some insights!
Even now we are going to ask each participant some questions:

  • What happened with the most important motivator? Did it shift? Which way? Why?
  • What is the most important motivator that shifted up and why?
  • What is the most important motivator that shifted down and why?

When everyone shared their thoughts it’s time to collect all the results.

 

After finishing the retrospective I went to my computer and entered all the results into Excel.
I have calculated an ‘Average’, a ‘Minimal’ and a ‘Maximal’ team radar.
To generate more information I have also created a bar chart for ‘Variation’/’Differentiation’ and ‘Max difference’.
It’s great to see that ‘Max difference’ gives you insight in how much the individual team members think alike on a motivator.
Does the team agree on what motivates them? With ‘Variation’ or ‘Differentiation’ it’s possible to find an answer to this. A small value on a motivator indicates the team is likeminded on this particular motivator!

 

Team radar ('Average', 'Minimal', 'Maximal')

Team radar (‘Average’, ‘Minimal’, ‘Maximal’)

On one of the walls in the team space we have added the printed results of the team.
These results consist of:

  • Team radar (‘Average’, ‘Minimal’, ‘Maximal’)
  • Bar chart (‘Variation’, ‘Max difference’)
  • An explanation form for each motivator
  • An overview of the average cards in horizontal order.
  • An overview of the vertically shifted result.
Bar chart ('Variation', 'Max difference')

Bar chart (‘Variation’, ‘Max difference’)

 

What’s next?
Print the results for each team member: both individual and team results.
Put the team results on the wall and discuss them with the team.
Discuss each personal chart individually.
Pay extra attention to the most important motivators that didn’t shift or shifted downwards.
These are the traps that can demotivate an employee or even the entire team or department. Be aware of that!
By coaching the team and each individual it might be possible to prevent demotivated employees.

 

My conclusion at this retrospective:
It was an eye-opener to see what can or must be done to maximize the full potential of an individual or the team. In our case most of the team has the same most important motivator, but they were not always challenged enough. This is a risk that needs a direct follow-up.
I already knew that I find it really interesting to discover what thrives someone and by doing this I realized the amount of coaching opportunities related to motivation there are.

Freedom

How did you use the moving motivators and what results or insights have you acquired?

Permanent link to this article: http://agilethings.nl/what-thrives-a-team-and-each-individual-member/

Aug 08

Please the customer, fix the scope.

The first couple times this happened I was not prepared. We thought we were doing the perfect agile project and worked together as a perfect team. The Product Owner was committed and really into agile. We all were aware that we were working with a variable scope. Everything seemed ok.

But then, at about three quarters of the project, things got a bit more tense. The question: “Is everything we need going to be in it?” was raised. And we all knew that the main stuff would be. That plus all the new stuff we created since we used our new insight and such. The PO told us that he understood. “It is a flexible scope”. We were young and naive and we assumed the if the PO understood everyone understood.

Old habits die hard

Build all the things What happens a lot in this situation is that when there’s some tension people tend to go back to the ways they know and feel certain with.

Managers from clients tend to think they will get more by overruling PO’s or put pressure on them. Demanding that everything that was in the original estimate should be build. In detail. And the “we are doing agile so we do not really know in detail yet” argument is not valid in this environment. It’s about old school management now.

Managers of the development teams tend to put pressure on Scrum Masters and the development teams to keep the customer happy. Tell them to write less testing, stop pairing, add extra developers and say stuff like: ”We have to cover some real ground now”. This is their attempt to please an angry customer without considering the fact that the customer could be unreasonable.

And in this attempt they sometimes make a decision that can destroy everything you and your team have build:

“ We are going to do the last sprint(s) fixed scope, time and budget.”


Bad

  • It’s bad
  • It’s bad for the team. It is a signal that they did something wrong and that management is always needed for solving problems.
  • It’s bad for all employees. It says that you can all do that agile thing but when the going gets tough real management is needed.
  • It’s bad for the functionality. With fixed scope and time there’s not much room for new insights. Just build everything.
  • It’s bad for quality. Since the scope is fixed, everything we do that take time costs us money. More functionality, less testing.
  • It’s bad for relations. There’s no collaboration anymore. There’s a client-supplier relationship.
  • It’s bad for the PO’s since they got overruled and their credibility is gone.

And then what?

Be prepared. Be prepared and try to avoid this stress moment. Mostly it happens when you are on 75% of the project. Help both your PO and your management. The chances are that they are not so into Agile as you are so they will need your expertise. Go outside your team and step in their world. Educate. Try to go to their meetings. Demo. Talk to the stakeholders. And if you feel there is some other expertise needed, ask the people who you think can help.

But most of all do not let this happen to you, your team, Product Owner and the product that you are making. Make a fuss if you need to. It is your project too. You do not want this!

Feel free to give us all some tips or stories in the comments!

Permanent link to this article: http://agilethings.nl/please-the-customer-fix-the-scope/

Jul 25

DevOps, building on quicksand?

The management decides they want DevOps and Continuous Delivery. It is faster, cheaper and there are less people needed for the same work. So now DevOps and CD are set as goal for the whole company to reach in the near future. So basically engineering practices are being set as strategy, top down.

DevOps is not something that stands on its own. To really benefit from the concept, the underlying dependencies need to be in order. It is not as simple as adding operation engineers in a Scrum team.

But the question remains: is DevOps without fully implementing the underlying aspects like building on quicksand?

DevOps Overview

Read the rest of this entry »

Permanent link to this article: http://agilethings.nl/devops-building-on-quicksand/

Jul 21

DevOps and Product Ownership

Change Tyre

[This article was co-written by Miel Donkers and Niels Talens.]

You could see DevOps as expanding the mindset, toolset and processes which started with Agile. Where Agile focuses on creating maximum business value as soon as possible, DevOps can help you to actually deliver this working software quickly. Finally a Minimal Viable Product makes real sense.

But just as we found out time after time with agile adoption projects, the gap between business and IT is often a bottleneck and not an easy one to resolve. With DevOps this often becomes an even bigger bottleneck since it adds the technical aspect of maintaining software in production.

DevOps is not just a matter of integrating Ops work into Scrum. In this blog-post we would like to focus on questions like; How are we going to …

  • help the business with this changed reality?
  • be able to cope with unplanned work (like incidents) while retaining a sustainable pace?
  • show the benefits of DevOps to the business on short term?
  • make sure features aren’t always prioritized above quality and security?
  • make sure that all important work is going to be planned on time?

Read the rest of this entry »

Permanent link to this article: http://agilethings.nl/devops-and-product-ownership/

Jun 17

Moving the mastodont

1206068419g4cHE2hMore and more I see companies who want to work with frameworks like Scrum but fail in getting it right. The more I look at why this happens the more obvious it becomes for me that the larger the company the more the challenge. And sometimes it is even impossible to get it to work.

In large companies the start of working with Scrum can be sparked in two ways. Either by development teams although this is very rare and I’ll explain later. Or by middle management and this is also the reason that it fails often. Now I’m not talking about a company with around an hundred or so employees, this is a challenged but easy to take. I’m talking about the 1000+ size organizations The bigger the more impossible.  You might gues that this is because the communication is harder and it takes longer to get everybody on the same page.  But it is not the communication that is the problem. It is the anonymity of the company.

If you look at scrum from the bottom up, to start with the teams so to say, it is very hard to get management involved. And when they do, they often lack the power to change upper management. Especially in large companies things go as they go and there is a lot of traditional way of working. Change is hard as many doors stay closed and business will stay as it is. Teams might get some improvement but never get Scrum to work to the full extend. Hey but what about DevOps. Well, DevOps is nice, but when you don’s have the cooperation of the entire company, this will also fail and especially DevOps. But let’s stick with Scrum for now.

What if the upper management wants to change then why should the people in the lower levels of the company? The problem is that the bigger the company, the more the anonymity of its workers. Why should you change when nobody will see it? I often encounter people who have worked almost their entire live at one company. They have seen many changes and scrum is just another thing endorsed by management.  To them it is nothing more then the movie of the week.

So basically the chance that you get stuck when wanting to implement Scrum in a larger company is very real. So should you not do it then? Please don’t let me keep you from trying. But you need a lot of energy and even more, a lot of people who are willing to change. And most important, you need sponsor. You need people who are willing to give time, influence and knowledge to help this change. The bigger question that large companies need to ask themselves, and not just the bigger companies, is why they would want this change. The “Why?” question is the one often not answered. Simon Sinek addressed this topic a time ago and more and more I see this question popup its curious head. Why the hell do you want things? Why would you start with scrum in your large 1000+ companies and if you do why is it not working?

So apart from wanting to turn the company on a 180 degree rampage towards something else. Ask yourself why you would want to do that. And once you know why, you can start with what you need the change and how. So there is a little spark here. You can redesign a big company, but you really need to shout the why question.

 

Permanent link to this article: http://agilethings.nl/moving-the-mastodont/

Jun 03

You need to have a SIT

7695928_origSo how do you get things to move within a larger organization? As I mentioned before just hiring an Agile Coach doesn’t do the trick. He or she can only bring change on those parts where people are willing to change. But it is just like a Chinese plate spinner. Once you have the first team spinning. The others will loose momentum and might fall. So you need more hands. You have your different Scrum Masters. True, but what if they need coaching as well or are not yet experienced enough to provoke change. What you need it a Scrum Implementation Team. A group of people with enough knowledge to teach others how to work and act with Scrum but also people who have time to do so. And by time I mean, mandated enough to do invest time and effort where needed. Not just one hour per week. This team also should be able to move freely through the company. And last of all but most importantly. They must have authority. It’s almost like the CRACK rules for a Scrum Product Owner.

This team should also be able to provide change by using Scrum. Build a product backlog with all the goals for that period and conduct daily standups, reviews and even retrospectives. So implementing Scrum with Scrum.  So what does the coach do then? Is he or she suddenly redundant? Absolutely not, but the coach can start with the change on a corporate level. And start helping the Implementation team as they need all the help they can get.

Now this is nothing new. You can read about this in the book that Jeff Sutherland and Ken Swaber wrote “Software in 30 day’s”. Yes I know, it is nothing more then a big sales brochure but it has got some good point. But also look at Spotify where they use coach teams who teach and help the different subgroups. It works. Change is not something you can do alone as a coach or as a single individual within a company. You need people; lots of people who are willing to adapt but also teach, promote and change. So as soon as you can. Start with a Scrum Implementation Team (SIT), or whatever you would like to name it. And keep all those Chinese plates spinning. It’s the only fast way to get things done.

Permanent link to this article: http://agilethings.nl/you-need-to-have-a-sit/

May 12

Be the change

Image source: http://pragprog.com/magazines/2009-11/the-agile-coach

People hire me as a Scrum coach to help them to make changes. Often these people work at companies that want to work with an Agile Framework, often Scrum. In many cases when I have the first talks about the how’s and why’s. I get most of the information I need as a coach to get starting. Sometime I’m asked how I’m going to do my work or if I have a plan. My honest answer is that I don’t. Off course I have ideas about how I’m going to do my coaching but I’ve learned that just starting with inspection and a lot of talks helps me to get my hands on everything.

The biggest challenge I face often is not that of helping a team with Scrum. I coach the Scrummaster and Product owners so they can lead and facilitate the teams. But in almost every case I smash into the company walls. Upper management, CEO’s, CTO’s and so one, sometimes want Scrum to work but don’t invest the time needed to get knowledge for themselves. They just rely on me as a coach to do the job for them. I think this is very dangerous, I might have a lot of knowledge and experience to apply changes but I’m just like everybody else, just human. I can make mistakes and my power (if there is any is limited. But even more important, how can you expect that your company will change if you as an initiator. don’t know what is happening or why. Yes I can teach and consult but the responsibility for change is not mine. It is of those who want that change.

At every intake that I conduct with companies, my first question is why they want to work with Scrum. Often I get a logical response but my response is always the question if everyone is committed and willing to change. But telling that someone is commiting is one thing, actually committing is something else. So I was thinking that maybe it would be a very good idea to make this commitment transparent. Maybe a sort of Scrum Coach Commitment document with statements like this one;

My name is …….., and I hereby commit myself to the learning’s, coaching, consultancy and examples of the appointed Scrum coach and will do everything in my power to turn this change into a success. I know it will be hard and difficult. I acknowledge that the way we are used to work will change and I shall accept this and make this change my own.

I would so much love to set this in writing on the wall and ask everyone who is going to work with the Scrum framework to sign it. I know there is the Agile Manifesto and you might say that this should be enough. But even though the manifesto is a very good idea, it does not say anything about really committing to change.

I would like it if a company not just hired a Scrum Coach as a sort of excuse or silverbullet, but that they openly commit themselves to the change. And then ask a coach to guide them. The best guide is knowledge and this is something that you can get for yourself. So read, learn, get involved, work together and most important be the change. Otherwise it will not work.

Permanent link to this article: http://agilethings.nl/be_the_change/

Apr 25

Have fun with Lego

Lego RetrospectiveIt’s not the first time I write about this. Maybe I’m very enthusiastic about this. Maybe I just want to tell you about this because it is plain and simple fun but very effective. Doing your meeting with Lego.

As a coach I help people to see things how they are, either good or bad. Applying transparency is important in every environment, not only if you are Agile or doing Scrum or Kanban. So once in a while it is good to look back at situations to see where you can improve. In Scrum it is a good idea to do this after every sprint. It’s one of the moments where you get to change and improve the way of working. But even if you don’t do scrum it is smart to look at what you are doing. One way to do this is with Lego Serious Play.  You can start with buying a big box of Lego and just do it. But a little knowledge of how Lego Serious Play works and how those little bricks can jumpstart the brain is, I think, important.

I’m not going to tell you how this exactly works. It might take a few pages. Although LSP seems simple, the logic behind it and the working of this method takes a bit more explaining.  But once you are able to understand how it works (ask you local coach or LSP facilitator) you can do very powerful sessions with your team or department.

This is not a blog to sell myself. Don’t get me wrong, I’m always keen to do this and earn a little money. But I write this to show you that you can do more with your Retrospective then just sit around the table and talk. Even when you use stickies, retro-games or whatever, once in a while you need new and fresh ideas to get people to attend with new energy. You might want to consider Lego. The glistering in the eyes of ever the participants is so much fun because no matter what age you are. And no matter what you position is within your company. Everybody just loves to play with Lego. Imagine that you have that positive feeling and then do a meeting. Trust me, it will be both fun and work. It will be serious play.

Permanent link to this article: http://agilethings.nl/have-fun-with-lego/

Older posts «