Scrum in Six Steps
So I started to write my master piece on how to start with Scrum for Hardware – the organizational change, written in clear readable steps, intended to be very practical. After I completed the first writing session (which goes below) I thought “Darn – that is just Scrum for Software, I failed!”
And I need to update, add and polish. But I believe that what I discovered is worth sharing: starting a Scrum for Hardware implementation in your organization is not different from any Scrum implementation. It is the art of the possible all over again. Here is my first take, stay tuned for a more polished version, and don’t wait for it if you want to get started with Scrum for Hardware!
Scrum for Hardware – Just Do It!
This is the first post in a series about Scrum for Hardware, a series with hints and tips, and sometimes deeper thoughts, on how the iterative plan-do-inspect framework called Scrum can be applied successfully in developing hardware products.
First a quick definition: hardware. As I jokingly say, the part you can kick in a product. (I printed T-shirts with the slogan “If you can kick it, you can Scrum it!”, still surprised that nobody kicked me!) So, although there are often firmware and software components in a product (say a hard disk drive), what this series is about are the parts you can’t program (the enclosure, reading head, disks in a hard drive).
This first post is about how to get started with implementing Scrum in a hardware environment. You’ll hear me say the following more often in this series: “Just like in software development,” … Here is the first time I’m using this phrase: “Just like in software development, learn about the Scrum process by taking a class, reading a book, pick up a copy of the Scrum Guide and then “just do it”. There are lots of questions to be answered, and problems to be solved, and like in any project – you won’t get all the answers upfront.
Let’s look closer at that advice, what is needed to get started with Scrum for Hardware and expect to be successful with that implementation. In 2005 I wrote a paper with Ken Schwaber and Dean Leffingwell titled, “The Playbook of Implementing Scrum.” The playbook had six basic steps:
- run a pilot
- achieve impact
- measure assess, adjust
- expand & win
Implementing Scrum for Hardware also follows these steps, here is how to put some meat on the bones and I also offer a few real-life examples.
#1. Prepare for the Pilot Project
Scrum is Scrum, whether used in software, or in hardware, or in schools (have a look at eduscrum.nl). Therefore train the involved people as a Scrum Master or Product Owner. Run an Executive Briefing, and bring a Scrum Coach in to work with the people in the development teams. Don’t burn many hours and many dollars on this step — but don’t skip it. The old saying, “when all you have is a hammer, every problem looks like a nail” is also true when you move away from your plan driven development process.
#2. Run a Pilot
Now, select a first product development project, not too big (say 15 active people as an upper limit) and not taking too long (maybe 6 months).
Get around the table with all these people and prepare a first list of things to deliver as part of the product. Don’t go for a perfect list, go for a good list: one that provides reasonable coverage of all the work that needs to be done. Accept that it will not be a correct list! A good way to enforce this acceptance is to time-box this meeting: in 4-8 hours the result is ready. Whatever is delivered in those hours is what is going into development. (An intriguing thought: the less certain you are about the list, the sooner you have to start delivering and inspecting the results.)
Except for “accept that it will not be a correct list,” the previous actions are easy. Now a hard one: with the same group of people, lay out the deliverables on your list in such a way that the most important deliveries are done first. And then split up the top 5 of these deliveries into slices so small that you can complete 10 of them in 2 weeks. If that isn’t hard enough, now ensure that when the 10 first activities are delivered the group can learn from the results. And that this learning is the most important thing they can learn. In this whole exercise keep in mind that hardware is the part you can kick, so those 10 results can all be kicked! (No proud man or woman wants to be caught kicking some pieces of paper around, right?)
Congratulations, you’ve taken an important and hard hurdle: you sliced what used to be a series of design documents into steps that go from design to delivery in a matter of days. You have a first groomed product backlog for hardware! Your plan-drive brain might object at this point: no plan, no estimates, no committed dates! No. None of these, but what you should have is a group of people who are excited to get their hands dirty, who trust each other to do the right thing, and who trust leadership and management to help and protect them. Go find the video of the All Blacks performing the Haka dance prior to the Rugby game – that is how your team should feel and act!
The pilot has effectively started by now: you have a team, a product to deliver, a list of activities, and the very top of that list is ready to be delivered. Let’s Scrum!
Everybody has learned what a Sprint Planning meeting is, so run it. Go for an outcome where all the workers are confident that they understand what needs to be done, and that they are capable of doing these things. They expect to be successful, and they feel safe enough to take risks – knowing that some plans will fail and that all that will happen with failure is a request to sit down and learn from it.
#4. Achieve Impact
With the Sprint Backlog ready step back, and let the team work. Protect them, jump in to help if they ask you to, listen, observe and learn. And do not direct, or suggest, or talk, or annoy them. Let them be their best. Wait for the end date of the Sprint to arrive, and then sit down with the team to review what happened. Some deliveries will be solid – with test results, or mounted in a prior version of your product. Some deliveries will not be fit for purpose, although test results looked promising. And some deliveries didn’t make it at all. Great.
#5. Measure, Assess, Adjust
In just two weeks you have results, data, and that gives material to inspect, to change an approach, maybe change the team structure. The review will result in an adjusted product backlog – some activities added, some moved around. A suggestion to regroup or to slice the deliverables differently. A better understanding by everybody of what matters, when things matter, and where the delivery is going to hurt. Almost ready for rinse-and-repeat. Ask the team to retrospect, inspecting how they worked, what team dynamics happened (or not), what was a good experience, and what was a hindrance. Don’t expect a report, but maybe a few requests for help. Over time the effect of this retrospective will be tremendous, this is where the faster-better-cheaper delivery of products really happens.
#6. Expand & Win
Go back to the beginning of this post – rinse and repeat! And the most important thing: keep looking for that Haka dance spirit in your team!