Regardless of the chosen method for Epic development, each Epic can be further decomposed into Features that represent a slice of meaningful functionality to a customer or end user. When the teams are ready to work on a Feature they will break it in to user stories.

User stories are typically written in narrative form and should be a testable vertical slice of functionality. The story should encompass requirements, design, development, test, integration and analysis.

Each user story should have a Definition of Done and an Acceptance Criteria. The Definition of Done is a checklist for user stories of similar types and ensures quality and completeness. The Acceptance Criteria helps the team have a clear understanding of the problem they are trying to solve and what test they will have to pass before work will be considered complete. The Acceptance Criteria clarifies the “what” and ensures there is a common understanding of the requirements prior to the start of work.

Vertical slices allow the team to quickly pivot as they learn more about the product they are developing. Because the product is being incrementally tested and vetted by the customer, there is a higher probability that the customer will be happier with the end product and that the product itself will be higher quality. Once vertical slices are ready to be worked by the team, there are many techniques they can use to perform the work with increasing agility.

Hardware Development Challenges

Hardware development is physical in nature therefore it is significantly different from the intangible development of software products. Changes to hardware are generally more expensive due to wasted development efforts, raw material costs, shipping and handling, expediting fees, inventory, and material management costs. Drastic software changes are virtual in nature and so they typically result in re-work and wasted development efforts. This significant difference in the cost of altering a design makes it imperative that hardware teams have less expensive ways to test out their ideas early in the product development process, before ordering more expensive prototype, pilot, or production materials. This is one reason why teams brainstorm many design concepts for components and use virtual modeling, 3-D printing, and simulations to fail the concepts as early as possible, obtaining meaningful customer feedback along the way. They then arrive at the best design solutions and continue to use virtual modeling, 3-D printing, and simulations during sourcing lead times to gain important product feedback about the slice of functionality they are developing. The teams push to build “something” demonstratable to the customer to solicit feedback regardless of prototype, pilot, or production part availability.

Hardware development introduces a special challenge in the form of lead time associated with obtaining a supply of raw materials. As the team rapidly iterates toward developed products, they need a shorter supply chain with vetted and available rapid sourcing suppliers. Adjusting the supply chain to accommodate quick turn suppliers and rapid prototyping takes time. An initial workaround for shortening the onboarding time of prototype suppliers in the Enterprise Resource Planning (ERP) system is the use of purchase cards available to the development team with an associated spend limit. This allows the teams to purchase low cost prototype materials from the supplier of their choice without the red tape associated with getting interim suppliers in the ERP system. A more lasting solution is the development of the sourcing skillset on development teams or the inclusion of sourcing at a scaled level. This will allow the teams to either source materials themselves or access more timely sourcing at the team of teams.

Agile Development Techniques

Many of the agile best practices and techniques that software teams use can be modified and applied to hardware development to create more opportunities for agility along the value stream.

Pair Programming is an agile software development technique in which two programmers work together at one workstation. One person writes code (Driver) while the other reviews each line of code as it is typed (Observer/Navigator) and strategizes about future work or improvement opportunities. The two are both capable of writing code and regularly switch roles. Because the two software team members pair together, bugs are less prevalent and the two are more accountable to efficiently complete work. Many studies have been conducted on the effectiveness of Pair Programming and the results show that pairs have ~15% less defects in their code. However, pairing can become overused if team members spend all day working together and are unable to independently approach work. It can also be distracting to use pair programming for more complex code in which solo work is better suited.

The concept of “pairing” is derived from the Pair Programming technique and can be used to facilitate Development Team Members working together to complete stories for the purpose of shared learning, awareness of the “big” picture, collaboration, and increased knowledge saturation. Pairing is an easy way to start making gains towards a more cross-functional team.

Test Driven Development is a software development technique, also known as red-green refactoring, that requires developers to write and run tests before they write code. The new test is run and subsequently failed to ensure that it captures the necessary logic to be confident in the results. The minimum code is now written to pass the test and the test is repeated to ensure the code passes. If the code fails it will be adjusted until it passes. The code is re-factored, non-functional attributes of the code are improved, and the result is solid code, reduced re-work, and improved quality.

Agile hardware teams borrow from this concept by writing stories with a test in mind and using red-green testing techniques to develop the product to the point that it passes the test. This is often referred to as the Minimum Viable Product (MVP) and it helps prevent over-engineering of the solution. This approach also ensures that work is completely done each sprint and it raises the quality of the final product because the pieces are tested along the way.

Scaling and Infrastructure

Agile development techniques can improve the efficiency within teams; however, there may be dependencies between teams, departments, or supporting functions that need to be resolved in order to arrive at complex, large scale product solutions. Scaling can help address bottlenecks and significantly improve time to market as waste is removed from current development processes. Some examples of organizational waste include handoffs, specializations, multi-tasking, context switching, and decision making by parties not involved in the details of development.

Agile Heat Mapping is a technique where the location and maturation of Agile, lean techniques, frameworks and best practices are mapped out and recorded across the organization. This provides visibility into pockets of Agility and allows for enhanced collaboration, learning, and sharing. It also serves as a baseline for Horizontal Scaling. Horizontal Scaling refers to the spread of Agile approaches across the organization. Teams that are using Scrum, Kanban, various lean and agile techniques, and scaled frameworks can be present within the same organization and yet they are oblivious to each other’s existence. By mapping out the current state of organizational agility, progress can be tracked over time.