The mechanical engineering product development process has flaws that present themselves to any engineer that has ever engaged in this workflow. We can get stuck making last minute changes to a product when new features are added. It can be hard to track exactly how much progress is being made between broadly spaced deliverables. Finding tasks for every member of the team throughout the entire project blueprint can be difficult. We accept these flaws in the design process as standard – but could there be a better way?
Agile development has been around in the software production process for many years. It reimagines the conventional production flow for products, basing its methodology around frequent deliverables, cross-functional teams, and focused planning around strict timelines rather than strict specifications. In a grander context, Agile is a philosophy that can be applied to all aspects of production. Embracing change and establishing iterative feedback loops is at the core of Agile’s constructs.
In the software creation and programming process, Agile was developed to allow teams to manage and work together easily all while managing a constantly changing scope and deliverables list for each product. This ideology works well for the digital and constantly changing software world, buthow does it translate into the very divergent world of engineering product development?
How Agile Fits into Product Development
Agile breaks down into differing methodologies and processes that all keep the iterative and free-flowing nature of the technique at their core. The main methodology used, especially in engineering development, is a process called Scrum.
Scrum takes a project and breaks it down into regular cycles referred to as Sprints. Sprints generally last between 1 and 2 weeks and involve functional teams of 5 to 9 people. Each sprint encompasses some segment of work that the overall team has agreed to accomplish. The teams that work together on each sprint are generally cross-functional and self-managing. They take a certain task that has been established in the “product backlog”, similar to a list of goals for the product, and take it to a deliverable phase. A crucial aspect of Scrum is that each sprint ends in some sort of deliverable, whether that be a formulated idea, useful simulation, or all the way to a fully designed component. This enables iterative feedback loops in the design process and keeps progress from being made in the wrong direction.
The product backlog that teams pull from strays from the traditional specification documents of long-established product development. Instead of a set blueprint, this backlog consists of prioritized items that represent added value, are testable in nature, and ultimately capture the who, what, and why of a task. The existence of a fluid and iterative product backlog requires a rudimentary shift in our design process. It becomes essential that we understand this concept at a deeper level.
In our typical product workflow, we begin with a list of specifications from a client. Arbitrary specifications like, “able to hold 5 pounds” or “capable of being easily lifted.” These concrete specifications from a client, or sometimes developed by engineering teams at the beginning of a project, set strict guidelines for what needs to be completed and added into the design. When met with these specs, standard engineering workflow takes us into a process called “waterfall.” For this, we take these specifications and work through a design-make-use (DMU) cycle in succession. Scrum’s shift to a product backlog changes this workflow into an iterative process.
The cycle for product development stays constant within the design, make, use flow, but teams using Scrum operate in parallel both down and across the DMU cycle, operating in iterative feedback loops. Working with this flow allows forward progress to constantly be made while still allowing for design changes, problem mitigation, and impactful idea generation.
Image courtesy of Redshift
Drawing back to the initial example of clear-cut specifications, we can see how a Scrum workflow can benefit hardware design. In the typical waterfall technique, these specifications are taken through the DMU cycle with little consumer feedback or measurable deliverable phases. This allows potential problems to occur. If the specifications are later clarified or even slightly modified, we engaged in the waterfall process end up with wasted hours in planning and useless conceptual designs. By creating feedback loops through Scrum, we can be constantly engaged with our product’s goals and make changes to the design easily and effectively.
Why Agile is Needed
We have already seen that Agile development allows for the prevention of wasted man hours and useless designs. The iterative nature of the philosophy creates an environment for constant progress down the innovation continuum. With that said, there are indispensable aspects to why applying Agile to product development is a beneficial undertaking:
It forces engineering teams through the DMU cycle at a faster pace for smaller segments of the design. Through the establishment of cross-functional teams, workloads can be managed entirely autonomously within each small task. Work can constantly be accomplished without bigger picture meetings involving the whole engineering team. Meetings can be kept brief, tasks can be accomplished faster, and a constant workflow can be established. This benefits both engineers and overall management in product design.
It induces active thinking and preventative action. In a typical design process, we create a blueprint of tasks to accomplish and stick to it as best as possible. This “instruction-based” workflow can work well, but it encourages engineering along a straight and narrow bath. By utilizing iterative Agile techniques, we can be more deeply involved with problem solving throughout the creation process, perhaps even foreseeing possible issues. This active thinking somewhat occurs in waterfall processes, but Agile magnifies its potential.
It creates an environment for innovation. Every engineer or engineering team’s goal is to progress a project through constant innovation, finally reaching the best possible deliverable for the client. Static waterfall processes only allow the best possible solution imaginable when the initial specifications and the workflow blueprint was imagined. Agile allows for constant change throughout the entire design workflow and creates a setting that is perfect for innovation growth.
All of these overarching benefits of Agile, combined with more specific results of its application in each design flow encompass what makes it such a useful ideology for hardware development. If we understand its benefit and its principles, the next step is applying it to our workflow.
Apply Where Necessary
Agile’s beginning in software development naturally creates some disparities between the actual methodology and its specific application into the mechanical engineer’s product development cycle. This can be seen in how each sprint results in a “deliverable.” In the software realm, delivering a functional set of code can be accomplished within a sprint timeframe, but for us, delivering a functional part often cannot. It is in this way that we have to take these ideas and create a hybrid hardware approach that is “inspired” by Agile development.
Sprint iterations, perhaps the biggest aspect of Scrum workflow, can be applied to how we approach our designs. Instead of moving down the design-make-use process singularly, it becomes much more advantageous to segment the process and work in both directions. In this sense, we need to take ideas or concepts that we have for the project and work on each individually within a sprint timeframe. For Agile, staying within a set timeframe becomes much more important than accomplishing every task first imagined. This can prevent projects from going over schedule by significant measure.
One thing needs to be clarified here. This time based agile-inspired process does not mean that the overall project could result in a lack of needed features. Rather it makes teams focus on accomplishing necessary features, and allows for optional features to be accomplished if time permits. At the beginning of a project, teams can often have ideas that make a project better, but they aren’t necessary to incorporate into the project plan. Time-centric development allows the necessary to be accomplished, with the possibility for the supplementary. Using this methodology as engineers allows us to fully optimize where we focus our energy.
Moving along with inspired application, our organization of engineering teams needs to be altered. When project tasks are split into manageable weekly sprints, teams can stay more focused but also need to be made more diverse. Instead of the department-oriented teams of long-stood engineering development, we need to create teams that involve every level of leadership. This means that for Scrum sprint teams, we need a Team Leader, the person who controls the small team, a Sprint Leader, the person who controls the process, and the Development Team, the workers. A team leader and a sprint leader can also be involved in the development team, but their main goal is to control the process of the sprint and the end deliverable created by development. There also doesn’t need to be anything hierarchical about who gets what role. It can vary between project, exist between the same level engineers – all it does is establish control over who is doing what on a certain task.
When you step back and examine how most engineering teams are set up, it segments knowledge and blocks often-necessary communication. Placing the design staff on a separate team from the production staff can and does result in communication roadblocks within our process. Agile-developed teams enable communication for each sprint between every necessary “department,” even if said department is only one team member.
Applying Agile to overall project production also manages team functionality and individual member stress. By segmenting larger projects into small and accomplishable deliverables, teams can gain a tighter feedback loop and be able to manage requirements on a much more concrete scale. This keeps the individual engineer from becoming overwhelmed with what needs to be accomplished in a project as well as helping prevent procrastination or lack of forethought in planning.
Shifting Our Product Development Process
When applied properly, Agile-inspired product development can prevent multitudes of issues in the design process and positively impact project timelines. By following stories, not specifications, sprinting shorter distances rather than “jogging the marathon,” and empowering teams with specific deliverables, our engineering itself can become Agile.
Examining Agile techniques in greater detail leaves us with many benefits towards the utilization of this workflow tool and very little drawbacks to its potential implementation. As engineers and project managers, we have to ask ourselves, how we can properly implement agile inspired techniques into the engineering teams and resources we have available to us. By segmenting our resources into smaller teams and having daily scrum meetings, do we gain functionality and foresight? By iterating in the design process in weekly sprints, do our projects become more manageable and result in better deliverables? These are questions we must ask ourselves or perhaps even test out in applicable projects. As engineers, we must always strive to optimize and innovate our product development process. It is for this reason that we must undergo thorough investigation and implementation of Agile-inspired product development within our specific engineering process.