Shop Floor Agility Resistance

Agile software development can be an answer to over-prescriptive, over-documented and command & control style development. Agility is by no means anti-methodology, anti-documentation or anti-control. The idea is to restore balance and put people first.

In my experience most people think that, foremost, customers and management have to be convinced that adopting agile practices will lead to better, faster, cheaper and/or happier software development. And they also assume that transitioning to agile practices on the shop floor is a piece of cake. It is about more freedom, craftsmanship and collaboration, so who will object to that?

Well, in reality there are lots of reasons why analysts, developers, testers and people in roles alike object against agile. For example, there are people that object against teamwork because it threatens their knowledge based status.  Or what about team members that consistently refuse to update their tasks preventing them from having an up-to-date sprint burn chart. Another example is team members that just cannot focus on one of two user stories, always do work outside the scope of the sprint and never finish their tasks. Normal project or people management you say? What about team members that tell you that they do not have the required discipline nor are willing to try. Or what about staff who get violent when they are asked to move to another office space in order to create a co-located environment?

Examples of what I have seen (or done) during agile implementations, sometimes along with project recovery, are:

  • Closing down the email server for 3 days to get team members to talk to each other and find a common enemy
  • Remove people  from the project team
  • Claim two weeks of the project’s schedule dedicated to fixing process and tooling
  • Boring out people so that they start thinking about improving their way of working themselves (not again!)
  • Move to another office space in order to creating insecurity and thereby room to do something new
  • Create a new department for innovation, embrace enthusiasts and let the others do maintenance.
  • Find a (project) manager who excells in handpicking team members to create a winning team
  • Do a personality style workshop so that 'odd’ behavior of team members becomes normal (and funny)
  • Re-frame testing to validation thereby bypassing an uncooperative test department
  • Loan (or steal?) a server to create a test environment you are not supposed to have
  • Log the time people are on the phone and check the phone numbers to find out if this time is spent for the good of the project

Basically it comes down to conflict management and what can you do about it depends on 1) how much time you have to solve the problem, 2) the severity of the problem, 3) how much collateral damage is allowed and 4) who you are.

When you have no time and the problem is sort of trivial or relationships are important, then you might choose to ignore the problem and avoid any confrontation. When you have enough time and relationships must be preserved, then you can try to find a win-win situation or settle for a compromise and accept a less than ideal outcome.  When you have no time to lose and relationships do not outweigh the severity of the problem or are just not important enough, you can basically force whatever change necessary upon the team.

Parting thoughts. When you stumble upon a conflict that you think it is not smart or safe to handle yourself; asking a colleague or calling in outside help are more than valid options.