Agile is not just for IT

Beware of the Myth: Agile is only for I.T. – 7 Steps to Embracing Agility

It’s a myth and we need to stop feeding it! 

“Agile won’t work for us because we’re not doing software development.”

Have you ever seen the 1986 comedy movie, “Little Shop of Horrors”? If you haven’t, we won’t give away too much of the plot but there is a weird plant in the movie that is constantly asking its owner, “Feed me, Seymour!”

Seymour obliges and the plant whom he affectionately names, “Audrey II”; continues to grow and grow after each feeding and becomes more demanding. Eventually, Audrey II wreaks havoc on Seymour’s life and Seymour realizes he must destroy his beloved plant to not only to save himself, but the world. 

Believing that agile is not only for Information Technology is like feeding that weird little plant, and perhaps we’re not saving the world by destroying the myth, but we could be saving your next project, the morale of your team or maybe your career!

Although it’s been over two decades since the publication of the Agile Manifesto, there is still a long-held belief that agile only applies to software development. It also doesn’t help that many agile certification programs reference software development as the standard when teaching agile concepts. 

While it’s true that in our modern times, we rely heavily on technology and the need for software developers continues to rise, agile can help streamline common activities for many different roles or types of work. 

Agility is best defined as the ability for a team or person to embrace change by preparing for the unexpected so that they can deliver quality “work” “faster”. 

Change can be anything from responding to a catastrophic event, customer needs or wants, market trends or even changes in how work is done (even software is developed differently than it was 20 years ago). 

“Work” can be anything from feeding Audrey II, planning a wedding, delivery of a marketing campaign to building a bridge. Wherever there is a need to deliver faster, better and adapt to change, “agile” can help. 

“…but nothing changes when you are building a bridge so agile won’t work!” 

Even while building bridges, the project can suffer from unexpected changes such as earthquakes, job site accidents or even a loss of funding. 

Let’s dispel the myth by learning about 7 steps that can be adopted for any type of work, team or individual. 

1. Teaming: Develop Team Working Agreements

Gather the team into session and create a set of working agreements which are a simple list of guidelines that your team will follow. This list of guidelines can include values, behaviors or rules that are meaningful to your team.


  • How often the team will meet
  • Any norms such as a promise to be honest and transparent at all times
  • Collaboration tools the team will use 

Skip this step if you are solo.

2. Create a Definition of Done (DoD)

What does it mean to be “done” with the “work”? Decide on what conditions must be met to consider something “Done” means and write this down (hint: add to your working agreement).

At minimum, establish a DoD for the task, but consider establishing one for larger chunks of work as well as the entire body of work.

3. Build the Backlog

A backlog is a list of anything that needs to be done. This list of things could be all the activities or items needed to ensure that “Audrey II” never asks to be fed again or the wedding is planned, the marketing campaign is a success or the bridge “complete”.

4. Define the Timebox

A timebox is a box of time which is alloted to finishing work. Choose when the timebox starts and ends and since it’s more effective to have a short timebox, the time frame could be minutes (i.e Pomodoro Technique) to weeks.

5. Establish the Plan for the Timebox

Consider which activities or items from the backlog  are the highest priority. 

There are many methods to prioritize a backlog such as Must Have, Should Have, Could Have, Will Not Have (MoSCoW) but for simplicity’s sake, imagine you only have until the end of your timebox to complete a set of items from the list and there will be no more time after. 

Which items would appear at the top of the list? From this prioritized list, create the plan for your timebox.

6. Go!

Start working on the plan! 

7. Pause and Reflect, Rinse and Repeat

At the end of your time box, reflect on what was done or not done. Think about the process itself. 

Does it need to be revisited? If so, enact and validate those changes and begin the next cycle of work and don’t forget to celebrate success (but please do forget to feed Audrey II).

Share this post

Ready to scale your business to new heights?

Get in touch today and one of our team members will be happy to discuss your requirements

Ready to level up your career?

Recent Posts

Add to Waitlist

If a course has an ‘add to waitlist’ button then it is likely booked up. Spots often become available so please fill out the form below. We will be in touch within 24hrs


Born 1965, San Antonio, Texas and lives in Dallas, Tx.
Mr. James, Ronald, Maverick holds a Bachelor of Science in Psychology at The University of Texas, San Antonio.

Mr. Maverick or JR as many call him is a “slick” but warm and friendly character in our upcoming book on the DevOps Mindset. Mr. Maverick cares about his IT team very much and could charm the socks off a Texas Longhorn. JR is liked by many in his organization; however, he is not as well trusted by the Overlords as he used to be. Mr. Maverick has a group of loyal staff, including Mr. Barker a bit of an opposite to JR. Of course, Mr. Barker would never call him JR; he would only call him Mr. Maverick because well, Mr. Maverick is his boss. Mr. Maverick has held many IT positions in the past, including starting as a Sales Professional for HP and IBM mini and mainframe computers. Over the years he has risen through the ranks to hold this senior position by delivering using high-paid consultants and Big name firms. He also received his promotion from outsourcing to a foreign country where he was able to reduce his IT spend significantly. Recently he has discovered (actually this was made painfully aware to him by the Overlords) that both the Offshore roadmap and use of external consultants was not giving him the value and velocity for his IT department, and he was probably paying more than he bargained for

So, after hearing a talk at a DevOps event by the Agents of Chaos, JR decided to enlist them to help with their digital transformation roadmap and help improve the value, focus and velocity of his department. However, MR. Maverick has a few ideas about agile and DevOps, something he has heard about for a while and read in various CIO magazines; he thinks of these as Marketing terms and something that can be bought. While Mr. Maverick has held on for many years to traditional IT ways of working he has come to the end of his tenure if he doesn’t do something fast and get DevOps working quickly as he has promised to the Overlords providing him with a little more rope to get the transformation completed more quickly as they view his IT department ageing, procrastinators who are not able to keep up with business demands. JR says in his mind, “I will get it done, they don’t call me Maverick for nothing!“