Through my years at various companies, I have taken part in, and led, many different efforts at organizing a large team or department around a large – usually enormous – backlog. Things like SAFe, LeSS, and other methodologies try to codify this, providing patterns and best practices to tackle this challenge head on. My personal experience is that, while these methodologies help somewhat, they all still feel like something is missing.

In the past, I have often wondered if it can be done much more simply. The recent focus on #noestimates has reawakened my musings, and inspired me to write a bit about them. What if, instead of trying to play a min-max game with your team members, you simply tackle your backlog one item at a time, regardless of the size of your development team?

Sounds simple, and sounds exactly like what much of the Agile community is saying. My problem has always been in the details, when I start to envision how I would have attempted this in past known situations, I bump into some problem where I shake my head and say “nope, that wouldn’t have worked”. So I thought, imagine I were starting from a state where you are adding to existing software, but your people are not tied up in current work.

Let’s say you have a team of 100 people of all different types needed to successfully complete a piece of software. Let’s also say you have a rough vision of your product, broken down into 20 different features (or use cases, or vision bits, or whatnot) which seem to be mutually exclusive.  And let’s assume that the relevant experts from the team were involved in the clarification of these features.

Imagine if the PO were to take the top feature and say “Right, we have to get this one done, no matter what. Don’t think about any other features, just tell me, if we wanted to get this feature done as fast as possible with the highest quality, what do you need and who should be involved?”. What would happen? Could this work?

Let’s move on with the idea. Imagine that there is the right amount of facilitation for such a large group, and let’s also assume that the group has a fair amount of trust and mutual respect. The group might take a couple hours to figure out that seven people could work together on this feature and these particular seven people would be best suited. That new team can then go off and begin to dive into their feature, investigating details, breaking down into stories, identifying new dependencies, etc. etc.

Now continue this for the remaining features, always focusing only on the feature at hand and always maximizing for that feature from the remaining pool of people. At the end, there might be a handful of people left, which wouldn’t be able to take on the next feature, and so could join any of the other feature teams.

Now let’s assume a feature is completed. At that point, the PO would assemble the highest prioritized, unfinished feature team and ask, “Can any of these people help you finish your feature faster or with more quality?”. And move down the feature team list until all those people are assigned to a team, or perhaps a new team is created to pull the next feature.

Addendum

For a little more complexity, you could assume that all teams work on the same cadence and track their progress somehow. In the spirit of #noestimates, I assume that instead of tracking how much time is left, we would track perhaps how much of the total value is left to be delivered. This we could use in some kind of Cost of Delay calculation, which could affect the overall prioritization of the remaining bits of each feature. Then one could rearrange people to again maximize in order of priority.

Problems

Scheduling

During the clarification stage of a pulled feature, new dependencies could show up. One way of dealing with this at the start could be to only pull a new feature once the previous feature team raises a notice that they are clear. This could maybe take days, instead of hours. In this case, this exercise would not be an event, but a process. This opens up the problem of what the other people do in the meantime. An easy answer could be that everyone else either works on bugs, small improvements, or whatever they think is important, but in my experience this is a hard sell. Personally, I would not worry about it, as in my experience, motivated and smart people will create value on their own without shepherding.

Motivation

This process will almost definitely leave some people with hurt feelings and an experience of being left out, or chosen last. I don’t have a solution to this, other than to help everyone understand that being chosen last does not equate to skill, but rather to the particular expertise needed at this moment. Perhaps the next set of features will require a different skill set and the order will be reversed. That argument I find is rather weak though, and I wonder if there is a better way around this. One should also consider the defunding effect if the addendum is used, where a currently running team might lose an important team member to a more important feature, resulting in slower delivery. From a product point of view, such defunding might make perfect sense, but it can have a drastic effect on team spirit.

Churn

There is less team stability in this setup, as people might rotate quite a bit and work with a variety of different people. There is great value in this in the long run, but there is also high cost. One should try to balance stability with perfect skill fit. If the addendum is used, there is even less stability, and also perhaps a rapid shifting focus on features. Again, this can be quite valuable, but can also be incredibly noisy. In my opinion, it is important to not get lost in a sunk cost fallacy, but one must also be acutely aware of weariness among your experts. This could be a topic of its own post.

This process also does not address the individual desires and career paths of the team members. Again, this should be balanced against the priority of the features in some way, and again, this could be a topic of its own post.

Management

This is a very hard sell. Management is often so focused on maximizing and playing the resource game it is difficult to even get this idea across. One key point and prerequisite is to get management to understand the concept of local optima and the dangers of maximizing every individual’s output. This then brings the understanding that it’s better for everyone that people are idle every now and then, which makes the undertaking of a process such as described above more easily accepted.

Wrap up

I think this could work. I have seen too many attempts at maximizing the resources of every single team at once, which effectively leads to purposeful parallelization of work. Justified by the statement that everything is important and everything must be done anyway. Even in the case where all features need to be completed to have a release, I believe that leaning towards the front in the manner described above could bring better results and could also reduce complexity. However, this is all theoretical and just based on my own thoughts and experience, not on any research. Has anyone out there attempted anything along these lines? I would love to hear your experience. Perhaps this is a recipe for disaster and I am overlooking something fundamental. But perhaps this is a great way forward to reduce complexity, refocus everyone on prioritization and less parallelization, and to getting things done.