What Does it Mean to be Agile?
A few years ago, while serving as a Scrum Master at a small information technology company in the North Shore of Massachusetts, I was conversing with an agile coach on how to identify if someone was truly agile or just pretending. The catalyst for the conversation was a poor hiring decision the company had recently made. I was on that interview panel, and felt partly responsible. “The key,” the agile coach said, “is to ask them about their agile moment.” Every true agilist has one. It’s that moment when the methodology makes sense, and you realize how powerful it could be if everyone adopted it. That epiphany seems easy enough, but many do not have it because they have only worked in faux agile environments where the low-hanging fruit was enjoyed but they didn’t continue to work until the harvest was ready. Another common form of imitation agile is when the leaders use all the right keywords, but failed to embody servant leadership.
Instead of spending time defining agile, because I’m guessing that if you’ve found this blog then you already have a decent sense of what agile is. So I’d prefer to discuss what it means to be agile. Plus, there are plenty of blogs that provide solid definitions of agile. Here are a few: PMI.org, AgileAlliance.org, ManagedAgile.com.
In my experience, most companies decide to “become agile” or “go agile” because they want to do more work for less, or respond better to change. There are even some, if they are being honest, who don’t want to be agile, but can no longer resist the transformation, because the competition is encroaching on their coveted wedge of the market — and usually a very distraught CIO wants better results.
Those are not inherently negative motives, but it’s like buying a car simply because the sales pitch was heartfelt. In an attempt to sell agile industry consultants will speak in terms that interest senior leadership. Hence, Jeff Sutherland titled his book, Scrum: The Art of Doing Twice the Work in Half the Time. His team of consultants specialize in helping teams move faster, and if you’ve ever taken one of thier courses they like to boast about improving a team’s velocity by 500 to 1000 percent. Agile certainly helps in that area, especially within the scrum framework. However, the essence of agile is prioritizing the delivery of value to the customer — whomever is purchasing the product. Thus agile companies become product-centric, because they are attentive to the needs of the customer.
It’s not easy to be product-centric. Many companies are employee-centric (which includes senior leadership) or technology centric, even though they claim customer focus is at their core. As a litmus test, simply audit the reward system and decision-making practices to identify thier focus. If you’ve ever experienced a command-and-control leadership style or worked in a setting where Subject Matter Experts (the rebranding of Towers of Knowledge) held teams emotionally hostage until everything was built thier way, then you’ve experienced very anti-agile behavior. If that behavior was tolerated, then the company was only pretending to be agile. To be clear about customer centricity, some organizational leaders incorrectly translates that to mean everything has to be worked on at once. Agile is not giving the customer everything they want, it’s giving them what they value most in the shortest amount of time possible.
When a company goes agile what they should be told is that it takes an incredible amount of commitment, and the courage to make really difficult decisions. Commitment is needed to persevere through all of the ugliness that agile highlights, and trust me there’s a lot of it. If you’re not seeing ugly everyday then transparency isn’t being practiced. Ugly doesn’t go away. I’ve been on very high-performing teams that dealt with a lot of ugly. The difference, and this is part of what made them so efficient, is how the handled the ugly. Courage is also needed, because difficult conversations will need to be had with employees and customers. When employees identify too much with their work they can take any critique too personal. For example, product A gets more favorable mentions and is thus deemed valuable than product B, so the developer(s) working on product B feel less valued by association. Can a good manager coach individuals away from that mindset, yes, but the negative associate lies between relational and status conflict types, both of which can be detrimental to a team (for more on coaching team conflict see this helpful infographic). Additionally, product owners and product managers will need to help customers understand how to prioritize their wants and needs. In my experience, external customers are much more understanding with this than internal customers. The inability to adapt on the part of the internal customer can be a sign of non-agile incentivizing and/or a workflow structure that restricts product ownership by dividing the solution into parts across multiple teams or departments. The inability to provide an end-to-end solution can be demotivating to knowledge workers who thrive on autonomy, and destructive to agile teams who end up feeling like a cog in a wheel.
Agile enables a team (or organization)to improve through the identification of inefficiencies. The key word in that sentence is enables. Agile can be either a revelation or a phase. What is done with the information provided will be the determining factor. When a team, department, or organization has an agile moment it’s palpable: organic collaboration replaces turf-wars, bottom-up innovation replaces stringent requirements, and ethusiam replaces evangelism. I know organization that are years into an “agile transformation” and yet teams and individuals still need to be convinced that agile is the best way to work. Organizations like that are not agile, but they pretend to be… year over year.
If like these topics consider following me as I delve into these topics more.
A Note on references: most of my agile knowledge comes from first hand experience, thus I do not cite any references. However, there is a plethora of great research on motivation of knowledge workers, team conflict, and leadership which I will cite as it is discussed.