6 Questions That Tell You Are an AITO (Agile in Title Only) Company.

This is the second post in our Agile Development blog series.

Agile get its users from idea to revenue as fast as possible.

You run a tech organization and you’re “agile”. Your team has daily standups. You’ve got scrum boards everywhere
and can talk about epics, sprints, burndown charts, retrospectives, and planning poker until the cows come home.

But for some reason, your team is missing deadlines. When delivery does happen, it’s inconsistent. All-nighters are
a regular occurrence, and the stress level in the team reflects that. Reworking features immediately after delivery
is habitual at this point, so time spent on new development is far less than you (and your boss and/or investors)
are happy with.

You aren’t agile. You’ve got yourself an AITO (Agile In Title Only) company and you’ve got a problem.

Today, every tech company and new startup is agile. Or so it seems. The concept of being agile is so accepted today that
you might think it is a requirement to do business today. (It isn’t.)

The 2016 State of Agile report found that while 94% of respondents claimed to be doing agile, over 60% of teams within
their organization were not practicing it.

That gap in adoption is extremely telling. While a decisive majority of companies say, “We’re Agile!”, a majority of
those same companies are either having difficulty fully implementing it or they do not truly understand what agile is.
Either scenario results in the extreme example outlined above.

Let’s briefly discuss what agile is not before we dive into how to figure out if your company is AITO.

What agile is not

If you want to learn more about what agile is, we wrote about it here.

Here is what agile is not:
*Sprint planning
*Daily stand-ups
*Sprint reviews
*Sprint retrospectives
*Burndown charts
*Scrum/Kanban boards
*Product backlogs and more…

These are all elements of agile, or more appropriately, ceremonies, but that is all they are. If the ceremonies aren’t
driving you and your team into action that is a major indicator that your organization is AITO.

Are you AITO?

Is the hair on the back of your neck beginning to stand up? Grab your life jackets ‘cause we’re heading for the
deep water. If you’re beginning to wonder if you are AITO, below are some questions to ask yourself:

Do we regularly wait until the entire app/system is complete before releasing?

Allow us to be blunt – if this is true at your organization you are directly opposed to the very nature of agile.

Below are a few of the 12 principles of the Agile Manifesto:

*Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
*Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
*Working software is the primary measure of progress

See the inherent tension here? If you wait until everything is complete:

*Your highest priority is not continuous delivery of valuable software. It’s likely making sure the app is perfect before anyone sees it (but long after they actually want it).
*You don’t have a release schedule if you only release once, after everything has been built. Your client is left with weeks (months?) of wondering when they will be able to see progress of any kind.
*Lastly, if you claim to be agile but don’t release to real users until everything has been built how can you measure your progress on the project? More importantly how do you know that what you are building is what people want?

If this is how you build software, you aren’t agile. You’re probably doing this.

Am I regularly delivering value to my clients?

This is more than just talking through epics and user stories. This is real collaboration with your clients, giving them
an open door to give input and collaborate on the project. After all, it was their idea.

Also, are you producing new features or product iterations with regularity to your client? This is crucial to getting
feedback to improve the product moving forward and to properly meet expectations. If you’re doing scrum, decide on an
appropriate sprint length and stick to it. If your client is super involved and wants to new iterations and features
quickly, go with a continuous delivery model.

Lastly, are these new features and iterations valuable or are they window dressing just to say that you delivered something?
It better be the former. If it isn’t, then your client is probably on their way to disappointment city – if they aren’t
there already.

Are we outlining all requirements at the start of a project?

We have yet to see a complex project where either, all of the software requirements are known at the beginning, or have
stayed the same throughout the life of the project.

The beginning of a project is the point of maximum ignorance, remember? There is no way you can know or anticipate the
reaction real users will have at the start.

If you do this, you and your team are now committing to building something that people might want.
Who wants that level of uncertainty?

Do we ask vendors for, or give clients, fixed bid pricing?

Again, there is strain built in here. You can’t claim to be agile but offer/accept fixed bid pricing.

Why?

1. Agile embraces change. Fixed bid pricing says that you have a high degree of certainty about the software requirements,
   technology, timeline, number of people, and budget. At the beginning of a project you cannot possibly know all of those
   things with 100% certainty. (See above)
2. What happens when your client tells you you must add X,Y, and Z features? With a fixed bid project you’ve already defined
   the resources you have available. Adding more resources from your end will increase your costs. Client demand begins to
   outweigh your supply and the flow that your team has begins to break down.
3. The very nature of Agile (fast/continuous delivery, empowered teams, collaboration, transparency etc.) falls apart under
   the weight of fixed bid pricing.

Am I honest with both my team and my clients?

With agile, honestly and openness is expected. Your clients should have an open door into your development process
and to you.

Do we have a bias towards action? (see also: ‘What agile is not’ above)

Having ceremonies and artifacts like daily standups, retrospectives, burndown charts and scrum boards are great but what
are the outcomes?

If the answer ‘very little’ or ‘I don’t know’ then you’re missing it.

We cannot emphasize this enough. Agile is not about the behaviors (ceremonies) themselves but more about the actions those
behaviors create. Go ahead a tweet that.

A wise man once said, “The goal of pretty much every agile practice is to get you to talk with someone else.” If all of
your agile practices aren’t producing action, you’re simply going through the motions.

Conclusion
Many companies claim agile. Few companies actually live and breathe it. If you’ve read this and feel you fall into the
Agile in Title Only bucket don’t despair.

There are tons of great agile resources available to show you what agile can look like in your organization.
We’ve got a great infographic that you can download to get you started. Grab it below.