Agile Actually Does Not Have Low Hanging Fruit…
Are you “doing” Agile? Scrum or Kanban? Doesn’t matter. Probably some of you aren’t actually implementing or running with Agile. Even if you believe you are.
Sorry to disappoint you but this boils down to realizing that Agile does in fact have no low hanging fruit.
What Does That Even Mean?
Low hanging fruit, the easily reached, easily attainable target. Ever been up in a cherry picker? That sense as the hydraulics lift you into the air in that small metal basket. As the basket vibrates and you hold on and then … yep, you look down and realize just how fast you got that high up. Agile is like that. Implementing Scrum or Kanban the first time feels like that, especially for the matrix, CMMI and waterfall crowd. Where’s my safety net? Ironically, Agile is meta. The more iterations you do, the more confident you get.
Unless you fall prey to the illusion that certain activities within Agile are easy and you can cherry pick those and ignore the tough stuff. It becomes about performing ritual or kata for its own sake instead of a deeper understanding of why and how to do things, and do them right.
Kata is mindful and any martial artist will explain the benefits of understanding their purpose. Like many others, I’ve applied the kata concept to testing in the past.
Don’t do these. No really, don’t.
There is one more arguably, having tools that don’t integrate, communicate or display actionable information. Allowing technical debt to fester.
If any or all of these are happening with your Agile team then you fell into the illusory trap of low hanging fruit.
The Warptest POV
At this point you may be thinking all is lost or getting a bit annoyed. None of this is irreversible and the solution lies in the Principles behind the Agile Manifesto. If you have never read this and or don’t review it with your team, then this is the first change to make. Heck make this the default page in your team browsers, print it big for each work-space and read it aloud together.
See the photo above, I didn’t choose it just for the tree but also for the chicken below. I was sorry to see the chicken and pig analogy dropped (albeit for some evident reasons). The allegory has benefit but is loaded with negative connotation. Find another story that works for you.
Invest in your people. Train them and give them the knowledge and skills to succeed. We can’t just say to a team member, “Hey mate, you’re Scrum Master from now on.” They need to know what a Scrum Master does, how to do it and they will need guidance and help. A Certified Scrum Master course wouldn’t hurt either.
Make the changes that need making and do so fearlessly but not aggressively. Use honey, not vinegar.
Why is all this important? If you leave things as they are, stuck in some bastardized version of Agile then you are plotting your own failure. It won’t work and management will consider Agile a failure. This is a disservice to your efforts, your product and Agile itself.
The point of all this is to drive success. Some of the things you shouldn’t do are the end of a path taken that gives you short term, warm and fuzzy self-gratification instead of keeping your eye on strategic success.
This always makes me think of the scene in Arnold’s Conan the Barbarian where he and his companions are asked,
What is best in life?
Conan knows the answer and so should you. In the case of your team and product it’s adhering to a concrete definition of success. For me that is happy customers who come back for more of our product.
What’s your definition of success?