It's not about being Agile, it's about implementing practices that provide flexibility

I have posted before about what is Agile Methodology,Â but in this post I will discuss some ofÂ the most common side effects and failures experienced when the Agile Methodology has been completely mis-implemented in the enterprise .

Many organisations are considering adopting and transforming their software development teams to Agile units, all swayed by stories of how other organisations have been able to respond faster to changing market conditions by delivering higher quality software and improving their competitive edge.

Yes! Agile has gone mainstream, but is it really successful?

During the course of my career, I have seen many hype trains rumble through town. Some leave their mark, very few leaving the desired effects.Â Agile is definitely displaying all the hallmarks, exhibited by previous hype trains.Â Including cottage industries sprouting up, like fungi germinating from the decaying tree trunks.

There are a plethora of Agile Experts, Coaches, consultancies, tools and platforms not to mention the many new frameworks and methodologies that ensure successful implementation of the agile methodology.

Sadly, as with most things that go undergo mass adoption, it all starts to lose its shine, mis-implemented, misunderstood and finally diluted beyond all recognition.

Since 2012 / 2013, a number of thought leaders in the software development industry have been mooting the idea that Agile is dead. In short, Agile is no longer the trendy new kid on the block,Â but it is now the misunderstood teenager.

I personally don't consider myself to be a member of any of the project management cults, i.e. I wouldn't call myself an Agilist, Waterfallist, PRINCE-ist , Kanbanist, Leanist or whatever . I'm more of a "Get sh*t done" guy.

In reality I don't think any of these frameworks or methodologies help to get sh*t done, they just seem to add further complication to getting sh*t done.

I've lost count of the number of organisations I have worked for over the years,Â when at the start of the engagement they always produce some sort of declaration of what type of organisation they are. i.e "We're an Agile organisation", or "We follow SCRUM" , or "Our methodology is based on PRINCE2" or ever more seldom these days "We're traditional and we're very much a Waterfall driven".

The reality is, as the weeks or days go by, most organisations tend to display exactly the same set of characteristics without fail.

Rabbits in the headlights

The vast majority of projects are run by simply following the "rabbits in the headlights" approach.Â They can see the project coming towards them, it's going to make impact, in all likelihood there are going to be casualties, it's going to be messy and probability of success is between 10 - 15% .

The intervening stages are littered with meetings and gatherings of people in rooms trying to make some sense of it all, generatingÂ documents. Â This all coincides with attemtpting to deliver a software product.

Delivering on time

The irony that one project success criteria is defined by successfully hitting a time window, based on complete guesses.Â We try kid ourselves that these guesses are based on either on experience or some data gathered from a similar type of project with a team based on a similar type of skill-set.

This inevitably consists of placing a yardstick out at anywhere between 6 - 18 months, and then calculating how many 2-4 week timescales are within that period of time, we'll now call them iterations or sprints.

During these iterations organisations attempt to cram as much business functionality as possible in the hope of an ever increasing burn down rate and a team with an ever increasing velocity.

Burn down Chart

If you haven't watched Silicon ValleyÂ I can only recommend it. It would be really funny if only it wasn't so close to reality!

Chinese Whispers

I can't tell you how many project meetingsÂ I've been involved in that have gone under guise of "Catch Up meetings".Â Essentially these are spaced anywhere between every 2 - 4 weeks during a project lifecycle, and generally involve various people from the different disciplines on the project team.

Apparently these meetings are arranged so all can get an update on the projects progress. The theory behind these meetings is sound, but in practice what happens is that it all starts turning into a web of false promises and action items.

The end results are a load of Chinese whispers end up circulating. Often the result ofÂ good intentions poorly executed. Tribes within teams form, and it all turns into an us against them vendetta.

If your organisation needs to have a Project catch up meeting, then it's a sure sign that there is a smell within your project communication channels. Often this is a symptom of too many tools not enough synchronization.

For instance, your development team is using, Team Foundation server (TFS) to store development tasks,Â your Quality Assurance have ventured out and brought HP Application Life-cycle Management (HP ALM) ( a.k.a Quality Center), Business analysts have decided that JIRA or DoorsÂ and your Project Management Office have decided that Sharepoint is a great place to store Spreadsheets, Project plans, Documents and Power Points.

The problem here is that nobody actually knows how it all relates, because in all the management wisdom, we've split the departments up due to an efficiency drive project that was executed at a previous point in time, forming Silos of work!

Each department, creating their own processes and practices forÂ communication on a "project level" . The issue is that when the need for inter deprtmental communication arises, things Â don't work so well.

In order for a project to have a good chance of success,Â its necessary for all communication to be clear on concise, with minimal interferrence or chance of miscommunication.

Snot and tears

I have been in organisations where the conventional wisdom is that it would be a great idea for all departments to use one common system.

The problem with this approach, is that each tool has it's own strength and weaknesses and unique features. However much hype each of the vendors attribute to their individual products or platforms the sad reality is they don't cater for each need or desire adequately.

It always ends up with a square pegs and round holes, and from my experience a lot of snot and tears from all stakeholders.

Synchronization is key

One of the best approaches is to ensure all crucial data is synchronised between whichever tools are chosen,Â by leveraging a tool like Tasktop Sync or ConnectALL to synchronize all the relevant data required by all the management applications.

20/20 foresight

To build a good software solution, we need a clear vision and shared purpose of what success looks like. This unfortunately is alot easier said than done, primarily because different stakeholders often have different ideas of success.

All to often, software projects are broken up into smaller units of work across multiple "vendors", each vendor will have it's own definition of success, these usually have nothing to do with users actually using the software, but will have more to do with fulfilling terms of contracts and getting paid on time.

All to often, the primary definitions of success for a lot of projects, are defined as either ;

NOT to end up in court with the Vendor
NOT to end up in court with the Customer

If project teams safely navigate this first hurdle on managing expectations, it's essential that they actually establish well understood high level goals, and not focus on the detail of how they will achieve those goals. There is a natural tendency for project teams to fill a project backlog with tasks and trying to provide time estimates to ensure they sync up linearly with the delivery date.

The organisation is broken

For any methodology to be successful, it requires the full support of the organisation as a whole. Whether that organisation be a small software development team or a large multi national company. The entire organisation needs to be committed to the adoption and implementation of any framework.

Sadly, this is not the case for theÂ majority ofÂ situations, Â they proclaim Â "We're Agile BUT....." or "We're PRINCE2 BUT......" .

There is always a reason why they haven't taken on the full methodology, this is partly due to the fact that most methodologies state in the opening chapters of their text-book,Â that it is not always necessary to implement the full methodology to be successful, and that most organisations can be successful by selecting parts of the process to suit them.

Unfortunately, what predominantly happens is most organisations pick some good and easy parts of the new methodology to implement and attempt to mix them in with the really bad parts of their existing approach.

Agile In Name Only

The reality is that most ogranisations are never truly agile, but Agile In Name Only (AINO), Â at best most of them work in Iterative Waterfalls with daily stand ups.

Truly Agile organisations are developed from the ground up to be lean. Resources constrained and the whole attitude and cultureÂ within the organisation focused on truly doing more with less.

Work was carried out in truly agile and lean practices , not by choice but rather because it was the only way.

It’s not about being Agile, it’s about implementing practices that provide flexibility