The Dark Side of Agile

agile yin-yang

Along with the virtues of Agile Software Development also can come some destructive downsides that can erode trust and effectiveness within your company culture.

I recently attended a 3-day Scrum certification class where the founder of the particular methodology was the instructor. He insisted that managers not participate in standup meetings, planning meetings, grooming sessions, retrospectives, or any other meetings where an agile team might discuss their work. When asked why, he said, managers micromanage and lead through fear and intimidation because they control employee salaries, career progression, time-off requests and the decision whether to fire them. I have heard this perspective before, but decided to challenge him nonetheless. I suggested that if any of my managers lead in that manner, they would either need to change, no longer be managers or seek employment elsewhere – I guess you could call that managing through intimidation. When I suggested that managers can and should be supportive of their employees, his partner chimed in and suggested I was describing “Servant Leadership.” The instructor owned up that he had never seen such a leadership style in action and that his entire career had been in a very hierarchical, command and control organization within a culture that was very hierarchical.

I later realized that when Agile Coaches he had trained would come into organizations and spread this philosophy of distrust in leadership and insist managers be removed from team meetings and suggest managers be removed altogether from the organization. Team members can buy into this perspective and it can create a distrust in leaders that can taint every interaction potentially throughout their career. As they say, Trust is hard to gain, easy to lose and even harder to regain.

Certainly, there have been managers that manage through fear, intimidation and micromanagement, but people that buy into the notion that all managers/leader think along these lines must not be familiar with…

According to Laszlo Bock’s “Work Rules!” Google, instead of removing managers from all the significant day-to-day meetings where they can see their employees in action, ask open-ended questions, listen and learn, … decided instead to “cleave the knot by deliberately taking power and authority over employees away from managers

Here is a sample of the decisions managers at Google cannot make unilaterally:

  • Whom to hire
  • Whom to fire 
  • How someone’s performance is rated 
  • How much of a salary increase, bonus, or stock grant to give someone 
  • Who is selected to win an award for great management 
  • Whom to promote 
  • When code is of sufficient quality to be incorporated into our software code base 
  • The final design of a product and when to launch it

Each of these decisions is instead made either by a group of peers, a committee, or a dedicated, independent team. Many newly hired managers hate this! Even once they get their heads around the way hiring works, promotion time comes around and they are dumbfounded that they can’t unilaterally promote those whom they believe to be their best people. The problem is that you and I might define our “best people” differently. Or it might be possible that your worst person is better than my best person, in which case you should promote everyone and I should promote no one. If you’re solving for what is most fair across the entire organization, which in turn helps employees have greater trust in the company and makes rewards more meaningful, managers must give up this power and allow outcomes to be calibrated across groups.

The concern I have with Google’s approach as described above is that it feels like it’s trying to legislate fairness and good leadership behavior. The notion of calibrating across teams and making hiring, firing, promotion decisions with cross-organizational support and buy-in are things that are in service of servant leaders. Legislating it, as this feels, seems more like a tell than a sell, and in my experience, tells tend to get less genuine buy-in and appreciation than sells. Managers often have the best perspective to advocate and make a case for the members of their team. The modern manager/leader, imho, should want to solve for fair practices across all employees. If Google discovers that “Many newly hired managers hate this!” I would worry about an approach where the new managers weren’t sold on the notion of such practices being in service of enabling them to be more effective leaders. Otherwise, I do feel it’s a much better approach than simply removing managers from the majority of team meetings. Google being a place that believes in continuous improvement and the book being from 2015, I suspect Google has since figured it out. The concern is people are still reading the book and looking for a quick and simple answer may take it too literally.

Along with many other modern approaches to leadership that have long put the notion of leading through fear behind them. An effective, trusted leader is better able to provide guidance and coaching to her/his team if they can observe them in action. I’ve sadly heard of interactions that include bullying, demeaning and disrespecting fellow team members in meetings where no leader is present. Certainly, one objective of a leader should be to make themselves redundant and create atmospheres where “supervision” isn’t necessary, but without any guidance or coaching, and a good dose of distrust, good cultures can erode…

Going back to the original Agile Manifesto, we are reminded that Agile was intended to solve for individuals and interactions over process and tools. No where is there mention of having distrust in managers…

The Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”​
© 2001-2019 Agile Manifesto Authors​
This declaration may be freely copied in any form, but only in its entirety through this notice.​

P.S. Another point that was raised in the training and by coaches trained in this style of scrum was that individuals should never change teams. I said that I understood frequent changes could disrupt the flow of a team, but why the notion of “never?” The answer was clearly stated that too often upper management sees effective teams and decides to break them up to spread these effective employees around. I asked if his point was that employees shouldn’t be treated like chess pieces. I agreed and asked what if after a year on a team, an employee mentioned she/he would be very motivated to another team… Should we hold them back? His answer was “of course not!” I asked if he realized that his disciples hearing him preach about never moving employees between teams have fervently fought against letting employees change teams in such cases because the edit had been stated in no uncertain terms. He said he didn’t realize things were being taken so literally.

Luckily, so far every place I’ve been that turn to the dark side and took these principles on too literally as dogma and demonizing employees eventually came around and recognized the possibility of managers being contributing leaders.

Hence, I’ve always been an advocate of being clear what you’re ultimately solving for and letting that supersede any strict adherence to dogma or rules. I long ago arrived at the notion that the only thing you should be religious about when it comes to Agile is to not be religious about anything 😉

5 Flavors of Agile at the Lean Startup

At IMVU (aka The Lean Startup) there was a point where I was managing 5 different teams that were each implementing their own tweaked versions of Agile. Each team ended up with a form of agile that didn’t come straight/religiously from a book, paper or blog-post, but rather from what best suited them and their particular situation.

  • We had a team that was heavily laden with handling interrupts, and they needed to find a way to plan their sprints to incorporate significant unforeseen work and to frame the tasks/stories around interrupts in a user-centric ways with measurable impacts.
  • We had a mobile team that needed to take into consideration that between release to Apple and actual availability to customers could take three weeks – so, we needed to implement more change-control and triaging of changes and heavier testing at the end (very different fro IMVU’s typical push-often, learn-fast, fail-fast approach to web-based releases).
  • We had a team that was collaborating with Pivotal Labs doing their flavor of extreme agile with extreme pairing (that exposed some challenges in a team that wasn’t composed of T-shaped engineers).
  • We had a green-field team working on a new system in a new architecture where story-pointing was very difficult, and they arrived at a form of Kan Ban that worked for them.
  • We had a team that mostly worked in typical scrum-agile manner with tweaks to account for IMVU’s approach of pushing changes to production every 10 minutes, including multi-variant experiments and matching hypotheses. It did, as I recall, include a remote worker that also led to some adaptations to the more traditional scrum-agile.


The Path to Enlightment
From a key-note talk I gave about how to introduce Lean Startup Principles into existing organizations. The one thing to be religious about when it comes to agile is to not be religious about anything.

See Also:

If you’re interested in my perspectives on leadership independent of whether it’s within an Agile organization or not, see:

One thought on “The Dark Side of Agile

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.