Ministry of Technology
Show Menu

Pragmatism vs Compromise - A Difficult Distinction

Pragmatism vs Compromise - A Difficult Distinction

In recent years, the idea of pragmatism in the agile community has started to get a bit of a bad name for itself. I consider myself to be a Pragmatic Agilist and I am proud of that fact; I like to look beyond the fixed frameworks like Scrum and look at alternative methodologies for guidance in tools and processes that may better serve my clients.

There is a fine line between pragmatism and compromise. It is a common problem in agile implementations these days that too many compromises are made against the key principles of agile which prevent it from working effectively. It is, admittedly, easier to avoid this if you stick to the letter of a framework, such as Scrum, which gives you clear guidelines of what to do and what not to do (one of the reasons why a Scrum implementation is still a serious consideration for me when bringing a new client to agile to set a defined starting point). So, how can I be both pragmatic and avoid falling into compromise traps?

Question Change

No, this doesn't mean you suddenly need a massive change request process - what this means is, that as potential changes to processes come in you should question them against the 12 key agile principles to get a view as to whether these changes risk introducing a destabilising compromise (see below). If they don't then you should feel free to go ahead with the change and monitor it's results as normal. If the changes do risk compromising the agile principles then that doesn't have to rule the change out in it's entirety, but you should consider how to mitigate these risks before you implement the change and put in place additional measurements of success that capture the potential impact against agile ways of working.

Let's have a look at the key principles and how we can test a change against them (feel free to add your own suggestions to this simple check list)…

Early & Continuous Delivery

Positive things to look for...

  • Enables the first alpha version of the software to be delivered quicker
  • Enables integrated deployment
  • Pushes the automated deployment chain of the product further towards live

Warning signs...

  • Slows the time before the end users or clients get to experience the product
  • Makes automated deployments harder to do
  • Blocks controlled automated deployments through the environment chain

Embrace Change

Positive things to look for...

  • Allows the product roadmap to be altered with minimal impact
  • Decreases the time taken to change the product based on feedback
  • Makes further process or product change more rapid or reliable

Warning signs...

  • Reduces the flexibility of the product roadmap
  • Increases the time taken to react to change or block it entirely
  • Makes further process changes harder to implement

Deliver Frequently

Positive things to look for...

  • Reduces the cadence of the product delivery

Warning signs...

  • Increases the cadence of the product delivery

Daily Communications

Positive things to look for...

  • Increases the regularity of communications
  • Shorter, more effective communications
  • More direct communications

Warning signs...

  • Isolates the business and development parts of the project
  • Reduces the regularity of communications
  • Excludes people from communications

Empowerment

Positive things to look for...

  • Increases team involvement
  • Removes process blockers or dependencies
  • Gives the team more motivation or decision making power
  • Provides access to more resources or training
  • Flattens hierarchy

Warning signs...

  • Reduces team involvement
  • Introduces steps that prevent the team from going as far in the process alone
  • Additional levels of hierarchy
  • The team feels threatened by the change

Talk

Positive things to look for...

  • Highlights the importance of face to face communication

Warning signs...

  • Restricts or discourages face to face communication

Working Products

Positive things to look for...

  • Releasable, Working product is churned out quicker and more regularly
  • Defects in the releasable product will be reduced

Warning signs...

  • Defects in the releasable product will likely increase
  • Regularity of access to a releasable product is reduced

Sustainable Pace

Positive things to look for...

  • Highlights the importance of known working hours
  • Comfortable time planning

Warning signs...

  • Very tight deadline planning
  • Minimal allowance for change time
  • Likelihood of overtime

Excellence

Positive things to look for...

  • Highlights the importance of high quality product
  • Improves the rapidity and quality of testing
  • Refactoring regularly (in code)

Warning signs...

  • Ignores QA requirements
  • Reduction of quality to meet deadlines
  • Technical debt accrual

Simplicity

Positive things to look for...

  • Makes processes or the work environment more straightforward

Warning signs...

  • Makes processes or the work environment more complex

Self-Organisation

Positive things to look for...

  • Increases team control over product and process
  • Allows the team to handle more of the pipeline alone
  • Flattens hierarchy

Warning signs...

  • Reduces team control
  • The Team will have to get sign off from others
  • Additional levels of hierarchy

Inspect & Adapt

Positive things to look for...

  • Additional metrics to guide change
  • Better information on progress

Warning signs...

  • Reduction in regularity of the Retrospective

Managing Expectations

In a pragmatic approach it is essential to manage the expectations of change instigators, be they teams or management, in that while you will embrace change the overall balance of the processes is key and, should a change imbalance these processes it will have to be rethought. This is key to overcoming the 'but it's agile - that means we can do whatever we want, doesn't it?' mentality that pervades compromised implementations.

A willingness to review and potentially even trial changes that have the potential to be disruptive can be very powerful in terms of increasing buy in across an organisation where resistance to change may be high. The key element here is capturing data to show the success or failure of changes and their potential impact to highlight their value or cost to the business.

My Implementation is already compromised - What can I do?

All of my suggestions above can work well in a clean implementation, to prevent introduction of compromises, but recovering from a highly compromised implementation is a lot harder than keeping it on track in the first place. This is why I always recommend that an organisation looks to hire a permanent management level Agile Coach, post implementation, if they are not following a defined framework - The cost of ongoing prevention is significantly less than cure.

Despite this, all is not lost. If you are working in an agile organisation where the implementation feels compromised you just need to come at change from the opposite angle. As with managing expectations, management need to have their expectations raised that the current implementation is potentially compromised and changes will be needed to get it on track and enable the business to operate optimally. These changes should be carefully measured so that the success of the changes can be highlighted to management. This will increase the appetite and acceptance of further change.