Scrum for Hardware

The first scenario that you picture when you hear “Scrum” is, most of the time, a small development team that work on a modern app in a sort of small and informal environment with almost no rules (I am exaggerating a bit… perhaps).

This is a pretty common cliché, somewhat easy to debunk. But what do you picture when you hear “Scrum… for hardware”? Scrum is usually associated to software development so perhaps you could think that I meant “Lean” and not Scrum. Actually I really meant to say Scrum.

Don’t get me wrong. Lean is a great approach to manufacturing. It minimizes variance (i.e. waste) and therefore improves cost and quality. On the other hand it can be counterproductive if applied to achieve change or innovation. There is always a trade-off between innovation, which is a form of variance, and the cost needed to support the change.

Lean is not the right tool to support innovation. It is a great tool, but not if you, sometimes, value waste.

A growing number of companies are successfully adopting Scrum as the framework to deliver innovative hardware projects. There are many factors behind this choice. Rapid prototyping, learn and adapt from early feedback are a couple of them.

A company famous for its application of Scrum to hardware development is SAAB. They run Scrum to build the multi-role strike fighter SAAB Gripen JAS-39. It is a well know success story of Scrum, adopted to develop hardware and software, that is running for more than ten years.

There are a handful of practices that can be leveraged, regardless whether you work on software or hardware.

Make your work visible is one of them. In that way, the issues become also visible and you will be able to unveil hidden delays. Ideally, all the work should be visible in order to enable the whole Company to benefit from this approach. You will also be able to avoid bad surprises. Nobody will be able to say “I didn’t see that coming”.

This is a very easy practice to implement. Even if you are not following a cadence (i.e. sprints) it is fairly easy to set-up a physical or virtual board to enable visual management. Moreover, it it a great help for prioritization.

With the right prioritization and the stress level under control thanks to reduced changing priorities or unclear goals, the team can focus on perhaps the most valuable practice of Scrum:  “inspect and adapt”. Work to get early feedback  from your customers and improve the way you run your daily operations. A hardware project can benefit as well from faster feedback thanks to mock-ups and prototypes. A common scenario is to use simulators to enable prototyping for the hardware product.

To make Scrum work, it is key that the impediments are identified early and removed quickly. With the help of the visual management you can make clear that the sprint is at risk by highlighting the issue and make it easier to escalate it. After all the upper management wants the development team to be fast so it is only fair to ask them for help. There should be in place a lean and well understood mechanism to escalate issues and solve big dilemmas without making it sound an emergency every time. I am not talking about processes (they might help), I am talking about a mind-set always ready to tackle the issues. A mind-set always ready for feedback.

Last but not least, work at a sustainable pace. If all the teams start the four-week sprint the same day and follow the same  length it becomes easy to synchronize the Company around the same “heart beat”. Change management will follow just as a natural consequence. It is also worth measuring the velocity (just counting the cards is a starting point) to understand what your “sustainable pace” mean.

Sometimes, it seems that using Scrum for a hardware project contradicts the rules that have been established over the years of successful adoption of the framework for software projects. Obviously, hardware  and software projects have significant differences in their nature and this has to be taken into account when adopting Scrum.

One of the most striking differences is that a software project is capable of deliver usable features over time whereas an hardware project delivers its value at the end i.e. we don’t have a potentially shippable product at the end of each sprint.

There are many challenges when developing hardware, but none of them should stop you from trying Scrum for your project. It is a safe bet to consider hardware projects to run in a highly regulated environment, where physical safety plays a critical role and where the cost of failure can be very high.

Another challenge is to implement agile estimating (e.g. using poker estimate to quickly determine the rough size of a story in points or t-shirt sizes) because there is little overlap of skills and therefore discussing about estimates to gain a better understanding of the work ahead is pointless. The specialization skills needed by the team members to work on a hardware project set them apart therefore not all members are always able to challenge or contribute to the story estimate.

The high diversification of specialization skills makes it also difficult to do pairing or swarming because only a few members could have the skill-set needed to collectively work on the critical story that is not progressing at the velocity we would like to see.

As written on hundreds of other blogs, Scrum is not a silver bullet that solves all the issues you might encounter during your project, but you should definitely be open an try it also if your product involves a considerable amount of hardware.

There are many success stories of Scrum being implemented for software and hardware projects therefore I encourage you to give it a try.




Conway’s Law

In this post, I have put together some material I have collected to give an overview of Conway’s Law.

Conway’s Law is about organizations, communication, and systems (products). It describes how these three fundamental elements are intertwined giving a powerful summary of our environment and its behavior.

We should always be aware of Conway’s Law and play it to our advantage.

Back in 1968 M. Conway wrote in a paper
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” (M. Conway)

In 2008, Harvard Business School published a paper supporting the observation that Conway made 40 years earlier.

Conway’s Law is a valuable reference to understand the history of a company and improve its future actions, from a too often neglected perspective.

The main purpose of a company is to achieve a specific business goal. A key element is the communication that supports the collaboration needed to pursue that goal. How many times have we seen reorganizations of teams or whole companies fail to deliver the expected result? Whose fault is it? How can we improve?

A common culprit is the siloed organization. The vast majority of my colleagues see silos as a bad thing but we accept them as part of the game.

An idea is to design the organization for Conway’s law. This could help to move towards cross functional teams, better communication, and leaner products.

How do we break the silos? By leveraging the communication structure (not the reporting structure) and this is a goal  in the range of what a team can accomplish without having to redesign the entire organization.

A couple of examples are Spotify where collaboration across teams is a fundamental value driving the company and Amazon where Bezos gave a very precise direction to the teams in order to achieve the desired enterprise architecture.

Another suggestion comes from Thoughtworks. A technique “blip” in the tech radar of 2014 and 2015 was the Inverse Conway Maneuver which basically tells to design your organization for Conway’s law.Although this is not current anymore in the new radar edition it is still worth exploring.

We can also look from a different perspective: the product. There are several technologies available to enable an organization (or a small team) to leverage Conway’s law. Containerization, microservices, modern communication tools like Slack or Facebook’s workplace are all going in the direction of a more fluid and interconnected environment.

These products and technologies can also shape the organization its communication. A good example on how the technology can be a driver for change is the DevOps movement. It started as a technology-driven change which is now mature enough to be considered a good practice to organize teams.

We have seen that each element of Conway’s Law can influence the other two. This can be used to our advantage whenever we have to decide how to adapt our tools/organization/communication to pull all together towards the end business goal.