Be Truly Nimble Instead of Just Following Agile by the Book


People often ask, “Can we apply agile to fields outside of software?” In this article from Marco Peredo-Saavedra, you can read how a construction project applied agile to its work with Marco as the product owner/customer. Take inspiration, and read his lessons. Then, go apply them!

Working at Jalasoft, a software company with near to 500 employees based in Cochabamba, Bolivia, we employees are aware of agile practices, applying them regularly in our daily software-development endeavors. In 2010, the opportunity arose to move into a new building that was being erected exclusively for us, and an extremely interesting challenge also emerged.

Our country has a rather weak infrastructure as far as technology is concerned, and, the truth is, we do not have local regulations or standards for many extremely basic construction issues involving technology. But, because we adhere to agile principles and “value individuals and interactions over processes and tools,” we had to guarantee a flawless electric power infrastructure. We couldn’t afford to be affected by (accidental) blackouts or similar events that could potentially prevent us from being online. It was therefore imperative to enforce our own high-quality standards while working with a team of very skilled electricians who were manual workers with weak theoretical backgrounds. These were technicians who were not really into following standards or regulations by the book.

Because of my credentials (Master of Computer Science and a degree in Electronic Engineering), I was appointed to lead the team of electricians. In a software company, the training of the engineers focuses, of course, in Computer Science, with almost no regard for the electrical aspects. Even though power installations are not my true field of expertise, I am much more familiar with electrical problems than my colleagues, and I was therefore deemed an apt counterpart who could lead the team of electricians while taking care of the true interests of our company.

In this situation, I deeply needed some agility, even though I was not able to find any reliable reference to an agile framework far removed from the software context.

The thirty electricians were distributed among five “crews” of six in such a way as to guarantee that each group had a leading figure and its fair share of people who seemed more likely to become high performers. They were all briefed on the following: the concepts of achievement or failure as a team and not as individuals; the need to deliver every two weeks whatever the company might define as a “deliverable;” to place a special emphasis on punctuality; and of the unavoidable need of having daily short coordination meetings and much longer self-evaluation and planning meetings every other week. But no mention was ever made of words such as Scrum, sprint, backlog, user stories, or even retrospectives, in order to avoid intimidating people who were totally unaware of agile techniques and its terminology and who, on top of that, do not speak any English.

The complete backlog was distributed among the five crews in the form of a long list of user stories, and the benefits of self-organization became apparent after I asked each crew member to identify all individual tasks and define priorities in such a way as to deliver a properly powered circuit every two weeks. In order for the delivery to happen, a working circuit had to pass a technical inspection that follows international standards. It was clear that a partial progress, no matter how carefully implemented, was not a deliverable if these criteria were not met.

After making the necessary changes for working with hardware rather than software, the principles in the Agile Manifesto were adopted and implemented by the team of electricians.

The highest priority for the entire group of electricians was to satisfy the customer—namely, our own software company—through early and continuous delivery of valuable power cabling. And, we knew that we would have some changes in requirements happening late during the installation process. The experiment in agility gave us the means to properly manage and control unexpected and unplanned changes occurring beyond the original building plans, after actually moving personnel into a completely new building. We did this by having the electricians deliver small (no matter how small) but properly powered working areas every two weeks. To facilitate these deliveries, and to make sure we had one point of contact, the business people and upper management at the software company were to interact on a daily basis with the crews of electricians through the duly appointed “interface” (me).

User Comments

1 comment
Keith Collyer's picture

The first time I came across an alternative to waterfall was in Tom Gilb's book "Principles of Software Engineering Management". His evolutionary approach pre-dates the agile manifesto and has many features in common (the book was published in 1988, thirteen years before the manifesto). Interestingly, many of the examples he uses are not software.

So, can you use agile in non-software fields? Thirty years of evolutionary development back up this article in giving an emphatic yes

April 22, 2016 - 6:01am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.