I’ve been delivering talks at conferences & user groups for over 20 years. One question I ask at most of my talks for developers is “how many of you spend most of your time fixing bugs?” Throughout all of these years, I get about 9 out of 10 telling me they do. But they don’t.
I go through this conversation with them:
- Consider a time you were notified of a bug.
- remember the time you spent trying to reproduce it
- and then figured out how to fix it and did that
- And then undid it because it broke something else
- And then found the real cause and fixed it
- Now, how much time was actually spent fixing the bug?
- I’d suggest that most of your time was spent finding the bug.
Now this is not just semantics. Consider from when you write a bug (and yes, do you write them even though you say “I found a bug” as if someone else wrote it 😊 ). And let’s say it was found right away (maybe you have automated testing). It likely wouldn’t take very long to fix, because it’d probably be due to the last thing you did. But if you discover it weeks later, even if nothing changed, it might take you hours or days to find and fix it. If things have changed, it’d take longer. And think of the wasted time you would have caused others.
The moral? Spend a little time so that you don’t have to look for bugs.
Scrum presumes it is effective to give all teams a simple preset, immutable framework that each team must follow until they figure out how to manifest it.
Scrum is designed for and requires cross-functional teams doing work that is plannable. If these conditions aren’t met it is presumed that manifesting Scrum’s rigid framework will achieve Agile in all situations if people are motivated.
An underlying believe is that teams can’t initially understand what they are supposed to do so must be given a predefined set of rules that must be implemented without change until the team understands what’s happening.
While this approach works when cross-functional teams can/should be created & work can be planned, it can causes resistance & abandonment of misunderstood practices when teams have challenges adopting the framework or attached to their roles.
Have expert have 2 hr discussion w/ team&their management to see what alternative or additional practices would be useful. Use these to provide a set starting point and provide teams a guide on how to improve/change practices when they encounter challenges. While coaching still advisable, significantly less will be needed.
I invite people to discuss these alternatives.
On a twitter thread there was an implication that perhaps the reason some people don’t engage with me is because they perceive my purpose is to destroy. I have told myself that as a good person that is not my intent. But I now realize it is.
Over the last 20 yrs I have observed many patterns of challenge & success in the adoption of Agile. I am convinced that Agile adoptions do not have to be as hard as they usually are. Most of the time they are difficult I see unexamined assumptions as contributing to this. This includes both beliefs underlying the approach used & how to teach it as well as if/when to introduce certain practices.
You destroy unexamined assumptions by examining them (they become examined beliefs). That’s what I am doing.
But many people make their livelihood on frameworks & methods that I believe are based on these unexamined beliefs. And this causes a cycle of poor Agile adoption w/o serious reflection. Unfortunately, as Upton Sinclair has observed, “Its hard to get a man to understand something when his salary depends on his not understanding it.”
My mission is serve the practitioners and consultants who have an aligned mission – making organizations and their people more effective regardless of approach.