Last time I talked about validation and verification and how they apply to both software requirements and engineering. Today, I’d like to cover another topic we talk about in our training and how it relates to engineering; software development lifecycles (SDLC) for Waterfall and Agile.
Again, to begin, I’d like to start with the definition of each. The Waterfall development lifecycle is a linear life cycle in which each phase of the process must be completed before the next can begin (or if two phases are being completed simultaneously, there are still phase gates for both and oftentimes special permission needed). Each phase of Waterfall usually has a list of things that must be completed before the team can exit that phase (phase gates). Sometimes, this leads to teams doing work that is not necessary for their project to make sure their phase checklist is complete.
The Agile development lifecycle usually has many of the same phases of the Waterfall lifecycle, but they are conducted differently. Ideally, all the phases of the lifecycle are completed in each sprint (a 2-4 week cycle at the end of which something is delivered- a product, enhancement, etc.) and each project will have multiple sprints to complete. In this way, the project teams can get the system/product into the customer’s hands faster and understand what works and doesn’t work. Similar to Waterfall, there are some drawbacks- mainly the need for colocation of the team and for the subject matter experts to be dedicated to the project (which is not always feasible).
But this blog post really isn’t about Waterfall vs. Agile, pro and cons or which one is better when. Instead, I’d like to leave you with how this relates to engineering (structural engineering specifically) to have a reminder of the differences between the two lifecycles.
Now, my disclaimer is that engineering is fundamentally a Waterfall process; the client’s needs are gathered before design is completed and design is completed before construction begins. This is a typical bridge or building. So I’m not going to spend much time on a Waterfall house as almost all of them are.
The more interesting topic is what would an Agile house look like? There are actually two ways to think about an “Agile” house. The first is the “Minimum Viable Product.” In many Agile projects, the first sprints/release is about getting the Minimum Viable Product (MVP) to the customer. This way the company/project team can understand if customers will use the products and can get feedback on future features to add. In an Agile house, this MVP would likely be the superstructure and substructure of the house. The foundation would be poured; there would be four exterior walls and a roof. No flooring, no delineated rooms, no plumbing, no air conditioning, etc. If the Agile engineer was smart, the walls and foundation would be designed in such a way to accommodate those other things being built later, but it might not. In subsequent sprints/releases, the house would be built upon: the interior walls would be built to make rooms, the plumbing would be put in, the electricity and AC would be put in, the walls would be painted and have baseboards put on, basic appliances would be added (bathtubs, toilets, sinks, etc.) and the exterior of the house would be decorated to look livable. But each of these subsequent releases merely add functionality to the house; the house was livable after the first release. This idea requires that at a minimum, the entire project be scoped at the beginning.
Another way to look at an Agile house would the “complete package” idea. This is the idea that each sprint should deliver something that can basically stand-alone. In this view of the Agile house; a single room would be built in the first release, say the master bedroom. Everything in this room would be complete: foundation, exterior and interior walls, flooring, electricity, plumbing, etc. A person could live well in this one space. Then subsequent releases would each add a room and connect it will the rest of the already built house. This view is a little more flexible than the MVP idea. You don’t have to know what the entire footprint or idea of the house will be, you just have to understand one room; everything else can be added later. But again, if you don’t plan ahead for the house to be extensible, you’ll run into significant rework in construction to make the house as a whole structurally sound.
Of course, neither of these ideas would actually work in engineering- the first because people don’t want to live in a minimum viable product house and the second because a structure needs to be built either all at once or designed in such a way to allow future expansion to ensure its structural integrity (this applies to software project too in some ways), but it is interesting to think about.
What do you think about the Agile house? What helps you remember the differences between Waterfall and Agile?
