Carl Bruiners Agile / IT Development Consultant

Will Agile kill itself by being too efficient at highlighting failure?

Over the last few years it has become very popular (almost trend setting) to say that your business uses Agile.

As I mentioned in a previous blog 07/08/10 this normal means that Agile methodologies have been poorly implemented, which is worrying enough, but another concern I have is that Agile methodologies (SCRUM, XP, Lean, etc...) may end up killing themselves by being too transparent.

One of the things that attracted me to working within Agile frameworks was that transparency is greatly increased. This transparency normally ends up highlighting an individual’s failure to produce 'stuff' for the team (though as a true SCRUMMER, I don't like highlighting individual failure outside of those who really need to know, I don't like blame cultures).

As most of my implementations of Agile methodologies start within IT departments, I will give you an example surrounding IT;

Example - Implementing SCRUM
Most businesses like the idea of SCRUM as they feel that this is a way to 'regain' control of either rogue IT departments or inefficient IT departments. If the IT team isn't used to working within an Agile environment, as a SCRUM master, you may encounter a number of problems that helps the business owners justify (initially) the move over to SCRUM (lack of staff buyin within IT, failure to meet initial SPRINT deadlines, poor performing staff highlighted, etc...). Once your over the initial hurdles of implementing SCRUM and the IT department are working with SCRUM I have found that most of the failings originate from the business.

There are loads of articles out there highlighting issues with Product Managers and Stakeholders (note: I've deliberately left off Product Owners), so I won't cover that ground again.

My concern is that whilst Agile brings the business lots of benefits, that ultimiately businesses will end up dropping Agile methodologies because it will become unpopular as it begins to highlight failings within the business (and normally business process / controls).

Case: A commercial director who's company has just implemented SCRUM
The commercial director cannot stop bragging how the company had implemented SCRUM within IT development successfully. Three months later the same commercial director asks the board to review and ultimately replace the development methodology.

The reason for his change of heart was that every day he would walk into the IT department and ask for ad-hoc work to be done (normally with no requirements or specification and by passing the Product Manager / Product Owner), when this caused disruption to the current SPRINTS and the additional non specified work was not completed he would complain to the head of IT insisting that SCRUM was not very Agile.
Two weeks later the Commercial director attended a board meeting were it was highlighted that the failure of the IT developers to deliver for 2 out of 5 SPRINTS was down to the commercial directors interference with the developers work efforts. After the board meeting the commercial director started to place doubt into other stakeholders / senior managers about the benefits of SCRUM / Agile and that the business should look towards more established methodologies (i.e. waterfall) to get the work done.

The example above is something I have encountered myself, and as a SCRUM Master this is something that I have had to fight with the business about when there is doubt amongst senior staff who can influence what methodologies are implemented within a business. So far I have been successful in stopping the changing tide (hence creating Hybrids to demonstrate flexibility and to appease the doubters), but this is something that I feel coupled with poor Agile implementations is going to ultimately kill Agile.