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).

We wanted to maintain that the team was highly motivation. For the electricians in all the crews, motivation came mainly from making everyone feel they were a very important part of a great project and by showing that they were getting a first-rate professional training, which would strengthen their background immensely. There were also some material incentives in the form of monthly bonuses for exceeding expectations as a team. We wanted to keep all the team members highly motivated and this played a key role in achieving a friendly working environment where people were ready to help each other toward achieving a common goal. Also, from the very beginning, we all adopted face-to-face conversation as the most efficient and effective method of conveying information. This proved to be an unsurpassed way of developing mutual trust.

The number of properly powered and working circuits was the primary measure of progress and, after just two or three iterations, everyone felt comfortable enough with the process, as to be able to go on maintaining a fairly constant pace. Moreover, the continuous attention to technical excellence and the adherence to a good previous design while being receptive to criticism helped create truly enhanced agility. The crews were constantly reminded, mainly by example, of the invaluable benefits of avoiding work done in vain or redundantly and, after setting the final goals, they were certainly left to self-organize themselves, but the working method never allowed them to work without feedback, which ensure d that all of the teams were on the proper track toward their goals.

Conclusion
Sixteen months (thirty-two iterations) after the challenge, the whole software company (about 350 employees at that time) moved into the new building. Following a traditional approach, a very experienced contractor had originally scheduled the power project over a two-year time span.

Jalasoft achieved a high-quality power installation and a far more stable power supply than in any other of the buildings where it had rented facilities over the previous years. The budget also showed an important reduction while the only impact on quality was to increase the likelihood of it being well-above average.

All in all, we proved to ourselves that the agile approach can be applied to hardware teams with no software experience, as long as the core principles are taken into account and no unnecessary emphasis or effort is put into the theoretical part of the methodology.

One can achieve true nimbleness by transcending the mere “agile-by-the-book” approach!