intrinsic motivation Thomas de Graaf

Intrinsically motivating environments

Some time ago I said to someone that I want to create an environment in which people become intrinsically motivated. He replied to me “But intrinsically motivated people are already motivated themselves!”.

In the world of IT, with more ideas than successful implementations, we continue to seek for new buzzwords to help us out. Everything-as-a-service, full-stack t-shaped unicorns, high performing teams and intrinsically motivated people, who would dare to say ‘no’ to these? Although there is a truth in these buzzwords, misunderstanding them can have devastating results. Those buzzwords might distract us from what really makes the biggest impact on the productivity of teams, defining the environment in which people work.

We like to put people into ‘boxes’ to understand them better and within IT that would preferably be binary. Within complex environments such as human behaviour, that is however not applicable. Let me prove this to you. For those who see themselves as intrinsically motivated, who needs his salary to pay the monthly bills or maintain his/hers standard of living? Who is saving up for a nice new car, bathroom, kitchen or house? Or are you looking forward to buy that new gadget or piece of clothing from the next salary? For those who see themselves as extrinsically motivated, did you ever leave the office with the feeling that you accomplished something great that day even though your payment didn’t change because of it? Did you ever feel challenged on your work, because someone gave you a challenge and you resolved it? Did you ever feel appreciated at work because someone said thank you when you helped them out?

Hopefully I just proved there is a lot of grey area here and people are generally both intrinsically and extrinsically motivated. But that is not where it stops, it gets even better! Motivation is not static, we can influence it! Imagine you are a predominantly intrinsically motivated cartoon artist. You make awesome cartoons, appreciated by millions of viewers worldwide. One day a new chief editor is assigned who reviews your creations and every single time he says they are not good enough. Without elaborating why, he puts all of your work in the paper shredder right in front of you. Would you remain intrinsically motivated? What if he also decides to cut your salary or stop paying at all? And what if this cartoon artist would be a software developer instead, would this still apply?

Now the other way around, can we make a predominantly extrinsically motivated individual more intrinsically motivated? As a manager, try telling your team that you didn’t just hire them for their capabilities, but also want them to develop themselves in areas they are interested in, so they remain motivated and committed for a longer period of time. Give them the opportunity to explore new challenges, accept failure and let them learn by trying. Ask them if they are happy with their work and seek new opportunities together if the current work is not giving any satisfaction. In fact, anyone can help creating an intrinsically motivating environment. Try giving a colleague a compliment, let someone pick up a story for whom it is a challenge rather than a walk in the park. Give your colleague a compliment or thank them if they did something for you, it’s also the little things. Don’t forget to have some fun too, it might make you more intrinsically motivated as well.

Therefore, let’s stop talking about intrinsic motivated people and start talking about intrinsically motivating environments. Examples anyone?

A product backlog should contain just about 50 items

An thought-provoking idea has rested in my mind for some time and I’m writing it down right now to get some feedback. Maybe I’m completely wrong, but that ‘ll be clear from the reactions.

I often see very large product backlogs with hundreds of items in them. The sheer size makes it very hard to keep the overview. The symptoms are then solved with ever-expanding structures with epics, features, themes etc. But the root-cause is the size, and I contend that it’s not wise to make the backlog so large.

And I think it is really not necessary to have a large backlog. It’s rather a remainder of a waterfall mentality.

A product backlog with 50 items is enough! And this is why:

The top of the backlog, the work for the coming 2-3 sprints, should contain small and clear items. In my experience most teams deliver 6-10 items per sprint, so that yields some 25 items at the top.

Below that, the items should not be that small. There should be larger items that can be sliced into small pieces later.

Slicing already now is not wise. It could be that we will not deliver this item. New, and more important items can emerge, the PO may down-prioritise these items. Maybe the client asks us to take new directions, or the team invents smarter technical solutions. Slicing the items too early is a form of waste. Having too many small items in the backlog can make us less agile. We don’t want to change direction because we have put so much time in the existing items already.

So, after the top 25 small items, there should be larger items in the backlog. If the top-items are all 1-8 story points in size, the items lower in the backlog should be 13-40 points in size, and lower still the items should be even bigger. So having only 50 items in the product backlog is enough to keep the team busy for a year or so.

Well, this is my theory. Any thoughts?

Backlog refinement – theory and tips

The activity in Scrum that causes most confusion is the backlog refinement. The scrum guide does not treat refinement as an event, like sprint planning or the retrospective. So it does not have a clear timeslot in the sprint. The scrum guide treats it as an activity that needs to take place, but leaves it up to you how to perform this.

The literal text about backlog refinement in scrum is:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

So, the goal of backlog refinement is that product owner and team work together towards a good product backlog.

In the picture below I give a sketch showing the timeline of a new idea to working software, which may help to clarify the refinement process.

Backlog refinement Andre Heijstek Agileminds Valueminds

A new idea starts with a stakeholder. This can be a customer with an idea or complaint, or someone from “the business” with a smart idea, or a developer with a technical suggestion. These ideas should be given to the product owner.

The meeting where this idea is discussed with the PO is the very first backlog refinement. Maybe it is just two persons talking with each other, but the idea gets refined a bit already. If the PO likes the idea, it is placed on the product backlog. You could call this part of the process the “business refinement”.

Next, the idea should be discussed with the development team. They should get a clear picture about the item that needs to be developed. They should also estimate how much work it is, so the PO can take an informed decision about whether or not to develop this. Do the expected benefits outweigh the expected costs?

You could do this refinement session with the whole development team, but you can also start with subset of the team. In this way you can develop this idea into something better without spending the time of a lot of people. You can also invite stakeholders to this meeting if that will lead to a better clarification. You could call this meeting a pre-refinement, or prefinement, if you want.

If the idea is clear enough, you can have a refinement session with the whole team, so everybody will share the same picture. This is the “real refinement” session, where you will also do the estimation. If necessary, multiple refinement sessions can to be conducted until the idea is really clear.

After refinement, items can be picked up by a team in a sprint planning session. If the refinement has been done properly, the first part of sprint planning is easy. Just pick up the right amount of backlog items where the sum of the estimates matches your planned velocity. After this, sprint planning II remains, where you do detailed design on the selected items and add technical tasks.

It could happen that there still is a need for additional clarification during sprint execution. If this is just about minor details, that is perfectly OK. You could call this the after-refinement.

Hopefully this clarifies the refinement activity a bit. Any questions or comments? Please let me know.