Issue link: https://read.uberflip.com/i/1198887
2.0 Agile development processes Agile development processes have been very topical for the past 20 years and there is a vast amount of literature dedicated to the subject, especially in software development. One of the key goals of "Agile" is to be reactive to change. Software was once designed using a "Waterfall" process, where everything was determined before development could begin. "Agile" seeks to embrace change, by structuring the delivery of work so that progress can be constantly checked and the design direction changed in a way that minimized wasted effort. When the creation of a working piece of software is compared directly to the creation of buildings, the notion of agile development is pretty fanciful. Construction is, almost by necessity, waterfall in its process. The design basically needs to be completed before construction can begin. Agile execution of the construction process may be possible, but an Agile approach to designing and building large scale projects feels a long way off given the nature of construction. When the creation of a working piece of software is compared to the creation of a documented design, however, the parallels are more applicable. Both have the following key elements in common: ● A loose conceptual vision that, over time, needs to be developed and refined into a working solution ● A need to be flexible and adaptable to change, as more information becomes available, or as project requirements evolve ● A high level of inter-related dependencies which need to be developed individually but which can also easily trigger change requirements elsewhere Arguably many engineers seek to minimize cost by operating with a waterfall mindset – this essentially means waiting for a perfect set of design requirements before starting in order to avoid change. This is somewhat ingrained in engineering standards - some notions that you need to know everything before you can begin. This may not be the most cost-effective way to operate. In any case, the way software development teams structure themselves to deliver tasks in an Agile way is of most interest to this paper. These processes could potentially lead to big productivity savings for MEP design teams. They might also enable MEP firms to deliver more value to clients. Applying lessons from software design to building services engineering 5