On the one hand, it's a stupid meme that was literally a mind virus that spread the way teenage girls copy each other's dressing choices.
On the other, it's the Devil you know. God knows what memery will replace it.
That's mostly about Scrum, and Scrum is not the entirety of Agile. Scrum in practice is often also decidedly not Agile if you go back to the manifesto, though that's not an issue with Scrum proper but an issue with Scrum as implemented. Scrum as implemented is often too ceremony focused (so values the processes over individuals and interactions) and inflexible in the face of certain kinds of change (valuing following a plan over responding to change). Again, not strictly a problem with Scrum, but just how nearly every good process (or at least decent process) gets corrupted when it becomes institutionalized.
You can see the same issues facing Lean and Theory of Constraints (both predating the Agile Manifesto, but sharing many of its characteristics or objectives).
> Again, not strictly a problem with Scrum, but just how nearly every good process (or at least decent process) gets corrupted when it becomes institutionalized.
Is there a solution to this? Where's the issue? Company size? Bad culture? Staff attrition?
Is the nature of software inherently hostile to any process or is it up to the industry being too young and changing very fast?
Every time I try to write about this it turns into an essay. I'll say this, I have no solution. I have an anti-solution.
The two things that I believe (from observation and experience, not a formal study) are essential regardless of your processes and practices: Communication and knowledge sharing.
If you have knowledge silos and overly strict communication channels (or absent channels) you are in for trouble in the future. You will not be able to adapt.
My anti-solution process: Always be adapting. Learn all the processes and practices under the sun (this doesn't mean you can do them or recite them cold, high level, also I exaggerate, not all of them). Select from them as if from a toolbox.
I'll point to Brooks' Mythical Man Month and the idea of the surgical team for an example. His idea was to model the team structure on the internal management of an operating room, you have a lead who directs much of the action going on. Doling out tasks and requirements to everyone else, in practice in software this may be the Senior Architect who creates the high level requirements and some of the low level ones and distributes to specific individuals or teams the job of doing the coding, but they don't get to inform the design (significantly).
This process can actually work. But don't cement it in stone. This process can fail spectacularly when you have too many senior people or you don't have an actual senior person to run it or for various other reasons. Ossification, cementing a process, is the thing that has to be fought against constantly. A process can work today, on this project, with these people, and for that customer. Take that same process and change any factor and it will often lose effectiveness, maybe even become grossly ineffective and bordering on professional malpractice when used.
Over time, that surgical team approach with the same people working on the same kinds of systems will start to show its age. Unless you hired a bunch of dunces, the junior people and specialists will be growing over time, improving in their capabilities. They will want or need more autonomy. Depending on the complexity of the system and capability of the individuals. This may happen very early or very late (which may mean never in practical terms since people do eventually at least retire or die, especially if you did hire a bunch of dunces). Your processes have to adapt to reflect this.
Similarly, in reverse, a process that overindulges in autonomy may struggle when inundated with new hires (especially very junior professionals) who don't know the system or even the industry well enough to properly exercise that autonomy. You may need to go back to a more structured form.
The relative immaturity of the software industry and also its incredible breadth of domains both serve to exacerbate this problem. People want solutions, they want to be handed a way of working that just works. But it doesn't, generally, exist. It may exist one day, but we aren't there yet. And even if we find The Way for one particular domain, it may not transfer to others.
This is a constant problem with my recent employers. They want to apply practices suited for information system developers and operators to embedded systems. I'm sorry, but Kubernetes is useless to me as an embedded systems developer. That isn't to say it couldn't be used, sure if we could develop a farm of servers connected to devices to run a bunch of tests we could probably use Kubernetes. Or a build farm. Or other similar tasks. But on the system itself, it's useless, and we've got people trying to apply it to our individual devices (fortunately they aren't pushing too hard). And in reverse, I would not use the approach that we take with our embedded systems (a big-design upfront approach) and apply it to most information systems. Their deployment costs approach zero, so they can iterate much more rapidly than we can and should make...
I like this analysis. It looks like instead of Agile we need Fluid.
Technically speaking, you have an equation where the number of variables is too high to successfully optimize against.
From a business point of view you need to have one person or a team that:
- Knows the organization very well.
- Knows the industry very well.
- Knows the domain and the problem very well.
- Knows the tech very well.
- Has the history of what was tried and what worked.
- Has the authority and an exceptional organizational abilities to analyze and improve the process all the time.
- Has exceptional people skills and a sense of rhythm to not increase the attrition by introducing changes too often.
When you frame it this way you see that the problem of designing the right process is really hard. You need to recognize the context and then create an ad-hoc process to fit that context. And keep optimizing.
People rely on frameworks and systems and you offer them none. It's like offering programmers switching from functional, to procedural, to OOP, to logical, to pen and paper all the time.
There is nothing wrong with Agile. There is not even anything wrong with learning how to do Scrum well and adapting it to your team. At the same time, there is something wrong with failing to learn Scrum well but telling your team to do it badly, then locking on to bad practices.
The thing is, these are all just tools. Use them well and they help you. Use them badly and they hurt you. Same as a table saw.
Saying Scrum in practice is
not true Agile is like saying Stalinism in practice is not true Communism.
Scrum is not true Agile, but Scrum is what happens when you mix average company incentives with the Agile dream.
The principals were good, the average company couldn't implement them, and it's time to improve on these ideals.
We've had 20 years to implement the Agile principals but average companies couldn't. There are systemic reasons why Agile can't be implemented in the average company as the manifesto dreamed. A new manifesto should make changes that reflect these systemic problems.
Companys should not be implementing a single Agile process across their entirety anyway. Each team has different people, and will need different details to their Agile process. A company who ignores that and just tells everyone to work the same way is putting processes over people, and thereby not Agile.
What did the Googles of the past use before they got to be the Googles of today? Agile in the purest sense - a couple people hacking something out. I think at the end of the day, a group of capable people with no strictly defined process will always win out over less capable people that follow some process to a T.
I still think bad scrum is still better than bad anything else. If you have to have a badly managed project, scrum keeps it from going off the rails.
My favorite project was this thing where everyone just chatted non-stop on Slack from morning to 4 AM on all the cool things they wanted to do. Since the conversation was non-stop, everyone just knew how the progress was and what needed to be done and we had almost no meetings, and onboarding was seamless.
It didn't scale though. The managers who kept it running that way eventually left. The conversation just became noise and as the teams grew bigger, nobody knew each other, so they broke off into different cliques.
17 comments
[ 4.1 ms ] story [ 37.1 ms ] threadYou can see the same issues facing Lean and Theory of Constraints (both predating the Agile Manifesto, but sharing many of its characteristics or objectives).
Is there a solution to this? Where's the issue? Company size? Bad culture? Staff attrition?
Is the nature of software inherently hostile to any process or is it up to the industry being too young and changing very fast?
The two things that I believe (from observation and experience, not a formal study) are essential regardless of your processes and practices: Communication and knowledge sharing.
If you have knowledge silos and overly strict communication channels (or absent channels) you are in for trouble in the future. You will not be able to adapt.
My anti-solution process: Always be adapting. Learn all the processes and practices under the sun (this doesn't mean you can do them or recite them cold, high level, also I exaggerate, not all of them). Select from them as if from a toolbox.
I'll point to Brooks' Mythical Man Month and the idea of the surgical team for an example. His idea was to model the team structure on the internal management of an operating room, you have a lead who directs much of the action going on. Doling out tasks and requirements to everyone else, in practice in software this may be the Senior Architect who creates the high level requirements and some of the low level ones and distributes to specific individuals or teams the job of doing the coding, but they don't get to inform the design (significantly).
This process can actually work. But don't cement it in stone. This process can fail spectacularly when you have too many senior people or you don't have an actual senior person to run it or for various other reasons. Ossification, cementing a process, is the thing that has to be fought against constantly. A process can work today, on this project, with these people, and for that customer. Take that same process and change any factor and it will often lose effectiveness, maybe even become grossly ineffective and bordering on professional malpractice when used.
Over time, that surgical team approach with the same people working on the same kinds of systems will start to show its age. Unless you hired a bunch of dunces, the junior people and specialists will be growing over time, improving in their capabilities. They will want or need more autonomy. Depending on the complexity of the system and capability of the individuals. This may happen very early or very late (which may mean never in practical terms since people do eventually at least retire or die, especially if you did hire a bunch of dunces). Your processes have to adapt to reflect this.
Similarly, in reverse, a process that overindulges in autonomy may struggle when inundated with new hires (especially very junior professionals) who don't know the system or even the industry well enough to properly exercise that autonomy. You may need to go back to a more structured form.
The relative immaturity of the software industry and also its incredible breadth of domains both serve to exacerbate this problem. People want solutions, they want to be handed a way of working that just works. But it doesn't, generally, exist. It may exist one day, but we aren't there yet. And even if we find The Way for one particular domain, it may not transfer to others.
This is a constant problem with my recent employers. They want to apply practices suited for information system developers and operators to embedded systems. I'm sorry, but Kubernetes is useless to me as an embedded systems developer. That isn't to say it couldn't be used, sure if we could develop a farm of servers connected to devices to run a bunch of tests we could probably use Kubernetes. Or a build farm. Or other similar tasks. But on the system itself, it's useless, and we've got people trying to apply it to our individual devices (fortunately they aren't pushing too hard). And in reverse, I would not use the approach that we take with our embedded systems (a big-design upfront approach) and apply it to most information systems. Their deployment costs approach zero, so they can iterate much more rapidly than we can and should make...
Technically speaking, you have an equation where the number of variables is too high to successfully optimize against.
From a business point of view you need to have one person or a team that:
- Knows the organization very well.
- Knows the industry very well.
- Knows the domain and the problem very well.
- Knows the tech very well.
- Has the history of what was tried and what worked.
- Has the authority and an exceptional organizational abilities to analyze and improve the process all the time.
- Has exceptional people skills and a sense of rhythm to not increase the attrition by introducing changes too often.
When you frame it this way you see that the problem of designing the right process is really hard. You need to recognize the context and then create an ad-hoc process to fit that context. And keep optimizing.
People rely on frameworks and systems and you offer them none. It's like offering programmers switching from functional, to procedural, to OOP, to logical, to pen and paper all the time.
The thing is, these are all just tools. Use them well and they help you. Use them badly and they hurt you. Same as a table saw.
Scrum is not true Agile, but Scrum is what happens when you mix average company incentives with the Agile dream.
The principals were good, the average company couldn't implement them, and it's time to improve on these ideals.
We've had 20 years to implement the Agile principals but average companies couldn't. There are systemic reasons why Agile can't be implemented in the average company as the manifesto dreamed. A new manifesto should make changes that reflect these systemic problems.
> A new manifesto should make changes that reflect these systemic problems.
I feel we're approaching this point.
My favorite project was this thing where everyone just chatted non-stop on Slack from morning to 4 AM on all the cool things they wanted to do. Since the conversation was non-stop, everyone just knew how the progress was and what needed to be done and we had almost no meetings, and onboarding was seamless.
It didn't scale though. The managers who kept it running that way eventually left. The conversation just became noise and as the teams grew bigger, nobody knew each other, so they broke off into different cliques.