Cope with the IOT Revolution by Staying Agile As the smart building industry rapidly evolves, management strategies pioneered by software developers can help us successfully adapt.

Brad White, P.Eng, MASc Principal, SES Consulting Inc. Contributing Editor Christopher Naismith BASc, EIT, LEED GA Energy Efficiency Engineer SES Consulting Inc.

Our company has a problem. It’s a problem that I suspect a lot of young, small, and growing companies can relate to. Namely, we’re so focused on work for our clients that we find very little time to dedicate to improving how we do our work and how we run our company. This certainly isn’t from a lack of ideas; we have a large and growing backlog of great ideas for everything ranging from new training materials, project templates, business processes, tool updates, and deployment of new software tools. At any given time, we might be officially working on 10 different items with responsibility spread out across the company. However, this work inevitably takes a back seat to billable work, and so these projects languish on the sides of desks for months or even years. The time that does get spent is so infrequent and spread across so many different projects that the payoffs are few and far between. Meanwhile, many of our systems and tools, which worked great at five employees, are frustrating and inefficient for a company of 30.

These internal challenges have a lot in common with challenges that not only our company, but our industry as a whole, have been facing as a result of the enormous changes that our industry has been experiencing lately. The arrival of IOT and big data, in particular, is leading us down an interesting path where the users of the solutions we are deploying for our customers are further removed from our own experience. We don’t understand our users the way we used to, and this lack of understanding is likely one of the reasons that it has so far been difficult to realize all of the purported benefits of the big data and IOT revolutions in our industry.
What’s different about today’s user group? In the past, the users of technologies we were deploying were essentially ourselves. Integrators, controls contractors, building operators are all largely cut from the same cloth. But the rise of IOT, data analytics, and the trend toward democratization of controls has transformed the user group for smart building systems. The user interface is now going beyond the boiler room and showing up in the C-Suite and on the smartphones of every occupant. The challenges we’re increasingly tasked with addressing, like improving occupant productivity and comfort, are ones that we are further removed from our experience as solution providers. As a result, we can no longer take understanding the needs of our users for granted. Assuming that we know what people want and designing/building to that is a recipe for building the wrong thing. What we need then is a process for ensuring that we build the right thing. 

Fortunately, we can borrow solutions from software developers who have long had to grapple with this same problem and have developed frameworks to deal with it. One widely adopted approach in that industry is based on Agile Management. In the words of the Agile Manifesto:

While Agile does not prescribe a particular methodology, many frameworks have been developed that embrace Agile principles.  One popular example is Scrum, which is the one that we have chosen to adopt. This one minute video offers a succinct summary of the essentials of Scrum:

Key for our purposes, Scrum puts an emphasis on explicitly and formally including users in the development process through the collection of user stories to drive the development priorities. Scrum also offers processes for organizing a development team and for coping with the prioritization of a large backlog of items. With a framework in place, we could move forward with starting to tackle our development priorities.

The emerging development process at our company is centered around three distinct lists or backlogs. Each one represents a different level of the development process but ultimately follow the same principles.  It is owned by someone (or a group of someones), it is prioritized with the most important items at the top, and its elements can be estimated. 

The opportunity backlog represents all of the proposed development work at the company.   Anyone can add opportunities to the backlog at any time, while the responsibility of prioritizing these ideas falls to the newly minted role of Opportunity Owner.  By creating a single point of responsibility for organizing development work, we can ensure that our efforts are aligned with the best interests of the company.  It is essential in moving forward, that we ensure openness and trust are built around this role.

[an error occurred while processing this directive]Product ideas may be anything from internal processes to customer-facing tools, and each has a product backlog.  For example, our first development sprint focused on our company’s invoicing process, improving tools and redesigning the process to take some pressure off of our overworked bookkeeper. The product backlog captures all of the user stories that make up the idea.  By employing methods such as Story Mapping, and the 5-act interview we can pull out the needs of stakeholders, allowing the end users to contribute directly to the development process.  Each product has a Product Owner, who is in charge of ensuring that the most important things are built first.  This is usually the person who developed the vision for the idea in the first place.

Once we’ve committed to building something and know what it is that we are trying to build, it’s time to bring in the Development Team. In our case, we don’t have nearly enough resources for dedicated full-time developers. Instead, our Development Team is a small group of consulting engineers pulled from across the organization. The team creates a list of tasks based on the specifics of the user story in question. They are encouraged to operate autonomously in a collaborative environment with minimal distractions.  By focusing attention on a problem for short, but intense, ‘Development Sprints,' we can easily track progress, inspect frequently, and adapt as necessary to changing requirements. By keeping the sprints short, just three days out of a month, we can also manage to temporarily set aside the billable priorities of the team members so that they can focus exclusively on the problem at hand. After the sprint is completed, they go back to their regularly scheduled billable work until the next sprint comes along. 

Recently having completed our first development sprint, initial feedback from this process has been very positive.  Stakeholders feel that their specific needs are being heard, the development team is excited to be working collaboratively on challenging problems, and leaders have higher confidence in the valuable throughput.  Monthly check-ins on the process allow for continuous improvement based on user feedback, ensuring that any pains are worked out along the way. Crucially, from a business perspective, we’re not allocating any more resources or funds than we were previously using on improving tools and processes. But with clear priorities, dedicated team members, and a well-defined approach we intend this to be a much more effective use of these resources. In the IOT era, we are all developers now to some extent or another; it’s time to start acting like it.

For another perspective on how the software development culture is encroaching on our world, we highly recommend this month's article by Building Context's Therese Sullivan on DevOps "Will DevOps Culture Come to Smart Buildings?