Agile for people who don't care about software development

Posted on June 02, 2016

Agile used to be the big buzzword for software companies. At this point in the software world, if you're not using some flavor of agile development you may be looking for a new job soon.

But agile isn't just for software development, it's a mindset that can be applied to almost any industry, home remodel, or honey-do list. 

Where agile came from

In this context the word agile comes from the agile manifesto - a set of values written in 2001 at a skiing and development retreat in Utah by a small group of people in an attempt to come up with a lighter more iterative process for software development. 

The manifesto says,

“we value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”

From this manifesto several methodologies of agile were developed, a few of the popular ones are scrum, lean, and kanban. I'm sure you've heard at least one snarky developer toss the word scrum around like it means something to you or you would care. 

That word always sounded kind of gross to me anyway. 

This manifesto wasn't the first time these concepts were discussed. Thoughts and insight around incremental development trace back to something like the 1950's. 

There were I'm sure several studies that influenced the manifesto to be written like this one in 1998 where Harvard Business School academics Robert D. Austin and Richard L. Nolan did a study on large software projects. Their study, which questioned many of the fundamental ideas of IT development and project management, produced these key findings:

"The first flawed assumption is that it is possible to plan such a large project.
The second flawed assumption is that it is possible to protect against late changes.
The third flawed assumption is that it even makes sense to lock in big projects early."

I'm pretty sure any large or complex project can relate to the above flawed assumptions, not just software development. When has a gantt chart ever been right? When has any large project not had a change brought in midway through that sorta f'd the whole thing up? 

Agile is a mindset

I understand and deeply respect that there are very structured and specific methods of agile that are used in the software world and beyond. Things with rules, and charts, and stuff i'll never understand. Stuff that scares the hell out of me. 

But I firmly believe that you can make agile as simple or as complex as you want. Agile is a mindset, the idea that a team can work together with agility. 

The agile mindset is to build or do something that actually works, and both the person building it and the customer who owns it understands it and feels good about it. 

The agile mindset is realistic about the fact that change is going to happen, so deal with it, embrace it, plan for it instead of losing your shit every time the customer brings up a new idea or tweaks the original concept. 

Transparency and collaboration between client and members of the team is a value the agile mindset recognizes as important. This is why a physical board and index cards or sticky notes are often used to track progress. 

A physical board is a low tech tool that allows everyone to be involved regardless of technical skill level. The intimidation factor of sticky notes is very low. The board is often placed in a high traffic area allowing managers or other team members who are not on the project to quickly understand where the level of progress is. 

Super simple agile example

This is a kanban board from a team I am working with that is interested in including more feedback in their culture 

black board with sticky notes on it

Throughout the week the team adds a sticky note if there is something they want to get feedback from the rest of the team on, or if there was a particular event or meeting that they want to offer some feedback about. 

Once a week the team meets for 30 min to review the "event/topic" column of sticky notes that were added. At the beginning of the meeting we move 3-4 stickies to the "queued for discussion" column. As we give each other feedback about that topic we move the sticky to the "discussed" column.

And that's it. 

That's using an agile methodology to incorporate feedback into our culture. 

The benefits of using a kanban board

Using this physical board with simple sticky notes allows anyone from the team, even interns who do not have access to our intranet, to add a topic for discussion. 

By discussing only topics that are added to the board the team is empowered to create their own agenda. 

Keeping this board in our main lobby raises awareness to the rest of the division that we work within. We want people to know that we are interested in starting a culture where feedback is the norm. 

Using simple materials like masking tape, black mounting board, and sticky notes shows we are open to change. We have already renamed the columns twice to fit our needs better. 

To me this is what agile is - transparency, team collaboration, simplicity, and the ability to pivot with change. 

When to use an agile approach

It would be awesome if we all had official agile coaches and fully understood the methodologies and terminology that's being used in the industry, but I guarantee there are some real benefits to just starting with the limited knowledge you currently have. 

Just fake it until you find something that works for you.

For very large and complex projects having a little more training in one of the agile methodologies is advised. If the project is top secret or contains sensitive material, having a full understanding of the advantages and disadvantages would be helpful before using it with this type of work.

However, if you have a desire to get out of the silo, open up the conversation, be more inclusive, create a culture of innovation, and add transparency to a project, you should give it a try. 

If you want to use a board with index cards, an online solution like Trello, markers and a white board, it doesn't matter - just start somewhere.

Experiment and adapt as you go - before you know it you will be that annoying person tossing around terms like kanban as if anyone cares.