When the Low-Hanging Fruit is Picked...Disrupt!
I’ve been on more than a few agile teams. If I’m doing my job as an agile coach or scrum master, eventually the team (assuming it is reasonably stable) gets to a comfortable place where all of the proverbial low-hanging fruit has been picked. The team is chugging along and the organization thinks “that’s a good team!”
Mission accomplished! I mean this in the same sense that George W. Bush meant it back when he declared the Iraq war over after a few weeks. Like those events, the mission just gets harder from there. We need to keep finding ways to improve.
Lots of teams settle for little things. “Let’s use Trello instead of a spreadsheet for our action items!” Great idea! I’ll bet that’s going to really accelerate the team’s pace of client value delivery. I know I’m being a bit snarky here, but it’s important to identify the signs when the team is so comfortable that they don’t want to rock the boat.
My suggestion is -- rock the boat! Few big gains are made from tiny changes. It happens. You should look for those opportunities. Though, I wouldn’t wait around too long for one to show up. Change tends to be uncomfortable and disruptive. Big changes can be downright stressful and really disruptive. So disruptive, in fact, that some leaders may put the kibosh on the initiative. “Bravo you” for trying anyway. Don’t give up!
The first thing to always keep in mind when you’re looking for changes to implement is that what matters most is delivering client value as quickly, efficently, and effectively as possible. Things like building team morale might contribute to that, but direct effects are usually the better choice. This suggests three areas of opportunity:
Finding ways to deliver faster (e.g. improved coding speed, testing automation, continuous deployment)
Finding ways to ensure that your designs are right before you build (e.g. prototyping, user interviews, surveys)
Streamlining workflows (e.g. removing external dependencies, increasing collaboration across the workflow, ensuring good/useful documentation)
For example, I know a developer who became interested in Elixir/Erlang. He was dabbling with it at home and realized that he could build scalable applications much quicker with it. He pitched it to his organization (who was mostly using C# and PHP at the time), and to their credit, they allowed him to spin off a small team to experiment. They were able to demonstrate that they could build a great app with ½ the people in about ½ the time.
In the end, the organization, despite the evidence, didn’t have the stomach to take on the disruption that would have ensued during such a fundamental transition. The developer left to go work for a company who was already using Elixir and his former employer rewrote their application in C#.
Big change takes courage! Not only from the team, but leadership as well. How we position these changes to our coworkers is fundamental to our success as coaches. We need to acknowledge that any great improvement after a point is going to require a significant investment. Agility requires us to keep pushing boundaries. It’s not comfortable. And, it’s not even always fun. But, it’s part of the job. Keep pushing!