Like the author, I’ve been at this a long time. Most recently, I’ve been working with people who are practicing ‘mob programming.’ I like it but I have mixed feelings about it. As a technical coach, it’s great. When you have a design discussion, everyone is there. Learning and knowledge diffusion are maximized - but I can’t help feeling that it really is slower and not ideal for all circumstances. Distributed work has been around for decades but the trend to make it “the way we do things” at companies is recent. Now people are saying it’s not just convenient, it’s better.
It’s interesting that we have these two diametrically opposed ways of working and advocates of each don’t just say “Hey, I like to work this way.” They proselytize and make the pitch that their way of working is best. In fairness, the author is saying something more nuanced, but yes, it is a pitch. I agree with him when he says context matters. It’s ok to admit that preference is a part of the context.
I like to think of scrum as agile training wheels. Calling what this article suggests “post agile” is avoiding the concepts behind why agile exists and what it actually is. Agile is not scrum, but scrum is agile. In the case that this seems confusing, let me clarify.
Yes, scrum is great sometimes - but it should never be the ideal solution. With teams that don’t often change, scrum tends to require a lot of bottle-necking on progress, large in-group meetings, and extraneous communication. This is because scrum introduces a large amount of process which essentially only exists to help everyone communicate.
When people get to a point where they are able to communicate effectively with the right people without needing daily stand-ups, for instance, standups become a bottle-neck. The reason for this is that there are tendencies in many developers to avoid talking to people until next standup out of fear of bothering the other person or even sometimes laziness. This often can block people for half a day if you do daily standups.
This is made even worse with teams that do standups in the morning, because often times developers are doing their standups before they even have a full handle on and remember what they were working on and running into the day before. Standups should be mid-afternoon, post-lunch, etc at a good breaking point where the majority of the team is going to be taken away from producing anyway.
That’s a long example, but it demonstrates how just one of the practices common in scrum can block people.
I believe that we should always be working toward a lean agile model, and scrum should be used as a way to help people gel when it isn’t happening. Once people are communicating effectively, get rid of it.
A lean agile model never precludes or punishes asynchronous work, and it is completely compatible with everything suggested in this article. With all that background out of the way, I suggest to consider that the bigger problem is simply that people think scrum means agile - when agile is a higher level methodology.
Agile is about being able to change direction easily and quickly with minimal velocity impact. It’s not about sitting in a room talking about how great last week went or standing in a group reiterating what you’re doing even though everyone already knows. That’s just a scrum thing, and if everyone already knows you shouldn’t be doing it.
Let us not invent a new name for something that already exists. Instead, let’s embrace what agile is and try to understand where our practices and methodologies have caused us to conflate different ideas and processes.
This is made even worse with teams that do standups in the morning, because often times developers are doing their standups before they even have a full handle on and remember what they were working on and running into the day before
Sounds like every stand-up I’ve ever been in. I saw an interesting comment about the trajectory of stand-ups, where people eventually end up spending half their time talking up how busy they were yesterday. Seems like moving stand-ups to after-lunch would discourage that, too.
Like the author, I’ve been at this a long time. Most recently, I’ve been working with people who are practicing ‘mob programming.’ I like it but I have mixed feelings about it. As a technical coach, it’s great. When you have a design discussion, everyone is there. Learning and knowledge diffusion are maximized - but I can’t help feeling that it really is slower and not ideal for all circumstances. Distributed work has been around for decades but the trend to make it “the way we do things” at companies is recent. Now people are saying it’s not just convenient, it’s better.
It’s interesting that we have these two diametrically opposed ways of working and advocates of each don’t just say “Hey, I like to work this way.” They proselytize and make the pitch that their way of working is best. In fairness, the author is saying something more nuanced, but yes, it is a pitch. I agree with him when he says context matters. It’s ok to admit that preference is a part of the context.
I like to think of scrum as agile training wheels. Calling what this article suggests “post agile” is avoiding the concepts behind why agile exists and what it actually is. Agile is not scrum, but scrum is agile. In the case that this seems confusing, let me clarify.
Yes, scrum is great sometimes - but it should never be the ideal solution. With teams that don’t often change, scrum tends to require a lot of bottle-necking on progress, large in-group meetings, and extraneous communication. This is because scrum introduces a large amount of process which essentially only exists to help everyone communicate.
When people get to a point where they are able to communicate effectively with the right people without needing daily stand-ups, for instance, standups become a bottle-neck. The reason for this is that there are tendencies in many developers to avoid talking to people until next standup out of fear of bothering the other person or even sometimes laziness. This often can block people for half a day if you do daily standups.
This is made even worse with teams that do standups in the morning, because often times developers are doing their standups before they even have a full handle on and remember what they were working on and running into the day before. Standups should be mid-afternoon, post-lunch, etc at a good breaking point where the majority of the team is going to be taken away from producing anyway.
That’s a long example, but it demonstrates how just one of the practices common in scrum can block people.
I believe that we should always be working toward a lean agile model, and scrum should be used as a way to help people gel when it isn’t happening. Once people are communicating effectively, get rid of it.
A lean agile model never precludes or punishes asynchronous work, and it is completely compatible with everything suggested in this article. With all that background out of the way, I suggest to consider that the bigger problem is simply that people think scrum means agile - when agile is a higher level methodology.
Agile is about being able to change direction easily and quickly with minimal velocity impact. It’s not about sitting in a room talking about how great last week went or standing in a group reiterating what you’re doing even though everyone already knows. That’s just a scrum thing, and if everyone already knows you shouldn’t be doing it.
Let us not invent a new name for something that already exists. Instead, let’s embrace what agile is and try to understand where our practices and methodologies have caused us to conflate different ideas and processes.
Sounds like every stand-up I’ve ever been in. I saw an interesting comment about the trajectory of stand-ups, where people eventually end up spending half their time talking up how busy they were yesterday. Seems like moving stand-ups to after-lunch would discourage that, too.