Agility is a Business Thing Too.

Question: Which of the following statements are true:

• We only use ten percent of our brains
• We lose most of our body heat through our heads
• If you swallow chewing gum, it will stay in your system for seven years.
• Cracking your knuckles will give you arthritis.

(the above links courtesy of Psychology Today) 

Answer: None of them. 

So why do we believe they're true?

My guess is that somewhere back in the fogs of time, there lived a very credible, plausible person who genuinely thought these were true due to misinterpretation of data, evidence or experiment or anecdote or false logic. That person told their friends or published articles with a wide readership and like any well scattered seeds, such ideas took root and grew and spread. Entire societies now think these statements are true!

Such statements that masquerade as facts yet are not facts are sometimes known as Factoids.

And there's quite a few factoids doing the rounds about what Agile is and what it isn't.

Agile is About Faster Software Development, Right?

This common misconception has its roots in at least one of the following:

• Unfamiliarity with the Twelve Principles of Agile
• Misinterpretation of the Twelve Principles of Agile
• Unconscious bias when reading the Twelve Principles of Agile i.e. paying attention to the bits that appeal/confirm one's world view and ignoring the other bits that challenge one's world view.
• Taking bad advice at face value
• Misconceptions within one's professional and social networks that could be widespread and deeply rooted that they feel like the truth. 'So many people can't be wrong, right?'

One of biggest misconceptions held by individuals and organisations is that Agile is something that only applies to developers. Agile is about more work being shoved through the pipeline. 

It's my personal view that the wording & emphasis of some Agile Principles haven't exactly helped.

Let's look at some of those principles for a minute: 

"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale"

and again here:

"Working software is the primary measure of progress"

Good principles of course but a lot of people who read them maybe bedazzled by the phrase 'working software' then they jump to the conclusion that Agile is just a thing for programmers.

But look at this principle below:

"Business people and developers must work together daily throughout the project"

This is probably the most revolutionary and important principle of them all. 

This principle is the well-spring and foundation of what makes Agile successful.

Within this principle, we see the walls that traditionally separate Business and IT departments being dismantled so that everyone regardless of profession or skillset, puts their shoulder to the same wheel of product vision, development and delivery.

So Agile Isn't Just a Programmer Thing? Really?

There's little point in having the fastest, the most talented development team in the world if it takes 6-12 months for a new story to appear on their product backlog from the day its initially thought off due to onerous, long-winded work intake processes

Agility applies to all stages of the lifecycle, from ideation to delivery and everything else in between.

Every step should be conducted as quickly and as efficiently as possible, with business, marketing, technology all working hand in glove at all stages working out the solution and delivering it.

All skillsets advising one another on what's possible, what's not, what's a better way, how about this idea, let's not do it that way etc. 

A world where UX or Architecture or Marketing don’t cocoon themselves for weeks or months and then present (or throw over the wall) a Document for developers/testers to work off only for a bundle of misconceptions to arise thus frustrating development and delivery.

Agile is from the A to the Zee : Ideation to Delivery

Sometimes, the onus of agility and expectation of speedy delivery is unfairly and wholly placed on the shoulders of the development team while those who work in the business/work-intake side of things, are being allowed to carry on at a leisurely pace like it was still 1978.

So much for speed to market. 

So much for being reactive to changing customer needs in these very fluid marketplace and society.

These days when the vast majority of software being used is customer facing and revenue generating, everyone involved from ideation to creation of software is The Business be you a marketing analyst, account executive, UX designer, coder, tester, product owner or scrum master or architect or whatever your role happens to be.

Handoffs - A Parent of Inefficiency

Handoffs are the mother/father of inefficiency.

The very concept has always been riddled with assumptions and indeed arrogance if we think about it. 

The mindset of a handoff can go something like this:

"I'm going to create a Visual Design for a whole new business flow. I don't need to consult with the developers or the product owner or the testers while I'm writing it. I know best and when I hand it over to the developers/testers, they will be able to code/test perfectly from my Visual Design without any questions because my work is so good. If anyone does raise questions, I become frustrated because I don't have time to answer them or attend their daily stand-ups because I'm too busy working on my next Visual Design"

But We Don’t Need to be Agile, We’re Doing Ok

An organisation that doesn't react to or fulfil its customer's expectations risks being severely & swiftly punished in the market place. Such an organisation would need to  swiftly change how it does things or face the possibility of decline and fall. As we have seen since 2008, no organisation is immortal or immune, no matter how big or old it is.

That said, some organisations are such financial juggernauts that they are well cushioned against the consequences of their products being developed in a less than agile fashion. 

Rich Firms vs Bad Apps

Several well known newspaper and magazine apps are notorious for having poor user-experience. 

Often, they are owned by publishing houses who make a lot of money from long-standing investments, advertisement revenue and sales of paper copy even though the latter is in long-term decline.

This means they feel they don’t need to be that Agile or customer-focussed for products such as their apps but in doing so, they're shoring up a lot of reputational debt.

This will surely come back to bite these companies in the not too distant future. Old world revenue streams may last a long time but online revenue streams are on the march. Just as it wasn't wise for a business to invest all its money in gas in 1920 while ignoring electricity, ignoring customer feedback or being slow to respond to customer feedback in the 21st century is just as inadvisable.

Such products may even not be the organisation's revenue lifeblood. 

They don’t make all that much revenue from their apps yet they still survive and prosper on the face of it.

They feel that they don't need to invest in performance or good UX etc. 

Their apps could even be buggy or lacking in good content yet the money rolls in.

Many people's first exposure to their titles are via the app. If the app gives a poor experience and if the company doesn't respond quickly or at all to customer feedback/low Net Promoter Scores, people will spread negative comments to their friends in real life and on social media. 

They will stop using the app. They would be put off buying the paper-copy version as they would assume if the app is poor, so must be everything else associated with the app and its makers.

So, in conclusion, Agility applies to all stages of a product's journey, involving everyone together. No handoffs, just pure constant collaboration and constant monitoring and responsiveness to customer usage data and feedback.