Aug 24

After continuous integration there is continuous validation

It’s a funny thing to say that delivering business value is the most important thing when developing software. It doesn’t matter that a framework like Scrum is far from efficient, because we focus on value. We deliver business value. Working software. Every sprint. Period.

But in the end we often just don’t know the impact of the things we make. What do we really know about the business value we supposedly created? Is it a one-time validation? Is it a one-way validation?

We keep adding stuff to our products because that is what we are expected to do. We always need more features. But do we know the difference these features make, except that there are more features now? More stuff. What if one feature undoes the effect of another? Wouldn’t that be valuable to know? Wouldn’t it be nice to remove it?

Software development has everything to do with validations. There are at least three rounds of validation from ideas to maintaining the software in a production environment.

Validate your ideas and business goals

Cycle 1

The first round of validation is about vision, business goals and problems to solve. Is the vision of the product (still) right? Are the right personas defined? Is the desired impact of the software defined? Are the right activities defined? Are the goals clear? What is the desired ROI?

Continuous Integration

Cycle 2

The second round of validation is about technical and behavioural validation. Features are being designed, built, tested, accepted and deployed.

Live validation

Cycle 3

Hooray! Your software is live! Well, let’s NOT sit back and relax. This is usually the moment where we tend to run back to the product backlog and get started on new features. Burn down those points! Move post-its around like there is no tomorrow! Like dropping your children off at school without ever speaking to the teachers.

Let’s make sure that this is what the world really needs. Let’s also make sure we keep it that way.

Proactive monitoring

Monitoring is often limited to raising the alarms when something is seriously wrong. With continuous validation you are monitoring something else entirely: you want to know the effects new features or changes have on the system and be able to act on them. Use the feedback you get from your users, that is, from the behaviour of your users. For instance:

  • What is the performance of the most important business transactions? Do the new features affect these? If so, how do they over a period of time?
  • What do heatmaps say about the assumptions you made earlier? Or the usage data? Do the users really use the new feature more than the older one? And what about over a period of time?
  • What do the statistics say about the increase or decrease of a certain feature? Was that the intention?

Validate goals

You make your software with a purpose, right? You want to reach business goals or you want to solve problems. But to make sure your software achieves what you intended it to do and keeps doing you need to validate this continuously. If your goal was to sell more items and you implemented functionality to reach this goal, you’ll need to validate its effectiveness. And then you need to keep validating it because software is no concrete structure and will change.


I cannot emphasise this enough: remove functionality that doesn’t meet the criteria anymore. The world is full of bloated expanding products which become even bigger and unusable. Like the gate in the picture. I’m sure there was a good reason to make it and it worked very well when there was a fence. For now it only costs us because it needs maintenance.

Does your product have gates without fences? Are you aware? Not all as visible as the one in the picture I’m sure, but they’ll cost you money just the same.

Permanente koppeling naar dit artikel:

Aug 24

More with LeSS

MatroesjkaFor a while now I’m coaching and training Scrum. And for a while I had the feeling that, even though Scrum works, it is very hard to get it to work in a larger environment. so I needed something extra. So I read books about scaling Scrum and I read blogs and talked to other coaches. But somehow I felt that I missed something. I know that in order to get Scrum to work it is important that the entire company is willing to change. But that is easier said then done. I provided training and talked with management. I also provided workshops and sessions. And everything was great and fun but still something was missing so I started focussing on the Scaling models. SAFe (Scaled Agile Framework) was the first one, and even though it seems to work as a larger framework, it didn’t feel right to me. I’m not saying that SAFe is wrong but it just was not my thing. So I looked further. LeSS (Large Scale Scrum) was the next option. I read about it and I liked it. So I went on a course. Four days buffering over powerpoint slides. Games, debates and theory. It was inspiring and fun. The fun thing was that LeSS is just Scrum, only bigger. And that is what I liked about it. The Scrum part was very familiar, but the strategy to get a company to change was something I loved. Not just a big bang and go on with it. The “Here is your training and now you can do it” mindset. The approach with LeSS has much more to do with slowly preparing the entire company for the change. And only doing that change when everyone and everything is ready.

One thing you have to be prepared for is that the change towards a larger Scrum environment takes time. I often have talks with managers who want Scrum in their company and want to hire me as a coach. When I predict the future and tell them that it will take two to three years before everyone knows a little how to work with Scrum, they turn pale. One or two months is what they hoped for and two to three years is not what they anticipated. But when you come to think of it, it makes sense. Most companies have taken years to get to where they are. Through growth and using various models they are what they have become. And all of a sudden they want to change because the market demands it. You can’t just divert overnight. It takes time. And you will have to take small steps. I know now that LeSS provides in those steps and it can help make the transition transparent for everyone.

LeSS is not easy and I don’t think that every company can just adopt it. Same goes for SAFe or any other scaling model or even Scrum for that matter. Change is difficult and for some people nearly impossible. And in order to do so you have to prepare everyone for the change. Make everybody a part of the the new way of working before you start working like that. LeSS provides in this. It provides a gentle slope of change. But once you have started to climb that hill together, the higher you get, the easier it gets but turning back becomes harder. I know, this sounds fluffy but take it from me, don’t just read a book about scaling but follow a good training. Also hire a coach to help you with the change. Sorry, i’m advertising myself and maybe other coaches. But if you want Scrum to work on a larger scale, you need every help you can get. It is no longer a development team with a scrumboard and a daily standup. We are talking about organizational change, and this is something not to be taking lightly. So, more with LeSS, I’m sure it will but you have to invest for the long run.

Permanente koppeling naar dit artikel:

Aug 03

Don’t hire a ScrumMaster

smroleThe ScrumMaster is a role and not a job title, so companies posting a vacancy for ScrumMaster are on the wrong track. Earlier we talked about the idea to first answer the “why” question and then start by looking for the right people to help you with the Agile transformation. Lately we see that roles are becoming much more important. Companies need to change to keep up with the dynamically evolving market. But also need to change to adapt to the way people work together. For long we are saying the specialisme is no longer needed. People need to work more together and divide the various roles amongst each other in order to get the work done. Holacracy is more and more the new way of thinking within the business.

So why not hire a ScrumMaster? As the ScrumMaster is a role within the team, the parts of this role can be divided amongst the various team members of a Scrum team. Keep in mind that one of the goals within Scrum is to evolve a team towards self management. So in other words, the ScrumMaster becomes obsolete when a Team is evolving. In some situations the Scrum master role can grow. So someone filling the role might start helping more than one team and slowly evolve towards a team coach and eventually a company coach. When this happens, you know that the agility growth within the company is happening. The Agile maturity is a different matter and we’ll talk about this some other time.

Also when looking at a ScrumMaster vacancy in most cases the role and responsibilities within the role are poorly described. When you analyse that there are more coaching aspects described, the company does not understand what a ScrumMaster should do. A ScrumMaster role is completely different from an Agile Coach role. An Agile Coach is someone who will advise the teams and organization in how to become more Agile. He or she will be advising them how to play the game. An Agile coach also has the goal to go as wide as possible through the company. He or she is asked to help changing. From teams to management and not so much just doing Scrum but also help with the change to become more Agile across the entire business spectrum. An Agile coach is more a change manager and in large companies this is also a fulltime job. A ScrumMaster facilitates Scrum teams to become more efficient in playing the game. A real facilitator.

When there is a poor description of roles in a vacancy, you are probably dealing with a Non Agile organized company. In most cases those companies ask for a ScrumMaster but actually there is need for an Agile Coach implementing Agile or transform a company to become more Agile. When contacting those companies, in most cases, if you’re lucky they have read some books about Agile Scrum. Majority in Agile is low.

When dealing with brokers in between or recruiters, in most cases they do not ask questions to the companies who have published the vacancy. When asking questions about the role in most cases you get no answer either.

So for you companies who feel they need to hire a Scrum master, first look at the real question. Is Agile Scrum sufficiently incorporated into my company. Do I need more knowledge? And if so. Wouldn’t it be better to hire an expert to get things going. To train the Scrum master role with the people already working. Keep in mind that hiring someone from the outside to fulfill the role of a ScrumMaster might also have a negative effect on the people already working in starting Scrum teams. “Am I not good enough?” or “Why do we need someone from the outside when we are supposed to overcome difficulties within the team?”.

For Agile coaches it is one of the first important signals that there is need for more than just a simple filling in the vacancy. It is a clear signal that they are probably dealing with a company who needs help. For the human resource department it is a first signal that others are struggling to work towards change. Help is needed. For teams and management a clear signal that knowledge and support is needed, but not so much by just hiring a Scrum master. And well for you brokers and recruiters, start by doing your homework.

Co:writer Erwin Verweij

Permanente koppeling naar dit artikel:

Jul 14

How assumptions are not the mother of all f-ups

The thing about trends is that they will come and they will go. So after the agile trend continuous delivery and devops are in line. I think in a way it is very nice to see that development craftsmanship practices are becoming more and more accepted. We can all benefit from this. Software is eating the world so let’s be damn sure that the software is good. But is it?

Be honest. After the development of the first couple of versions. After adding new features for a while. What is the state of the product? Are the same assumptions holding up? Are your goals still the same? Did the world change? Or is the fact that you can deliver your software in a matter of seconds enough?

Often we think we are building software like this:
What we think we make

But we are doing this:
What we really make

Let’s say we are still building the same crap but at least now we can deliver it faster and with fancier new tools.

Agile, continuous delivery and devops can make our processes and delivery easier. And we can do that in the cloud, with big data and microservices written in Elixir. But that is still only a part of creating software products. We have to look at software development as a whole again. Because that’s the only thing that really counts: making good products. And that does not only mean bug free or easy to deliver.

Why continuous delivery isn’t finished

The prerequisites didn’t change at all. With bad input and lack of validation the results are mediocre at best. It made my colleague Hylke Stapersma (@hylke1982) and me think about why continuous delivery isn’t finished and what we are missing. So we started experimenting with this. In the following blogs we will describe more of the technical journey. for now it’s about the concept.

Step 1: Stories that don’t suck:

Good story describes the goal a certain user wants to achieve with a piece of functionality (the why). It should be pretty functional. It works very well to add acceptance criteria (BDD/ATDD scenarios) in an early stage to fine tune and make sure a functional validation is in place. Let’s say that’s all in order.

We now want to introduce another dimension to make sure we achieve our goals. We add something we called an experiment, which includes some assumptions, to an user story. These assumptions can be measured and will automatically be validated.

**And for me it is not about being SMART all the time. I’m definitely more of a DUMB guy. It is more about validating assumptions than the measurement in this case anyway.

Here is an example of a story we are using in our demo setup which contains both the BDD feature and an experiment:

CD is the start1

Step 2 – 8: Do the magic: build and deliver the best software ever seen.

CD is the start

For a more indepth explanation of this model please check this blog.

Step 9: monitor assumptions.

If the results of the validation are under expectation, these result should have impact on the backlog. In theory the result of the validation is more valuable than any new feature you were dying for to implement. To be honest, the story in which the assumption was made was highly prioritized.

So one of the first thing we saw is that in contrast to unit or acceptance tests we now have the time dimension. Our behaviour tests run a couple of time in the continuous delivery pipeline but never when the software is in production. There’s no need either because there are no changes there. In the case of the experiment we have a starting point, our baseline, and from there we will schedule a periodic validation of the assumptions we made. We can validate as often as we want. Why ever turn them off?

Removing features is not a bad thing people.
If you find out that something is rarely used please do not be afraid to remove it. That will make your product leaner and your codebase cleaner (there is a song in there). Also here the validation of assumptions can be very handy. Because we can measure over periods of time we just set a limit and everything below that we have to evaluate. If something isn’t as valuable as expected then I would like to know that. Often by adding a new feature an older one becomes unnecessary. No problem. Just remove it and try again.

Impact mapping.
If you take a look at impact mapping you see that assumptions are a big part of it. Those are the things we often can make measurable. In our case add them to an experiment and validate. Impact mapping is a great way for us to gain insight in the many assumptions we make. If you don’t know impact mapping I can recommend the book by Gojko Adzic.

Non functional stories.
A story has to describe something that has value. But sometimes that value is easier to define than the functionality or the user. And what to do with some non-functional stories? I think we all have had experience with user stories that feel artificial. Like we can’t even describe a proper user for it. We just want to decrease the costs of operations with a piece of functionality for instance. Should we describe “ the members of the board” as users? It just feels artificial sometimes. I think in those cases an experiment/assumption could replace the story.

In the future we want to be able to also use information of tools like AppDynamics or Google Analytics. Those have so much information that will help the business in making good products. Performance and usage are definitely things that are key in that process.

So, in conclusion, in contrary of an earlier blogpost of mine, in this case assumptions are not the mother of all f-ups. Assumptions are a step in completing the whole flow of software development.

We are currently implementing this idea and will share our findings and solutions in one or more following up blogs. Stay tuned!

Permanente koppeling naar dit artikel:

Jul 04

Don’t start with the vacancy, start with the question

Scaling at the beach

“Hi we want to hire a Agile coach with LeSS or SAFe Certification. He or she will provide our teams with some training.” Well I hate to bring this to you, but this does not work. The first big question you have to ask yourself as a company is “why”. Why do you want to scale. Is it so that work will go faster and teams will work better or the competition is also doing it. Then don’t do it. Is it that you want your time to market to go up and actually start to deliver valued work more easily with everyone involved, than it might be a good idea. But even then don’t focus on the framework but start with the question. The first thing that companies should do is ask a good Agile coach who does understand large scale agile and ask to help with the big question. Sit down with management and identify the challenges, current affairs and mindset. Visualize the challenges and pressure points. Where are possible areas that could benefit from change. And then focus on what would work best. Only then you can start thinking about SAFe or LeSS or any other model.

I wrote an article before about scaling where I said that I’m not a huge fan of scaling scrum models. Not so much that it is not a good idea to scale. I think it is great when a large company want’s to change and involve everyone and everything in the change. But lately I see a lot of Scrum vacancies for Scrum Master or Agile coach who also has to have SAFe (Scaled Agile Framework) or LeSS (Large Scale Scrum) certification. I’m not a big fan of SAFe, I think it is too complex and way less Agile than LeSS. But I do believe that at some level it might work if you do it right. I recently became a Certified LeSS practitioner so I know a little bit more now about scaling. And yes, also LeSS only works if you do it right. The reason I don’t like scaling models is that companies who don’t understand anything about it and want to implement some sort of large Agile framework, think and even believe that by just hiring people to train people within the company, the question is answered.

So again, start with the Why and then the What and How. The Why is the reason you want to change, the What is, well what needs to change and the How is they way you probably could do it. I say Probably because there are no certainties. A certified coach is not a guarantee that it will work. A coach is just someone who can ask the right question and trigger response. The change will have to come from every layer within the companie. And it starts at the top. It starts at the top with change and If you don’t want to go all the way then don’t. Stop hiring SAFe, LeSS and Spotify experts and keep doing what you’re doing because when it does not start from within at high level, and you don’t know why you want it. It is not going to happen. Ever.



More about LeSS (Large Scale Scrum)*
More about SAFe (Scaled Agile Framework)*

 * the “e” is just added for the fun of it

Permanente koppeling naar dit artikel:

Feb 05

Scaling Agile, steep mountains have slippery slopes

7699228408_e7805285c5_kA lot of IT companies are trying to work with Agile. And most of them are having some sort of success. But the bigger the company the more difficult it gets. Getting Scrum to work with development teams works in most cases but surrounding management and connecting departments have a hard time to adapt.

To accommodate this we see a new trend. Scaling. Scaling Agile to help larger companies to make the change and gain the benefits of agile frameworks like Scrum or Kanban. But this comes with a price and to my believe might in most cases not even work. When a company starts to work with Agile, often Scrum, a change is set in motion. Communication and interaction start to work differently and the focus moves from budget driven to value driven. As I said, most often the development teams can work with Scrum but the interaction between these teams and the rest of the company becomes blurry. So systems like SAFe, LeSS, Scaling Agile, Blowing up Scrum or whatever the name, are brought in. Sometime because someone read an article or a coach is challenged to come up with something that fills in the blanks. I have heard from companies who start directly with these larger systems without even trying to get the basics like Scrum to work.

Why doesn’t it work? Keep in mind that the idea of scaling comes from the fact that there is a feeling that Scrum does not accommodate the larger picture.  Scrum doesn’t say anything about architecture or design. It doesn’t say anything about DevOps. So smart people start to invent large scale scrum solution that accommodate the bigger picture, but in doing so they forget two very important things. The first one is that the Agile mindset is about people and bringing value. Frameworks like Scrum are designed to help people to communicate and work on value. And they are horizontally throughout the company. They feed on what customers want. Traditional process management on the other hand is budget driven and feeds management and sometimes shareholders. You can read about this in an article from Forbes. Large scale Agile systems are to keep this vertical system in place and in most cases go against everything that Agile stands for. The idea of using Scrum is so everything becomes visible. The good things but also the bad and painful stuff. Agile as an mindset can then help to make the change.

The second thing is that often examples from other companies are used for these Scale Scrum Systems. Spotify is a good example. At Spotify they started small and with Scrum. When they became larger, they adapted Scrum so it worked in their larger system. They started to use Tribes and Chapters. And it is very cool, but keep in mind that this is something that Spotify worked out by themselves. They knew the potential of Agile and got it to work and designed their own Spotify system. This does not guarantee that this will work for other companies. What is good for one might hurt another. So when a company works with Scrum and finds that is does not completely work throughout the entire system. A click and play scaling Scrum system will not work. Each company will have to start working on their own Scaling. Every company has it’s own unique DNA and even though they all might develop software, the people doing this have a unique mind. You cannot upload a system into that mind and hope everything will scale. You have to build it from the inside out and using the companies own building blocks.

We often say that frameworks like Scrum are easy to understand but are very hard to get to work. There is no plug and play solution. We often try to adapt systems or frameworks to the needs of the company. Most companies have grown so large that it is nearly impossible to control. So we try to fit something over the mountain. But when are companies going to learn that maybe they have grown too big and made thing to complex. Maybe it is not about Scaling up. Maybe it is better to start sizing down. To go back to the basics and look at what is really needed and what will bring value.  I know of companies who work with around 250 developers and 5000 surrounding managers and supporting functions. What went wrong there? Together they try to control a large software landscape where most of the functionality isn’t even used anymore. But nobody dares to touch it, change it or throw it away.

So the question is not if you need to scale? The question is if you can reduce. And if this is somehow not an option, don’t just pick a ready to install Agile Scaling system, because they don’t work like that, but start to change from within the DNA of the company. Use Scrum as the tool to make the path visible and apply Agile as you navigation. That’s the way to scale the mountain. And I can provide a lot of metaphors hear about slippery and danger. But I think you can figure it out by yourself. So don’t just use an “instant” scaling system but device your own.

Permanente koppeling naar dit artikel:

Jan 12

Bring home the bacon not the receipt

BaconWhen did we start to lose track of what we really needed and began focussing on how much something costs? As a Scrum Coach I see it more than often that customers ask how much time something takes. How much effort and money is needed. The planning of a project is build upon the time people are consumed by it and decisions are taken on these plannings. Often I hear that developers need to do something within a certain time. It no longer is important what they do but it seems it is more important on how long it takes.

Somehow it seems that businesses have lost track of what it is all about, namely the delivery of something that is needed. Something of value. A product or service that can help the customer to do business with. The fact that at the end of the year in almost every company, people start to worry about the budget. Either they have to spend the last dimes in order to preserve the same budget for next year. Or there is not enough and more is needed. It is never about what is really needed. I have always disliked the thinking in budgets and end of year nonsense. Somehow customers and companies have lost track of what they are doing. Al the energie seems to go in the effort and not in the result.

In the time before software it seems it was all a bit easier. You needed something. You got it. And you paid for it. You left the store with something that brought you value or satisfaction. Over time products have become more complex and we no longer know what it is that we need. Sofware is no longer something that you can save on a disc, it is intricate and has connection with other networks and services. The scope is lost and the only thing that people seem to hold on to is how much lose is made on something. It seems easier to control how much is spent than how much is gained. This is strange. When you walk into a store, you will look at what you want to have and you make sure that you take it home. I never walk into a store to get something but the only thing I take from the store is the receipt. What I got is not important. Can you imagine going to the grocery and buy stuff you need. But when you get home you tell everybody how much you spend and that you stayed within budget. The groceries you left at the store, but hey you stayed within budget. Seems strange but we do it all the time.

Big companies only seem to focus on controlling budgets and not on what is gained in value. They have lost track of what it is all about and forgot the groceries. No wonder that employees of large companies have no idea what everybody is doing. As long a they work hard, show some results and don’t take to long in doing so. So think of this. What is more important to you as a customer. Getting something of value, something you really want. Or spent money and stay within budget. Do you want the groceries or the receipt? If you want the groceries start by focussing on the value output and not on the cost. Stop wondering how much time something will cost, but focus on what is delivered and why. The why is important, because if you get something that you don’t know why you want it, then why spend money on it.

In order to move towards a more logical delivery of goods, companies need to change their way of thinking. Stop looking at the cost and start looking at the value. Stop thinking in budgets and start with value streams. And most important, start with looking at you groceries and bring home the bacon.

Permanente koppeling naar dit artikel:

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.

Permanente koppeling naar dit artikel:

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.

Permanente koppeling naar dit artikel:

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

  • A printer, thick paper and a pair of scissors to create the motivator cards.
  • An application for generating the charts. I’ve used Excel to plot the charts. A request for this template can be send to my LinkedIn.
  • 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’)
  • Explanation form for each motivator
  • Overview of the average cards in horizontal order.
  • 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.


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

Permanente koppeling naar dit artikel:

Oudere berichten «

» Nieuwere berichten