Make it smaller

To learn faster, to deliver more value and to have a better general performance we need to make stuff smaller. Little stuff is easier to oversee than big stuff. Small problems are easier to fix than big problems. What can we make small in our work to make our work easier?

Shorter sprints

The shorter our sprints are, the more moments of inspection are available to us to learn and improve. A sprint is between two to four weeks according to the Scrum Guide. We don't need to adhere the framework here, if we can improve faster by shortening our sprint, we respect the framework as well. There are teams that run weekly sprints, and some even run shorter ones. A shorter sprint will provide more inspection moments and thus result in faster learning through more inspection and adaption moments. Because all events (except the standup) are relatively sized to the sprint, it will not consume more time.

Smaller PBIs

The smaller our product backlog items are, the faster they can be build and delivered to the customer. We get more revenue and more feedback. PBIs or stories are sometimes really big, they tend to have epic proportions. An epic PBI is one that can not be overseen or fixed in a certain amount of time. For most teams any story that takes more than three days to fix, the story should be considered an epic. So cut up the story into smaller chunks, make them independent of each other and smaller than three days. This might be hard at first, but practice makes perfect; think about the smallest possible change that might work. 

Less hierarchy

Hierarchy makes stuff complex. Hierarchy results in interdependence of PBIs, while we would like to have PBIs that we can resolve without any relation to another change (check the INVEST acronym). So an epic PBI, which is a PBI of epic proportion (and nothing more), should be made smaller. This will result in a couple of independent stories and the original epic story should end up in the trash. There is no added value in the original epic and it will only clutter the backlog with relations between stories that are useless to the outcome, because it's redundant.

There is another form of hierarchy, which we experience daily, that can decrease our performance as well. This is organisational hierarchy. The more autonomous a team is, the faster it can make decisions and learn from its mistakes. In a hierarchy people that don't do the work are made responsible for that work. Weird isn't it? Responsibility and autonomy go hand in hand. Make teams more responsible for their work in giving them the authority to make decisions about their work. Scrum solves this problem with two accountabilities: the Product Owner is made accountable for the work, the Scrum Master for the performance. 

Shorter meetings

I hear a lot of people complain about too much meetings, and too long meetings. I help them reorganise their agenda by skipping meetings that don't add value or performance. 

From a Scrum team perspective there are a couple of meetings: the daily; in which progress towards the sprint goal is shared. There  is refinement; in which stories are scrutinised with stakeholders until it is clear which work needs to be done. Each sprint there is a review, a demo and a planning session in which is talked about what is being or going to be made. And there is a retrospective in which the team introspects how it does the work. 

No other meetings are needed!

Many people find themselves in a hybrid form of Scrum with archaic roles and responsibilities in which they are obliged to attend some meetings. There are three types of meetings: informational, decision making and cake. The informational are most of the time unimportant and could be done with a memo; when you are invited think about what you are going to get out of the meeting and decline if it is not enough. It is no shame to not waste your or anyone else's time. The decision making meetings are a bit more important but again, choose to go if you think you can gain something by attending. In the meeting, steer towards decision making and go when done. A one hour meeting can mostly be shortened to half an hour by this approach. The last meeting is the cake meeting, this is the fun meeting, this is the one you should always attend!

To summarise: make everything smaller. Small work items, short meetings, less hierarchy and short sprints. This will increase performance and added value. Sometimes it needs a bit of courage when you need to make choices. But it is worth it. 

Let me know in the comments what you do to make your work smaller.

Why do we want to achieve standardised work?

We standardise to sustain good practises, make audits less painfull and make our work sustainable. Standardisation is not the goal, sustainability is. But how do we get from our current way of working to a more sustainable way?

"To throw away what you no longer need is neither wasteful nor shameful." - Marie Kondo

We start with sorting out what we don't need. We clean our work process and get rid of clutter. Anything that does not contribute to the creation of value, we remove. Ask with every step of the work process if it is really needed; what would happen if the step is removed? When you create a work item, think about the minimal product you are happy with.

"A dramatic reorganization causes correspondingly dramatic changes in lifestyle and perspective. It is life transforming." - Marie Kondo

The next step is to reorganise. To make it easy to work, to reduce movement, lookups and extra meetings. We can improve on this by refining the work we do and collect or link all information on a work item to that work item. We stop going to meetings that are not helping us to add value to the product we create.

"Visible mess helps distract us from the true source of the disorder." - Marie Kondo

To keep stuff organised, we regularly clean it. This means looking at our processes and stuff we make, and clean out the clutter. Did we took a short cut somewhere? Fix it. Do we need to refactor to improve? Do it. Stuff that is not maintained will cause headaches in the future. And yes, it takes time to do this, but it will take up more time down the road, when it gets in our way.

Now we come to the part where we can standardise. We make rules about the previous steps. We define our way of working, our definition of done, our test strategies, our meetup schedules. We make rules about how we as a team work. And we publish the rules to make it transparent to everybody how we work.

"The space in which we live should be for the person we are becoming now, not for the person we were in the past." - Marie Kondo

Sustainability is the ability to keep a pace over a longer period of time. In scrum this long period is called a sprint; perhaps we should have called it something else, because we don't sprint like sprinter. We are not trying to achieve a new world record on the 100 meter, but we are trying to create stuff for others over a longer period of time. We are trying to set a pace and slowly improve on that pace over time. We do this with the previous mentioned steps. We aim for goals and get there with small steps.

What is the best team size?

Some say a team of nine people is more than enough. Some argue that a team of fifteen works fine as well. My argument is that the smaller the team, the better their performance. But who's right and why?

The bigger a team is, the more interconnected it is, the more time it needs to discuss and agree. Each new member adds extra interactions to each other member, growing interactions exponentially. Brook found this out in the 1970's and created a formula for it.

Cognitive load is the amount of stuff a team can handle. The Paas-scale can be used to determine how much the type of work effects the load. The lowest number on the scale is simple work that costs very, very low mental effort. The highest number on the scale cost very, very high mental effort. 

Depending on the work, it requires more or less mental effort. What would happen if we plot the numbers? Let's have a look. 

The green line is Brooks law. It starts at zero and curves up, like one would expect of an exponential formula. The line tells us that with a team of three, there are three interactions. It also tells us that a team of fifteen will have 105 interactions.

The red line represents low mental effort work. From the graph we can tell that the size of the team doesn't really matter in this case. It almost seems that interactions can take place while working.

The yellow line represents very high mental effort, it crosses the green line at three. So interactions will very much effect this type of work, suggesting a team size of a maximum of three.

What about the recommended team size of "ten or fewer people in general" according to the 2020 Scrum guide? For average mental effort work a maximum of eleven people should be in the team. If the work is mentally harder, the maximum team size shrinks. This means that the team size by Scrum isn't very far of what the numbers say, but it is a maximum team size, not an average! 

It is fair to say that any member above eleven won't increase team performance significantly. Splitting a team with many members into two or even more teams of five to six will boost performance again. The cognitive load is halved per team, but interconnections have gone down by a factor resulting in an increase of performance.

Software development is an above average mental effort, making teams too big is very counterproductive. When you aim for a high performance team, go for team sizes of about five to six people.

Let me know what your thoughts are about team size in the comments below.

Time management with Scrum

One of the goals of Scrum was to get rid of meetings. With meetings I mean unnecessary ones. The only thing that counts is delivering value at the appointed moment so users will be happy. How does Scrum help with effective time management? Scrum helps time management with events.

Scrum events

There are five Scrum events: the sprint, the planning, the daily, the review and the retrospective. In the sprint everything happens: building, refining, testing, delivering. In the sprint all the actions take place to deliver value to the customers. During the planning event, all the work the team thinks they can do in one sprint, is planned: a workplan is thought off, a goal is defined and work items are selected to be completed in the sprint. During the daily standup developers (everybody is a developer in the team) discuss progress and impediments on the defined goal. In other words, they meet to see if they are going to achieve what they have promised all the stakeholders (that includes users). At the review everybody is invited to inspect what has been done during the sprint. Possibly a demo is given to show what has been made. The last event is the retrospective; a moment of reflection by the team to inspect and adapt on the way they do things.

Time spent

About 22.5% of all time has been claimed by Scrum events. We need another 10% per day to learn. That leaves 5.3 hours of actual work time. This doesn't sound much, but this is net time. So all the overhead is gone. We should be able to work for a bit more then five hours a day without interruption. 

Let us look at some reasons why we cannot spent this time and on some things that we can do to spent our time more effectively.

Pitfalls

One of the biggest pitfalls is that we are going to listen to other people outside of our time and outside of planned events. The social part is fine, we need that as humans. But the part where it as about work is wrong, there are events and a PO for that. When developers approach a stakeholder to verify something it is fine, then it is part of the developers job. But the other way around will cost time instead of saving it; therefor decreasing performance of the team as a whole.

The second most heard excuse of not working on items from the sprint is that a person is needed in a meeting. There is no meeting where a developer is needed on something that is not on the sprint log. And if there was one, the developer should be the initiator. I've seen developers that could not do their jobs because their expertise was needed. By pulling out a developer, the developers flow will be disrupted, causing a delay of a couple of hours to a days work. Some developers are so busy in attending meetings, that they cannot do their jobs anymore. Attending meetings will make the team loose focus and decrease team performance.

The last pitfall I will mention is to not use all the Scrum events. Some teams cut short on planning, review and retrospective. Not paying enough time for planning will result in extra planning during the sprint, in a change of calculated hours, in a deviation of the sprint goal and result in unpredictability to the stakeholders. Not paying enough time to inspection and adaption events like review and retrospective will stagnate learning of the team and will guarantee performance will never improve.

Good practices

A way to be more effective is to go pair programming. At first sight it seems that it will cost time. But ever since Kent Beck wrote about it, it has been proven over and over again that working in pairs improves quality of the work disproportionately causing less issues and less technical debt, opening up hours to add features.

Sharing knowledge in the form of a center of practice (run by developers) adds to quality of work and to speed of delivery. It will cost time in the form of a meeting. So run the meeting as an Open Space, free for everybody to join if they have anything to learn or to contribute. This is a very cost-efficient way of gaining lots of knowledge and improve quality of work, resulting in less rework and an improvement of performance.

The last tip on spending time more effective is to talk about it during the Daily Scrum. Talk to each other about the work one is doing and find a way to finish the work today. This will increase focus on getting the work done, it will put importance on it. Making your work more important than meetings makes it also easier to say no and stay focused.

Share

Let me know what is holding you back to increase performance or let me know what you did to get things done in the comments below!

Three ways to avoid unplanned work

When a team is creating software it has to take into account that there is more than only feature development. During Sprint Planning work is pulled from the Product Backlog, a Sprint Goal is drafted and an actionable plan is made. 

But what about work that shows up after the Sprint is started? Stakeholders might be in dire need to get stuff done and ask the team to drop what they are doing to get something fixed real quick. Unplanned work can break commitment on the Sprint and demotivate a team.

Welcome change, even late in development

One of the agile principles is to welcome change. As developers we want to deliver beautiful solutions to our users. We can allow change, but we need to think about implementing it as well. All changes have consequences. Consequences on time, effort, capacity and knowledge. In short, we need to refine first to understand what needs to be done so we won't create technical debt (technical debt is work that needs to be done after the solution is delivered). The impact of a late change can be huge. So, we welcome change, even late in development but not late in our commitment (of the Sprint).

Refinement

To minimize unplanned work a team can improve on refining. If unplanned work arises because of incomplete refinement, we should focus on improving that. Using the INVEST acronym can help improving the quality of the story and make it more transparent for the stakeholders. Transparency helps the stakeholders to reflect if they told the right story so that they can change the story before the sprint instead of during one, reducing changes and unplanned (extra) work.

Sprint length

The closest Scrum comes to a project development method like SDM is when we talk about the Sprint. A Sprint can be seen as a mini project, with a fixed planning, a fixed team and a fixed budget. The longer the Sprint takes, the longer stakeholders need to wait to get what they asked for. So the longer the stakeholder needs to wait to see if the story was correct. A longer Sprint length will therefor limit inspectability and adaptability. To reduce unplanned work, improve those by reducing Sprint length. If there is a lot of unplanned work, try a Sprint of a week.

No

The hardest part of being a Product Owner seems to be to say no. There are many stakeholders and a limited time to do work in. Naturally not all work can be done at once, so there needs to be some order of importance. The Product Owner has a Product Backlog in which the work is ordered at the PO's delight. And naturally not everybody agrees with the PO's priorities. It is important for the PO to say no to the items that don't match the scope of the product or are not opportune at the moment. In hybrid Scrum implementations where managers of the PO or Scrum team are responsible for work and HR, this can be a real pain. They can break into the Sprint and wreak havoc if a PO doesn't stand it's ground.

To improve on reducing unplanned work, keep track of it. Find out how much time is spent on unplanned work and compare it to planned work. Find out how much extra time is lost because it is unplanned. Be transparent, present it during review and talk about it with stakeholders. The goal is to reduce unplanned work and become more predictable and deliver on your promise.

To whom much is given, much will be required

"Ils doivent envisager qu'une grande responsabilité est la suite inséparable d'un grand pouvoir". - (Comité de Salut Public ('Committee of Public Safety') during the 1793 French National Convention)

Teams are getting more and more autonomy and like parents, managers are sometimes reluctant to let go. And for a good reason, management is used to have authority on product development and HR. Now they are supposed to trust the teams but still feel responsible.

A lot of teams are in pubescence, finding their way in a world where they have more autonomy about how the product is developed and how they as developers should keep on developing themselves. With a greater power of self-determination also comes the responsibility to make something out of it all. This shifts the authority of the team, the product and the persons involved away from the managers.

What is there for management left to do when the chicks fly out into their adolescence? First of all, less. Second, other stuff; or better put, the same stuff in another way. A manager has become a facilitator instead of a commander. A manager helps the teams perform better. As the teams continue to grow and learn, they still will have troubles facing them. In parallel of growing up: kids are getting married, going to buy their first house, getting kids and so on. Parents don't dictate their children should, at least I hope so, they help them in finding the way. They are becoming more equal all the time.

Toddlers

Small, new teams need parenting, they are toddlers, asking questions, not sure what to make of the world. They need to find a way of working for them, the team and within the organisation. They need help in getting a work location, using different facilities et cetera. A manager helps them on their way. Perhaps even deciding for them. The manager also helps Scrum Masters and Product Owners in understanding the Scrum framework, the people and the organisation.

Puberty

When a team has worked some time together they understand each others perks and start to perform better. They are ready to take on more ownership. They can ride their own bikes to school and they can, and should, start experimenting. The team will start learning the deeper understanding of Scrum, they will improve on inspection and adaption. They will become more and more transparent. As a manager you can see what the teams do, when you do your Gemba Walk and learn about what your teams need.

"The Gemba Walk is an opportunity for staff to stand back from their day-to-day tasks to walk the floor of their workplace to identify wasteful activities. The objective of Gemba Walk is to understand the value stream and its problems rather than review results or make superficial comments."

Adolescence

Teams are almost grown up, they will perform very well. Delivering on time, caring about customers and running experiments as a daily practice. Teams will demand full authority on everything they do. This is the time for the management to let go. After 21 years of raising the kids, let's hope it's shorter for teams, they are ready to fly out and settle, to have their own Lean Startup in the company.

Adulthood

When has a team become adult? When they are able to decide their own future and understand that with great power comes great responsibility. Do the teams still need managers? Well, it depends. It is like asking if kids ever stop asking their parents. Some do, some don't. But as a parent, a manager will always be there to help the team evolve and improve. And get invited to parties!

Three habits of an effective standup

Most teams have adopted a daily meeting, be it a standup or daily start, to sync their work. In these meetings people share what they have been doing, are going to do, what went well, what went wrong and they ask for help if they need it. A lot of meetings are becoming a drag where people only tell about their schedule yesterday and today. They inform about big pieces of work they are still working on, or about all the small details that they spend hours on.

What can we do to make these meetings more effective? How can they deliver value to our work?

One: talk about work, not persons

If you have an overview of the work that is in progress and the work that needs to be done, talk about when work in progress is done or what we need to do to get it done. We don't really care at this point in time when our peers have meetings with the dentist, we care about the work we committed to.

Two: work from right top to left bottom

If you have a Kanban system in place with a board and swim lanes and such, start on the top right lane of work that is not done (typically the last lane is the done-lane, so start in the lane before last). Decide with the team how the top item can be completed today, then work your way down that lane. If the lane is done, move a lane over to the left, rinse and repeat. With this system you focus on getting work done, to really deliver the work. Only the stuff that is done counts, the rest cannot be used by our customers and is therefore not done.

Three: limit work in progress

Set a limit on the maximum number of items per swim lane. A rule of thumb is here to put a WIP-limit in of half the team size. A team of six persons would have a WIP-limit of three per lane. When you limit the work that is being worked on, people need to focus on delivering current work. It is possible that not everybody is "working"; perhaps someone is idle. That is not a problem. As long as the work is done what the team committed to, being idle is fine. We are being effective and that is not efficient per se.

These methods focus on getting work done, to live up to the commitment we give our customers and stakeholders when we start a sprint. Being effective is focusing on the outcome of our work. The daily standup is an event we can use to inspect the results of that focus and adapt where needed.