At my current employer, we don't impose initial ways of working but encourage teams to find their own approach, though they often adopt scrum or kanban patterns.
After my first reading, I thought: "Use the framework to fill the common 70% and adapt it to fit the remaining few percents."
But Allen makes a compelling point: Have we ever truly seen teams evolve from their initial framework in a meaningful way? If i'm honest with myself: no! I wonder which interesting ways of working we might never touch, because we tend to stick to familiar concepts.
Who said anything about no constraints? We are not children, and we are not anarchists. The main thing is that those constraints, that are not practical ones imposed by things like finances, are created by the individual teams. That’s what it means to be self managing, among other things. It certainly is not everybody doing whatever the hell they feel like.🙄
We cannot be alpha and omega of everything. We cant be Agile experts, software development experts (backend, frontend), devops, sdlc managers, product and so on. Thats why we embrace frameworks.
In your case shall we also drop CI/CD, Trunk Based Development, TDD, Lean Startup, Product Operation Model, Domain Driven Design, Clean Architecture, SOLID, Object Oriented Programming, microservices, event driven architecture and many many others?
And spend our own effort to figure it all from scratch?
Or we shall just know them all and their foundations to pick all the best that suit our needs?
I've worked with cross-functional teams that did all of that. I honestly don't see the problem. A cross-functional team is responsible for taking a conversation with a customer all the way to delivering software to their hands. All of the skills you mention need to be present on the team to pull it off, though if you're working in a true DevOps environment, the automation will take on much of the burden. Also, I'm talking about skills (which can be shared), not people. One-skill-per-person siloing doesn't strike me as useful. Google "T-shaped skills" to learn more.
I should add that your cynicism makes it difficult to answer you. Certainly, some of the things you suggest are ridiculous, but some aren't. If I haven't addressed your concerns, please reply with follow-up questions.
Apologies if you found my comment rude. Maybe I overreacted.
My point was that all the listed things are some kind of frameworks and we need them in order to operate the whole software development process. Without the frameworks established by previous generations, every next generation would have to reinvent the wheel and with the help of the frameworks we can just build on top.
So basically I just disagree that #noframework is the way to go. Quite opposite: there is no progress without closing the things that worked out into frameworks and reusing them, allowing ourselves to climb up on the abstraction ladder
But Agile is not a framework, it's a set of values and principles. In fact, of the things you list (CI/CD, Trunk Based Development, TDD, Lean Startup, Domain Driven Design, Clean Architecture, SOLID, Object Oriented Programming, microservices, event-driven architecture), NONE of them are frameworks. They are techniques, architectures, philosophies, &tc. None of them are frameworks A POM might be a framework if it's treated as rigid directives rather than a way to capture how things are done now. Scrum is a framework. SAFe is a framework. Anderson's "Kanban method." is a framework. All those frameworks prescribe specific ways of working, including mandatory meetings. They all specify how you must go about the work. They prescribe specific roles and sometimes organizational architectures. Etc. They are also quite rigid, not allowing any deviation from the prescribed way of doing things.
A (ideally lightweight) framework is simply a set of boundaries to enhance creativity. A boundless, do-what-you-like environment is not conducive to creation or innovation. We thrive in restriction. I quote some who know far more than I on this matter...
"The enemy of art is the absence of limitations." — Orson Welles
"Design depends largely on constraints." — Charles Eames
"Instead of freaking out about these constraints, embrace them. Let them guide you. Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage." — 37 Signals
Scrum becomes damaging when people try to follow it without understanding its inherent simplicity, turning it into a cargo-cult-like ritual for compliance. It isn't that, but it is easy to make it that.
“Taking something that worked for one team and forcing it down everyone’s throat” is spot on. There are practices and principles that remain, but cook off the prescription.
That can be a hard or easy problem, depending on the organization. Generally, ask for forgiveness, not permission. I know of one group of three teams that literally walled themselves off from the rest of the office using whiteboards and instituted their own process within the walls. Managers were not allowed in 😄. The managers didn’t even notice until they did notice that the productivity of those three teams had gone way up. Stupidly, they did not ask those teams to spread what they were doing to the rest of the organization, but they at least left them alone.
Thank you for your answer. I also prefer to take freedom and ask for forgiveness. Some time it hurts and painful, but I think regrets of missing opportunities are harder. At least for me.
I still is trying to find a balance. And will also do it
“best people to figure out the best way to work are the people doing the work”
And if they sit in 9 different functional silos with no intention to figure out the best way to work, what could be the good starting point to change that intention?
It's an interesting perspective.
At my current employer, we don't impose initial ways of working but encourage teams to find their own approach, though they often adopt scrum or kanban patterns.
After my first reading, I thought: "Use the framework to fill the common 70% and adapt it to fit the remaining few percents."
But Allen makes a compelling point: Have we ever truly seen teams evolve from their initial framework in a meaningful way? If i'm honest with myself: no! I wonder which interesting ways of working we might never touch, because we tend to stick to familiar concepts.
Nice article!
Actually: go back to the basics of what all those frameworks are built on:
- Individuals and interactions over processes and tools
- Working solutions over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Who said anything about no constraints? We are not children, and we are not anarchists. The main thing is that those constraints, that are not practical ones imposed by things like finances, are created by the individual teams. That’s what it means to be self managing, among other things. It certainly is not everybody doing whatever the hell they feel like.🙄
We cannot be alpha and omega of everything. We cant be Agile experts, software development experts (backend, frontend), devops, sdlc managers, product and so on. Thats why we embrace frameworks.
In your case shall we also drop CI/CD, Trunk Based Development, TDD, Lean Startup, Product Operation Model, Domain Driven Design, Clean Architecture, SOLID, Object Oriented Programming, microservices, event driven architecture and many many others?
And spend our own effort to figure it all from scratch?
Or we shall just know them all and their foundations to pick all the best that suit our needs?
I've worked with cross-functional teams that did all of that. I honestly don't see the problem. A cross-functional team is responsible for taking a conversation with a customer all the way to delivering software to their hands. All of the skills you mention need to be present on the team to pull it off, though if you're working in a true DevOps environment, the automation will take on much of the burden. Also, I'm talking about skills (which can be shared), not people. One-skill-per-person siloing doesn't strike me as useful. Google "T-shaped skills" to learn more.
I should add that your cynicism makes it difficult to answer you. Certainly, some of the things you suggest are ridiculous, but some aren't. If I haven't addressed your concerns, please reply with follow-up questions.
Apologies if you found my comment rude. Maybe I overreacted.
My point was that all the listed things are some kind of frameworks and we need them in order to operate the whole software development process. Without the frameworks established by previous generations, every next generation would have to reinvent the wheel and with the help of the frameworks we can just build on top.
So basically I just disagree that #noframework is the way to go. Quite opposite: there is no progress without closing the things that worked out into frameworks and reusing them, allowing ourselves to climb up on the abstraction ladder
But Agile is not a framework, it's a set of values and principles. In fact, of the things you list (CI/CD, Trunk Based Development, TDD, Lean Startup, Domain Driven Design, Clean Architecture, SOLID, Object Oriented Programming, microservices, event-driven architecture), NONE of them are frameworks. They are techniques, architectures, philosophies, &tc. None of them are frameworks A POM might be a framework if it's treated as rigid directives rather than a way to capture how things are done now. Scrum is a framework. SAFe is a framework. Anderson's "Kanban method." is a framework. All those frameworks prescribe specific ways of working, including mandatory meetings. They all specify how you must go about the work. They prescribe specific roles and sometimes organizational architectures. Etc. They are also quite rigid, not allowing any deviation from the prescribed way of doing things.
A (ideally lightweight) framework is simply a set of boundaries to enhance creativity. A boundless, do-what-you-like environment is not conducive to creation or innovation. We thrive in restriction. I quote some who know far more than I on this matter...
"The enemy of art is the absence of limitations." — Orson Welles
"Design depends largely on constraints." — Charles Eames
"Instead of freaking out about these constraints, embrace them. Let them guide you. Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage." — 37 Signals
Scrum becomes damaging when people try to follow it without understanding its inherent simplicity, turning it into a cargo-cult-like ritual for compliance. It isn't that, but it is easy to make it that.
“Taking something that worked for one team and forcing it down everyone’s throat” is spot on. There are practices and principles that remain, but cook off the prescription.
Thank you for sharing Allen.
I agree that practices are bit transferable and every team unique.
I also saw many times that organizations are afraid to give autonomy to the teams. They do not trust and want to control.
What could you suggest to a team or developers in this situation?
That can be a hard or easy problem, depending on the organization. Generally, ask for forgiveness, not permission. I know of one group of three teams that literally walled themselves off from the rest of the office using whiteboards and instituted their own process within the walls. Managers were not allowed in 😄. The managers didn’t even notice until they did notice that the productivity of those three teams had gone way up. Stupidly, they did not ask those teams to spread what they were doing to the rest of the organization, but they at least left them alone.
Thank you for your answer. I also prefer to take freedom and ask for forgiveness. Some time it hurts and painful, but I think regrets of missing opportunities are harder. At least for me.
I still is trying to find a balance. And will also do it
“best people to figure out the best way to work are the people doing the work”
And if they sit in 9 different functional silos with no intention to figure out the best way to work, what could be the good starting point to change that intention?