Agile Is Supposed To Be Simple…
I was reading about the new iteration of SAFe that came out a few days ago. I appreciate what Dean is doing with SAFe and totally get the problem he is trying to solve. That said, it makes me wonder how folks receive the ever growing complexity of the model.
Fundamentally, we have two choices as leaders of companies.
We can model and manage the complexity inherent in the system, or we can reduce that complexity. What we can’t do is pretend the complexity doesn’t exist and fail to do something about it. So often I see agile implementations that want to ignore what’s really going on.
This is too complex, agile is supposed to be simple.
True, but agile is also supposed to be 6-8 people sitting in a room with an onsite customer. Teams are supposed to have autonomy. Teams are supposed to have the power to decide. Teams are supposed to have the ability to change direction when they learn new stuff.
You can’t have your cake and eat it too.
It’s naive to think that three roles, three ceremonies, three artifacts are going to fix everything in your organization. It’s naive to think that you can self-organize the complexity away. It’s naive to think that companies are going to stop caring about when and how stuff is going to get done.
So again, we come back to two fundamental choices for making all this work. Model and manage the complexity in the system, or make the system less complex. It’s your call.
Comments (5)
David Bishop
Very well said. That’s exactly what comes to my mind everytime I look at the SAFe model…. just too complex.
Bob Marshall
Keen observations. I’ve been focused for at least the past twenty years on making things simpler. “Natura valde simplex est et sibi consona”. How much simpler could it get than the one #AntimatterPrinciple?
– Bob
Craig Buchek
It’s becoming apparent to me that Kaizen (continuous improvement) is more important than any other Agile practice or principle. It doesn’t matter so much *how* you improve, as much as the fact that you *are* working to improve.
Agile methodologies have a lot of practices that you can adopt in your improvement process, but the practices should be seen as stepping stones in the path, not as an end state.
That said, simple will generally beat complex, and starting simple is a necessity.
Gianpaolo Baglione
One of the reasons SAFe is appealing because it aligns agile teams to money and power in a way that the people with the money and power can understand.
Jay Conne
Well said Mike, model the complexity or reduce it.
Or perhaps, try to reduce it first and then model it.
SAFe, like all approaches to large scaling, including yours, provides a lot of tools, thinking tools, to address typical complexity of large organizations. One can use the ones needed in one’s context and benefit from the documented relationship between them. Asking the comprehensive set of questions os the question – for leadership and the empowered individual contributors.
The whole process around releases is the challenge that is served by the second level with multiple teams’ work being integrated.
The higher layers of the business goals driving mission charge and funding needs to all be made coherent. That’s the WHY driving the rest – the WHAT and HOW.
Any approach that achieves this is worthy of consideration. A big advantage of SAFe is the extensive, graphically integrated, documented and freely available content.