Why this reaction to such a common question? It’s “agile development” and “traditional development” colliding in classic fashion.
Renewables are rapidly changing the way utility business models work, and software tools need to keep pace. This change is happening at the organizational level, but is also driven by key use cases such as DER interconnection. Some utilities such as PG&E have already embraced agile software development organizationally to keep pace with market changes. Others are still deciding the best way to meet their software needs.
Agile versus waterfall: what works best for software development?
Agile software development can be difficult to embrace if a company is used to traditional development. It can be viewed as chaotic or lacking control, but that’s not the case. It’s just a different way of thinking that allows a team to react to fast changing requirements and deliver usable software throughout the process.
When I started building software 25 years ago, the process was seemingly straightforward. The team would talk about project goals and how we thought we could accomplish them. Ultimately, we came up with a schedule for the next 18-24 months with milestones leading to major checkpoints along the way—things like code complete, content complete, beta, zero bug release and finally the release date.
This is known as a waterfall schedule where upfront planning sets the requirements, the team designs to the requirements, the developers code to the design, it’s tested and then it’s released. Everything flowed down the system like a waterfall, and like a waterfall, it was hard to go back up. Simple, right?
Not exactly. Waterfall schedules in software inevitably broke down—usually within the first milestone.
The waterfall model came from manufacturing where physically building something meant everything needed to be well planned and designed before spending money to build it. Design changes could have drastic implications to cost and schedule delays. For manufacturing, it’s a good logical way to keep a project budget and schedule under control. When software came around it was natural to assume a waterfall model would be a good way to create software. As it turns out, not so much.
Building software can be a creative, iterative and incremental endeavor. And because software is not bound by the limits of the physical world in the way a bridge or substation or piece of hardware might be, most any feature is, in some sense, possible. With software, it’s just a matter of time and resources. Software has a level of flexibility that just doesn’t exist when building physical projects. You’re only limited by the imagination of the team and the time (i.e., money) to work on a problem.
Building software isn’t as simple as setting requirements, then scheduling implementation. Many times, you have an idea about how something should work, but as the feature develops, issues and challenges are discovered that you just couldn’t know before you started.
Quickly adapt to customer needs with agile software development
Just because it’s easy to change software doesn’t always mean you should. You still need to arrive at a goal and produce something useful. This is where the agile methodology of software development comes in. Unlike waterfall methods, agile allows teams to adapt to customer needs in an iterative fashion.
There are processes that prevent agile from just being chaotic: project vision is still set by the team, features are still designed, development time is still considered and testing is still a part of the process. However, as the name implies, assumptions are revisited often to allow flexibility and a recognition that it’s impossible to completely plan software features from the beginning. Instead of focusing on one release, agile allows developers to focus on quick releases and continuous improvements in the overall product.
One example that embodies this concept is our new Release Notes feature in PowerClerk. We quickly implemented and rolled out the feature to our team for evaluation. We got more valuable feedback from actually building and demoing it than we could have gotten from just a written specification. One key change that resulted from this approach was the addition of an Edited Date, as shown in the figures below.
In this first iteration, we realized users would not be able to tell if we edited notes after publishing them.
We added an edited date, but its placement broke up the title and body, making it difficult to read and suggesting that only the title was edited.
After another quick round of feedback, the edited date was moved to the right, improving readability.
This is a small example of how agile development allowed us to quickly improve the feature through fast feedback and seeing it directly in builds of the product.
When a new feature becomes available, it can have unforeseen results in terms of how a customer uses the software, and it can open up new ideas for how to use the product. That then leads to new directions for features that were not previously considered. Agile allows that kind of thinking and iteration without worrying that “the whole schedule has to be redone.”
The nuts and bolts of agile software development
Clean Power Research uses agile development as part of our software engineering practices to develop high quality software products. That means we adhere to the rapid iterative methodology of development. To that end, we meet in daily “stand-up” meetings to discuss current happenings, keep a backlog of desired features and release frequently.
The stand-ups help us stay aligned as a team in near real-time and allow us to quickly react to changes that occur as features develop. It’s an effective tool that ensures we stay on track.
The backlog is important for achieving both short-term and long-term goals. Features that come from the team or from customer requests are added to the backlog. The backlog prevents ideas from getting lost and provides an expedient way to schedule and prioritize activities. Each item in the backlog is evaluated against several criteria to determine the priority:
- The impact on customers
- How the feature aligns with overall product goals
- How long the feature will take to develop
This system allows us to change priorities to accommodate customer inputs or shift direction as the market changes. While it may mean something moves further down the backlog, we make those choices with full knowledge of the impact to our customers and overall product quality.
Finally, we release frequently, often weekly. These releases are possible through a strict release process that includes extensive automated and manual tests in our test environment to ensure the product maintains a consistent, high-quality standard.
Agile: the right choice for a rapidly evolving energy industry
Creating software through agile development involves customers early in the process, provides short feedback cycles and iteration, and creates a more stable and improved product. It allows the product to embrace changing requirements quickly and efficiently to keep ahead of the needs of the industry. As a result, utilities benefit by being able to take advantage of new features and improved functionality immediately.
While agile software development is not a panacea, it can position utilities to take advantage of future advances in software around machine learning, artificial intelligence or even virtual reality with the greatest efficiency. Change is the only constant in the world of software and technology. By using agile development, Clean Power Research is delivering what utilities need today while providing the flexibility to meet future needs as the energy transformation moves forward.
Interested in learning more about how PowerClerk is helping utilities take control of their DER assets? Read the article: PowerClerk: Your 24/7 assistant, not just a front-end tool.