Agile is [not only] for IT

Agile is a concept that was born in 2001 as a combination of different practitioners’ ideas and solutions that were in place to improve the way software was being built. The “Agile Manifesto for software development” is the document that summarizes their agreements — if you don’t know this story yet, it happened in a Ski Resort in Utah, and more information can be found here.

Although it was made for software development, Rigby; Sutherland & Takeuchi (2016a) explain that Agile has its roots in Shewhart’s Plan-Do-Study-Act (PDSA) cycles, the Toyota Production System (TPS), the 1950s X-15 hypersonic jets development methods and a paper called “The New New Product Development Game” published at Harvard Business Review in mid-80s. which is worth reading [here]. To such a degree, it is clear that agile has its roots in industry and manufacturing.

Proving itself as an effective approach for software development, Agile has been lately used across different businesses in various industries, in the same way that the TPS and the PDSA cycle spread out during the last century. The table below summarizes some academic papers that describe cases of the use of Agile outside IT.

Further than being an approach for project and/or product development, agile became a tool for institutional change [Denning (2016)]. Striving to use an agile mindset, regardless if you are doing software development or just improving your administrative work, could be strongly beneficial because companies in which “agile flourishes find that teams can churn out innovations faster” [Rigby; Sutherland & Takeuchi (2016b)]

So, what characterizes an environment in which agile can become a strong ally? Unclear scope, frequent change, and complexity to start. And what do you need to implement it? Short development cycles and multiskilled self-organizing teams, at least. Take a snap at the most well-known agile framework, Scrum, which is illustrated below and described [here].

Now, do you believe the framework above, with many different ceremonies and feedback, could be applied to an operational activity in a river in the Brazilian Amazon rainforest?

Some years ago, I worked in the infrastructure and transportation sector, specifically in waterways projects and contracts. One common operation that you must perform in many rivers is called dredging. Oversimplifying, dredging is removing sediments from the bottom of the river to allow large ships to navigate across it. You normally have two main machines working on ships there. One measure the river draft (depth) to determine where you should remove sediments, and the other one will go there and — boom! — removes the sediments.

We had an issue with one river — Madeira River — because there was only one machine available to remove the sediments, and an initial scope, contracted after the measures of the draft were performed, would change a lot due to abnormal water streams that occur in the Madeira River.

The contractor would remove a lot of sediments, but new and critical areas would emerge and couldn’t be included due to the contracted scope, the ship would spend a lot of days moving to an area where the streams had naturally removed the sediments, and after all, ships would still have trouble to navigate in the river.

The solution was to use Scrum to manage the new contracts, as illustrated above. An initial scope would still be defined, but only highly critical areas would be fixed for the whole contract (product backlog) since there was no chance the stream would clear them.

Two-week work cycles would be used (sprint) to dredge the top critical area (sprint backlog), improving it for navigation (increment). Shortly after, the work performed would be evaluated by the contractor and the responsible engineer (sprint review), and the contractor would report how the work was conducted (sprint retrospective).

The measurements up and down the river were increased to determine the next area to be dredged (sprint planning), considering not only the draft but also the efficiency in that the dredging ship was moved across the river. A new two-week plan was defined to be started immediately after the last one (sprint backlog).

We couldn’t change the strong streams that were affecting the work, but we could change the way we approached the problem. Scrum helped us rethinking the way the contract was made and the work was managed.

No matter if you are working in IT or in any other industry. Agile, with its mindset and frameworks, can definitively make a difference in how you manage your work and deliver value to your stakeholders. For absolute beginners, read the agile manifesto [here]. Do you already know agile and/or Scrum and failed to implement it in your project or area? Don’t worry. Pretend it was the first sprint, run a retrospective to reflect on what could have gone better, and move to sprint two. And read Jeff Sutherland’s book Scrum: The Art of Doing Twice the Work in Half the Time here. Good luck!