Agile Teams

Hardware Product Development with Scrum

I am now 6 months into applying Scrum to hardware product development. I have better project planning and control than when I was applying traditional tools. From the implementation front, I am a Scrum Master on 3 independent development projects, the Team is integrating work monthly with a higher level Scrum team through a Scrum of Scrums, there are 4 Product owners and the approach to product development using Scrum is spreading every week. In my estimation the Teams have been radically successful at adopting and applying the Scrum Framework.

Aside from the implementation, the overall environment is changing from what was a command-and-control planning approach to that of an inspect-adapt-iterate “Agile” planning method. Due to the complex and uncertain problems we are solving, the frequent inspections, coupled with regular feedback loops are naturally working. The entire mindset has changed from “this is how you do it” to that of “here is the highest Risk item(s) on the project, tell us how you are going to go about engineering a solution, and let us know if you are faced with any impediments so we can remove them”. The environment change by itself has been a huge win.

I never thought that after 6 months I’d be in a position where I would need to start thinking about the next layers we can add to the basic framework. We are experimenting with Kanban for work packages, Lean principles for further waste elimination, compressing Sprints to 2 weeks, and exploring how we can optimize engineering tools and methods. Scrum is certainly a powerful inspect-adapt-iterate Agile approach, and can certainly be applied to hardware development.

More recently, I have been pulled into Agile Coaching. This is turning out to be a natural fit for me. Assessing the situation, training, launching teams, and ongoing coaching has been personally rewarding. Sure it is great that I have been able to apply this approach to my projects, but it is more satisfying to see others engage to make a difference.

Not that long ago I had never heard of Agile Project Management or Scrum. I was soley using a deterministic planning tool, project control that relies heavily on updates from Team members, and flaccid Risk management. Now, with an empirical process control approach, planning is real-time with frequent updates to the long range forecast, project control is established through transparency and daily communication with the Team, and I have implemented a solid Risk Planning methodology that is focused and aggressive. For the 1st time I am ahead of the projects and not constantly feeling like I am chasing my tail.

Lastly, those few individuals resisting the new environment have me perplexed. Self-organization and self-management is so far on the other side of the spectrum from “I’ll check-in, tell me what I need to do, I’ll do it, and then check back out” that the muscle memory keeps them from seeing the vision of how much better the engineering environment would be if they just engaged. It may be quite possible that complex problems are reserved for the free thinkers, those with initiative and drive, those few individuals that have the courage to take on the riskiest problems and make solid commitments to solving them.

Implementing Scrum for Hardware Product Development, training by Ken Schwaber, and listening to the insights from Jeff Sutherland have changed my Program Management approach. The next step in this journey is to maximize efficiency by understanding and applying further Agile tools and principles.