Is it crazy to try agile outside software development?

This post was inspired by an article I read in preparation for last week’s newsletter about Getting Things Done (GTD). In it, the author argues that GTD and other similar productivity methods are merely treating symptoms. They are aimed at helping us deal with the hectic, fragmented work of today, particularly in the roles that have many interfaces like project leaders or product owners.

While they do work quite well as a band-aid – I can certainly attest to that – they do not help in fixing the underlying problem, the manner of how work is conducted within a modern knowledge worker company. In the end the author proposes – amongst other things – to steal from the world of Software development and try to use the agile methods and principles for knowledge workers.

Essentially, he is advocating for being pragmatic and adapting those methods and principles to our needs. If that isn’t right down my alleyway, I don’t know what is.

Email address:

Leave this field empty if you're human:

Trying out elements of agile in non-software development with a set-up that is not according to the book might be controversial. I know a few agile evangelists (some who may be reading this right now) with whom I have discussed this in the past. Some will tell you that agile only works if you do it fully, only if you are able to conduct cross functional end to end product development. They might also argue that scrum doesn’t work if not all roles are actually present.

On the other end of the spectrum, agile skeptics will tell you that agile only works in very specific circumstances. I personally have had the pleasure of introducing agile principles to teams that didn’t know it before. Let me tell you, there were times where it was not fun. Humans don’t like change. 

To be clear, I agree with both, to an extent. I think agile methods work best when you are working end to end on a product with a cross-functional team. I also agree that in an ideal world you should have all roles in scrum. Unfortunately, we don’t live in an ideal world.

Also, not all aspects are fully adaptable to each and every circumstance. However, I would argue that you will always find some aspect of agile methods or thinking that help in some part of your day to day work as a knowledge worker.

It works because agile is in the end about values that – I believe – can help regardless of what you are working on. In my experience three things stand out when attempting to use agile methods in non-software development.

• Standups foster communication
• Boards enhance transparency
• Rapid feedback loops ensure that we are on track

Let’s talk about these one by one.

By simply introducing a regular stand-up, you can foster communication, help with finding solutions, and building a team. It’s all about knowing what is going on in your colleague’s work (and private life), what their struggles are, and how you can help one another, particularly in today’s remote world. 

At one point, I was in a team of project leaders who were all tasked with leading strategically important but otherwise unrelated projects. We had a standup twice a week to share what was going on. It was great to understand what was happening within the other projects. It also helped us find solutions, since we were sometimes dealing with the same people or similar problems. 

In remote work these stand-ups are increasingly important for team building. A portion of them can be used to talk about things apart from work. That is where you build relationships, where teams are strengthened. Back then, we were working in person and didn’t need the standup as much for that purpose. We were mostly in the same office, we would often grab a coffee, or go to lunch together. For many, this is no longer today’s reality.   

One of the most important principles within agile development is making the work visible, e.g. by using a board. This is so crucial because, at the very least, it enables you to identify bottlenecks or blockers and allows you to react. It helps to explain to stakeholders why certain things cannot be done right now (It also helps in the discussion with superiors when you are discussing the need to hire additional people, but let’s keep that a secret for now).

I once worked with a mechanical design team to help them structure their work packages. In the end we created a Kanban board to visualize all the projects they were working on (e.g. CAD design for housing or FEM simulation worm gear). For sure, we weren’t able to iterate as quickly as within software development since the steps take so much longer. For instance, building the die for casting some parts took 10 months, by itself. 

However, the transparency still provided some great benefits. We were quickly able to identify one team member who was overloaded since the component he was working on was used in many projects all with custom adaptations for each. 

We were then able to shift some of his other responsibilities to the other team members. This might seem trivial but without seeing all the post-it notes (yes, physical boards still exist) under his name, the exact amount of things he had to do wouldn’t have been known. 

Also, we were able to identify some major impediments much quicker than before, simply because some cards were not moving on the board. We were able to react (mostly) before the issues became too serious.

In agile product development you want to develop a working product as fast as possible and then iterate design and functions based on frequent customer feedback. The goal is to ensure that you are moving in the right direction within each iteration and to be able to react quickly in case you are not. This is also valuable in other walks of life.

In spring of 2017, I was the Scrum Master for a cross functional team tasked with the goal of developing a platform concept for rear axle steering within 3 months. We were building on work done by other teams who were already pretty far in developing solutions for specific customers.

The scrum based approach with bi-weekly sprints allowed us to react very quickly to changes within the various customer projects, all of whom were very dynamic. It also turned out to be pretty useful for us in terms of communication with management.

Since the project was strategically important, we invited senior leaders to our reviews. Presenting the progress every two weeks meant that we got their feedback, were able to react, and also help in calming anxiety because we showed we were on the right track. 

How could I write a post about adapting agile to other domains without once mentioning the term cargo cult? Whenever you are adapting agile methods to some other field, you should do this mindfully. Don’t just do it for the sake of doing it or because others seem to be transitioning. This happens far too often and it only leads to frustration on all sides.

Really think about the problem you are trying to solve and the goal you are trying to achieve. Then decide on what to use. After deciding on a course of action, a method to use, communicate it. And then communicate it and the reasons for it again. You will likely have a good portion of the team members skeptical of the new approach. In my experience consistent communication is key to getting the buy in. 

To summarize, agile methods are most effective if done in a working environment where a cross functional team can iterate rapidly on a product. However, the principles behind them, are in my view almost universal. Thus, elements can and should be used in other domains aside from software development.