2019年8月28日晚8点，由ShineScrum捷行主办的全球性“Scrum硬件敏捷产品开发”在线研讨会如期与大家见面。本次研讨会我们邀请到了国际Scrum联盟认证大师Arne Ahlander安儒宣和Scrum硬件开发专家Stefan Magnusson，分享有关如何在硬件产品开发中应用敏捷和Scrum的专业知识，吸引了国内外敏捷人士六十余位参会。研讨会最后15分钟的Q&A环节，Arne与Stefan针对大家提出的相关问题作出回答，会后由捷行工作人员整理如下，以便大家学习参考使用。
Q1. In hardware area, how to define potential shippable increment? At the end of most sprints, we haven't potential shippable increment, but only potential increment. Does it mean we are running a fake Scrum?
We propose that you make a wider interpretation of “increment” to include different outcomes: Add value, add knowledge and Build stuff. To get the right mix of these you need a simple high-level plan.
Q2. How to define DoD (Definition of Done) in hardware area?
DoD in software is often one for the Product Backlog and thus, similar between stories. In hardware we see that the type of stories differs much more, so DoD may need to be different for every story. Use them to set scope and expectations of the outcome of the story.
Q3. How to define hardware Epic/Feature/Story?
We suggest using the traditional Story-form, but WHO can be a range of persons. It’s important to always make the WHY clear. This is not simple and a big part of the course.
Q4. How to use Scrum in hardware if the product system if not modularized?
You need to find something that suits your situation to split the work. Are there physical interfaces? Different materials? Can you do design of a part in isolation? Can you use rapid prototyping of a partly ready design?
Q5. How to choose team size in hardware project? How many people can be in one hardware Scrum team? over 10 OK?
We don’t recommend deviation from the traditional development team size of 3-9 developers (+ ScrumMaster and Product owner). Instead accept that at most 20% of the work is done by persons outside the team and handle that in a structured way (Commitment point is one tool we have used with great success that you will try for yourselves during the course).
Q6. In hardware industry, somehow, we highly rely on our suppliers, but they do not use Scrum, and sometimes they even delay the project, how to deal with this kind of problem -- high dependency?
You will likely have these dependencies in HW,and you can try to minimize them. In Scrum we deal with reality and need a structured way to handle dependencies (Commitment point is one tool). My first action would be to explain agile to the supplier and how they can benefit from it as well. A second action could be to involve the suppliers even more. To grow together with your suppliers in order to optimize on product level.
Q7. a)The big & headache problem in hardware development is hardware is almost impossible to build the hardware in an incremental way.
You can try to be as iterative as possible by asking important questions and seeking answers to them during the sprint. Our experience shows that even if you don’t find a way to design incrementally Scrum is still more effective than traditional projects. In the course you will write your own stories and get feedback from us.
Q7. b)If in the Sprint 5, we find there has a serious hardware fault, it is always impossible to make a "patch" to the hardware to fix it.
Here you need to work with your risks on a nearly stage. In Scrum we always ask the most important question first and this means we can choose to address high risks directly. If you find a way to modularize and do incremental development the time to fix problems will be much shorter as well. Fail fast and fail in a safe way. All in the name of learning faster.
Q8. Would you please share the Scrum course contents? Not sure what’s the difference between our company’s hardware device development process and what can be benefited from Scrum?
Some more details can be found here: shinescrum.com/courses/534
You can always contact us at email@example.com if you need more specific information.
Q9. If no potential shippable increment when sprint finished, how we get feedback and how we learn? Does that mean the sprint length, or the time box is not so meaningful?
The Sprint length of maximum a month in Scrum is to help us shorten our feedback loops and learn faster. There are always things to learn! You can look up the tools MVP (Minimum Viable Product) and MVE (Minimum Viable Experiment). These are tools used during our training as well.
Author: Arne Ahlander, Stefan Magnusson