SCRUM – Iterative project execution!!! Does it works only for software projects? Let’s have a look…

The SCRUM methodology and iterative project execution is well established in the software community, but does it work equally well for other types of development? Lots of hardware projects iterative approach and have shown a big difference, improvement in the output of the team.

As a first observation what one of the hardware team in our company has to say is that they are able to tick off work items at a 30-50% higher rate than they did before!!!

They have all been there at one time or another - Things pile up on their desks. Everything seems so important. Where they should start? They begin to multi-task and switch between tasks, trying to somehow manage it all. However, this does not make them more efficient. On the contrary, frequent start and stop of tasks and the over-head that this creates can decrease efficiency quite dramatically.

The SCRUM methodology addresses this problem. The team defines the scope of the coming two-week iteration, or “sprint”, by selecting the most highly prioritized work items, or “features”, from a “product backlog”. The team then defines the related required activities, which go into the “sprint backlog”. The team members “pull in” activities from the “sprint backlog” when they have time/capacity to do so and ideally focus on one activity at a time until all are done. When the “sprint” is over, the “product backlog” is updated and re-prioritized and the next “sprint” is started. In this way it is possible to combine focused work short term with constant re-planning to make sure that the priorities and the direction is right.

By the way this team has not gone “full-SCRUM” at this point but never the less they got a lot of benefits from this way of working. Now for the team members the priorities for the coming next weeks are very clear, everyone knows what to do and they share the load in a much better way. Team is under a lot of pressure to deliver now so this is just what they needed.

 A key aspect of the SCRUM methodology is the “retrospective”; a short session after each sprint where process improvements are identified and planned. In this way the aspect of continuous improvement is built in to the process. Where the team starts in terms of process practices is then not that critical as the process will evolve and improve continuously.

They had a couple of “retrospective” sessions and they think the benefits of those are clear, but they are still to establish this as a routine.

Changing processes and ways of working is never easy and it takes effort and commitment, but looking at the potential benefits it is an investment that pays off.

They are not all dedicated SCRUM “believers” at this point, but they don’t have to be. The practices are pretty straight forward and as a team they feel they are moving in the same direction. They are all dedicated to getting the products out on time and with the iterative approach they are clearly better off.

Quick summary of why we need to use SCRUM to build hardware,

• Improved communications 
• Shorter feedback cycles
• Transparency of product status
• Transparency of problems
• Clear roles & responsibilities
• Focus on delivery
• Know-how transfer through teamwork

I hope above case has given enough evidence that SCRUM is applicable in hardware projects as well!!!