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…

• Google’s Project Oxygen – where they sought to understand the value of managers in engineering teams,
• Liz Wiseman’s notion of leaders that are Multipliers as described in her book MultiplierHow the Best Leaders Make Everyone Smarters,
• The notion of Servant Leadership as described by Ken Blanchard,
• Simon Sinek’s Leaders Eat Last – Why Some Teams Pull Together and Others Don’t,
• Hard core Navy Seals who put their teams first as described by Jocko Willink and Leif Babin in their book The Dichotomy of Leadership – Balancing the Challenges of Extreme Ownership to Lead and Win
• Bill Campbell thoughts on leadership as described by Eric Schmidt in Trillion Dollar Coach – The Leadership Playbook of Silicon Valley’s Bill Campbell
• Brené Brown’s Dare to Lead – Brave Work. Tough Conversations, Whole Hearts

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.

CD

See Also:

• Good Agile: The Manager and Scrum
  In discussing the notion of the manager as scrum master states: “The pre-existing patterns of “order-giver” and “order-follower” are very difficult to break, and what’s likely to happen instead is that command-and-control will be transplanted into the heart of the Scrum practices.” This assumes a starting place of command-and-control and giving and taking orders. It suggests avoiding the issues rather than addressing them because addressing them would be difficult. If the Navy Seals and the US Marine Corps can move from purely command and control to leaders that eat last and discover the result are much more effective teams, then perhaps businesses should consider that approach as well.
  .
• GitPrime: How Agile Changes the Role of the Engineering Manager
  Speaks to getting out of micromanaging, focusing on the big picture, removing impediments, collaborate with Product Managers and develop a roadmap.
  .
• GSA Tech: Traditional Management Skills and Functions in an Agile Organization
  Addresses shifting from thinking tactical to strategic
  .
• TechWell: The Manager’s Role on a Self-Organizing Agile Team
  Suggests shifting management from relying more on command to relying on influence
  .
• McKinsey: The Agile Manager
  Suggests the traditional mid-level manager is reallocated to three different roles: the chapter leader, the tribe leader, and the squad leader.
  .
• Atlassian: Development Managers vs. Scrum Masters
  Describes the development manager still involved in the process and meetings, but suggests things like: “The development manager adds value by asking questions and vetting assumptions made in the estimation exercise.”
  .
• Matrix: How to Be a Manager in an Agile Organization
  Suggests: “Managers are no longer managers; they are leaders of leaders.It may seem like semantics, but there is a huge difference between a manager and a leader.”
  .
• Solutions IQ: What Makes an Effective Agile Manager?
  Suggests: “Effective Agile managers are critical to successful Agile transformation and thus business agility” and “Today’s Companies Need Leaders, Not Managers.”
  .
• Barry Overeem: Characteristics of a Great Agile Manager
  Iterates through a list of characteristics that make for a “Great Agile Manager.”
  .
• Agile Alliance: Agile Q&A: Is There a Place for Managers in an Agile Organization?
  Suggests: “If you became a development manager because you are genuinely interested in helping people improve their skills and would rather do that than write code, the move to Agile provides you an excellent opportunity to do exactly what you wanted to do when you became a development manager – develop your team.”
  .
• SAFe: The Evolving Role of Managers in Lean-Agile Development
  Suggests: Managers assist with career development, lead change, manage up and across coach agile teams, builds teams and define the mission and vision.
  .
• Laszlo Bock: Work Rules! Insights from Inside Google That Will Transform How You Live and Lead
  .
• The Economist: The Human Element: Using Technology to Drive a Culture of Innovation

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