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.