[Background]
I have for a few years working to apply agile SW development to product development, i.e. creating a HW product with SW from scratch and will try to summarize several of my findings.
Some basic facts/findings (in this case):
- Producing HW, prototypes etc cost more money than a SW prototype (a lot more)
- Turnaround time for HW changes are a lot longer than SW changes. A product have typically <10 builds from scratch to complete product, during a span of at least 12 months. SW have more builds made in one day...
- Agile is not equal to Scrum, scrum is a well known toolbox but you do not have to do scrum to be agile...
- When a HW prototypes is build, it is most likely planned/purchased timeslot and what is not working when the slot is at end (on the HW) will not work until the next build is scheduled.
Some basic facts/findings (in this case):
- Producing HW, prototypes etc cost more money than a SW prototype (a lot more)
- Turnaround time for HW changes are a lot longer than SW changes. A product have typically <10 builds from scratch to complete product, during a span of at least 12 months. SW have more builds made in one day...
- Agile is not equal to Scrum, scrum is a well known toolbox but you do not have to do scrum to be agile...
- When a HW prototypes is build, it is most likely planned/purchased timeslot and what is not working when the slot is at end (on the HW) will not work until the next build is scheduled.
Software on the kind of products I have in mind, can be simplified in 3 different categories:
1. HW level, typically SW that is used to communicate with sensors, drivers and combining data from those. This level is the foundation, both upper levels of SW as well validating HW components, both during production and developing prototypes
2. Middle level, typical level of SW that is highly dependent on running correct HW and providing the glue to present a usable product.
3. Top layer, typical different add-ons that will enhance a product that can be added/removed quite easily to a product. Can be developed, if design rules are in place, on different HW but need to keep performance and other restrictions in when doing so.
1. HW level, typically SW that is used to communicate with sensors, drivers and combining data from those. This level is the foundation, both upper levels of SW as well validating HW components, both during production and developing prototypes
2. Middle level, typical level of SW that is highly dependent on running correct HW and providing the glue to present a usable product.
3. Top layer, typical different add-ons that will enhance a product that can be added/removed quite easily to a product. Can be developed, if design rules are in place, on different HW but need to keep performance and other restrictions in when doing so.
[The differences]
On top level, sw can be developed very similar to pure sw project, there are deadlines etc but most sw can be developed on emulator or different hw.
The other levels have a much deeper relationship with the hw, meaning the development must be aligned harder with developing hw and following the deadlines it have. Two main reasons, building a hw can cost a lot of money and takes much longer to correct mistakes. The priorities, business value must focus on enabling use of hw when this is needed. A common mistake is to set all business value is something end-user will go wow about, I.e cool features that will be noticeable instead hygiene factors, but you-must-secure basic functionality first, if this is not covered - there is no need to look at the wow-factor.
Sorting this out is hard work for a product owner, since understanding end-user need is different from understanding the process of developing hw, meaning it is often made by different persons different organizations even.
[What to do]
As for all other project, it needs a product owner or champion. With a product owner I mean an appointed person with the assignment to make profit of the product that the project produces. The product owner will have final call if needed of what should go into the product thus, a product owner has enough knowledge of both HW and SW to know what is more important.
Without this role or if the role is distribute to different organisations all projects will end up with misalignment of resources - stronger part-project-owner will sell their part better and draw more resources to this. If this is upper layers you will end up with lots of people wanting to add cool stuff (most really good), but not enough to make the basic features work in a timely manner. This will not happen overnight, it will grow on each organisation and settle as an accepted way of working. At this point it is both hard to realize you have a problem and even more so get out of the habit.
There are probably a million reasons to why it ended up in this situation, but if you realize you have a problem your main focus should be how to get enough authority to one product owner instead of finding the reason to why it went south. Some might argue that you need to understand what and where it went wrong to be able to fix it and in most cases I agree, but on this very complex situation where you might have several stakeholders that claims that they are the main owner of a part of the system, some even stating they own it all (except some parts) you are more than likely to have a very established blame-game in different levels. An establish blame-game will never reveal a true point of making the wrong turn, it is more likely to tell you that there is not really a problem (not in "my" parts anyway)...
I realize that this might seem out of bounds when it comes to agile methods so let me clarify. When you start with agile methods it very easy suggest to have self containing teams, i.e. teams decide what to do themselves which is part if the setup. However, when a team is part of a system there is another governance that overrules on some levels. It should also be clear that I do not mean that the higher governance aims to control teams in details but to take a wider responsibility of what needs to be done.
Without this role or if the role is distribute to different organisations all projects will end up with misalignment of resources - stronger part-project-owner will sell their part better and draw more resources to this. If this is upper layers you will end up with lots of people wanting to add cool stuff (most really good), but not enough to make the basic features work in a timely manner. This will not happen overnight, it will grow on each organisation and settle as an accepted way of working. At this point it is both hard to realize you have a problem and even more so get out of the habit.
There are probably a million reasons to why it ended up in this situation, but if you realize you have a problem your main focus should be how to get enough authority to one product owner instead of finding the reason to why it went south. Some might argue that you need to understand what and where it went wrong to be able to fix it and in most cases I agree, but on this very complex situation where you might have several stakeholders that claims that they are the main owner of a part of the system, some even stating they own it all (except some parts) you are more than likely to have a very established blame-game in different levels. An establish blame-game will never reveal a true point of making the wrong turn, it is more likely to tell you that there is not really a problem (not in "my" parts anyway)...
I realize that this might seem out of bounds when it comes to agile methods so let me clarify. When you start with agile methods it very easy suggest to have self containing teams, i.e. teams decide what to do themselves which is part if the setup. However, when a team is part of a system there is another governance that overrules on some levels. It should also be clear that I do not mean that the higher governance aims to control teams in details but to take a wider responsibility of what needs to be done.
[How do you know if you are in problem]
- Is there any question to who owns decision on what should be included in a product?
- Is there any question to who owns decision on what should be included in a project?
- Is it a common reply when poke in a problem that "this is not my area"
- Are there more noise from teams that want to deliver, but it is not good enough to deliver to, than from teams delivering
- Do you get a feeling each time you present a problem, several stakeholders release their breath when they understand it is not "their" area?
These are some question you can ask yourself, if it is hard to come up with a answer there might be more to find.
- Is there any question to who owns decision on what should be included in a project?
- Is it a common reply when poke in a problem that "this is not my area"
- Are there more noise from teams that want to deliver, but it is not good enough to deliver to, than from teams delivering
- Do you get a feeling each time you present a problem, several stakeholders release their breath when they understand it is not "their" area?
These are some question you can ask yourself, if it is hard to come up with a answer there might be more to find.
[Summary]
I am not sure I managed to stay tuned to what I intended with the post when I started, but let me try to summarize.
- It is very easy to translate agile sw development to run fast with little plans, but this is wrong. You always need to plan enough. And when involving build HW it almost always comes with a lot more costs - the SW that HW has dependency to on need understand and agree with HW development what is needed when. After this, feel free to use any process you need. Agile methods are in many cases even preferable.
- Projects always need a product owner, i.e. a stakeholder that will receive the finished product from the project and be continue to work with the product, producing units, requesting new projects to improve, requesting running changes of the products etc.
- It is very easy to translate agile sw development to run fast with little plans, but this is wrong. You always need to plan enough. And when involving build HW it almost always comes with a lot more costs - the SW that HW has dependency to on need understand and agree with HW development what is needed when. After this, feel free to use any process you need. Agile methods are in many cases even preferable.
- Projects always need a product owner, i.e. a stakeholder that will receive the finished product from the project and be continue to work with the product, producing units, requesting new projects to improve, requesting running changes of the products etc.
