Before we get into the details of Agile for non-software projects let’s take a look at how this methodology came about. Agile methods for software development have been traced back to the late 1990s, but not until 2001 with the development of the Agile Manifesto has the process become so publicized. Still the majority of software is developed today using the Waterfall or Modified Waterfall methods and certainly most hardware, service or process improvement is managed this way.
The Agile Manifesto states:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
With the advent of Object Oriented Software development methods it became easy to break large software projects into very small components and therefore able to take advantage of the Agile sprint. Since in each sprint the outcome is a working element of the product this ensures rapid feedback and adjustment to the changing needs of the marketplaces. The Product Backlog becomes a Sprint backlog which turn into user stories that the developers can then break down into actionable tasks to be planed into the next sprint. Sprints are typically 2 to 4 weeks depending on the team and the product being developed. So you ask why not use these methods on hardware, service of process improvement projects.
The answer is that teams are beginning to use Agile methods to manage the rapid cycles of learning and feedback in non-software projects and here is how they are doing it. The basic steps of the Waterfall method that team are familiar with are: Requirements, Design, Implementation and Verification. Why not put these elements into each sprint cycle? By breaking down the project into small modules one can fit them into sprints. Therefore a Product Backlog of features, becomes and Sprint backlog of stories, which becomes tasks in the sprint cycle. Today with the rapid prototyping capabilities for printed circuit boards, molded parts, CNC cut parts and laser printing there is no reason why the sprint cycles can’t be used. By breaking down a service or process improvement into its smallest components these also can fit into Sprints as defined by the team thereby obtaining rapid cycles of learning.
The key part to all of this is the definition of “Done“. It has been the most difficult element whether the project employed the Waterfall or Agile processes. It is the upfront planning that is key to making these Lean process improvements in the development lifecycle. It is by looking at the customer “Value Stream” that one can define what is important and therefore used in the definition of “Done”. There are also the non-functional requirements to take into account e.g. regulations, internal company needs, market musts, and others to are needed as part of the Product Backlog. So by taking the current development cycle and putting it into a Scrum Sprint one can become far more agile and ensure that at the end of each sprint they have delivered elements of what the customer is asking for.
A dramatic example of a hardware project that one thinks is impossible to manage using Agile methods is being done by Joe Justice of WikiSpeed. He answered a challenge by Progressive Insurance to build a car that gets 100 MPG. He did so using scrum methods.
So in conclusion it is: People over process, Deliver over Control Documentation, Cooperation over Contracts and Change over Detailed Plans.
With these principles in mind Agile methods can be applied successfully to non-software projects.
Contact Allegro Business Solutions for further information