#AgileDoesNotHaveToBeThisHard. Insight #7.
I love the essence of Agile at the team level. This is what I believe the essence of Agile is:
Have a team of capable people, managing themselves, be focused on delivering value to their customers. They:
– strive to deliver value as quickly as possible
– create work in small bits, either through a timeboxed for flow model
– collaborate with stakeholders to discover what’s really needed
– use feedback to drive their work, adjusting as needed based on the feedback received
– take an attitude of welcoming changes – both in what needs to be done and in how to do it
– frequently reflect on how to become more effective and adjust their behavior accordingly.
– learn how to do its practices better, challenge those practices, and learn how to change faster over time.
– don’t follow process unless it supports them and they change it when it doesn’t
-don’t rely on documentation or emails to convey information but use direct communication whenever possible
– attend to the quality of the product being built, in particular, the technical practices being used
– recognized that architectures, requirements, and designs will need to emerge
In addition, management provides an effective environment for people in the organization to work in.
In addition to this, I believe that there are many first principles that can further guide us and enable teams to be more effective. This reflects that without theory, experience is blind (Kant) and expensive (Deming).
Systems thinking is also essential so when things go wrong we look to improve the system and not blame the people.
Scrum adds restrictions on this view in an attempt to make things simpler:
– purposefully incomplete
– follow until you understand (which implies you can’t understand at the start)
– a focus on empirical process control
– an underlying belief that we can’t get to cause and effect because we’re in a complex adaptive system
– a lack of a need for management
It’s also removed technical practices and has become more abstract and more confusing in the process.
Without this extra guidance of what works, it requires being immutable so people don’t go off course. This says not to challenge its assumptions. This violates the essence of Agile – learn how to do things better. This tends to have people follow Scrum instead of discerning what improves being Agile.
I’m happy for feedback to help me understand why these limits are useful. But please don’t defend them. Don’t tell me it’s Scrum’s creator’s right to do it. Of course, it is. But why is doing it effective?
And don’t say “Scrum allows what’s being suggested.” I know it allows a lot of things. But if things are important, allowing is less effective than encouraging.
See my first comment if you believe there’s a better way.