Agile methods when developing SW to new HW products

[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.

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.

[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.

[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.

[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.

Analyzing a problem - what should be solved - really

As an engineer you are probably very skilled at solving problem and in many cases it might even be a passion to you, which is good. However you need to be a bit picky about what problem you should solve...

In normal daylife with simple problem there is no need to think - just do it. If you have a flat tire - fix it, etc. But often a problem will aquire some effort in fixing then it is always useful to do some kind of analysis to make sure you understand the problem and focus on a root-cause instead of a symptom. My favorite tools for this analysis can be found here.
http://blog.crisp.se/2009/09/29/henrikkniberg/1254176460000
Also good example of focusing correct
Problem: Smoke in room
Solution: Open window

Or, with some more effort
Problem: Smoke in room - <so what> - hard to breathe - <so what> - will pass out shortly - <why> - smoke form sheets - <why> - cigarette burning, laying on sheets - <why... wait, what??>
Solution: Put out cigarette, make sure sheets are not on fire, open window

Meaning, make sure what/why it is a problem and then make sure you find the root cause and then solve. It might not even be a problem, you could be at a disco with cool smoke coming toghether with strobe light...

Performance feedback to team members/co-workers

As a Line or Project manager you most likely get involved in evaluating people. As Line manager - you need to gather information from other about your direct reports, as a project manager you are often the first contact of a line manager to give feedback about your team.
As a general rule, but not often applied, I suggest that both Line and Project managers should keep some kind of diary where short notes can be added of the team - this way you will have a good draft ready once it is time to make it official.
For Line managers, to get the complete profile do not just ask project managers or people leading your direct reports but also peers and if available, people who is reporting to the person being evaluated. Also, keep focus on open questions instead of Yes/no questions - it is important to get a wide picture before you narrow it done to your perception. When this is done you need to consider what baseline each report is referring from, i.e. are there any comparison.
Key topics to get elaboration on for each co-worker can be used by a line manager when preparing the questions also guidance to whoever get assigned to evaluate someone else.

For project managers, you should take time and keep notes as suggested above otherwise when you are asked you will base your review on very recent events and/or only major events. Remember this another tool to help your team to evolve as well as a good opportunity to sort out what you really need from a team. There is of course a valid point to go through your thoughts with the individual directly, having a healthy dialogue will probably gain some feedback as well.

Role description of a Project manager

As described in previous post I was assigned a small task to write a role description and published a few thoughts on it. Now I have written it and here are my findings/suggestions:
- Make sure you understand what is expected by the role from "outside" - do not only rely on what is the current work tasks at hand
- Formalise the expectations/output
- Based on the expectations - create the major task-groups with a sane level of details
- Based on the tasks - what input is needed, and a rough idea where this information is available.

I.e. write is from the end to the beginning, and make sure to have a review after each step. Doing it this way you will stay tuned to expectations and need, if you start with with the input/info available you will likely create tasks and output based on that instead of need.

This can and probably will put light on information that the role is depending on but no clear interface - note them and request them to be address of whoever commissioned your task. The avalanche has started...

What is expected in a role description

When you start a new assignment or a new job you might encountered "Role description", a document or similar that should describe what you now are expected to do. I am not sure how important it is in the long run, since reality changes more often than the description - chances are that it grows obsolete. At least in projects the outcome are more depending on a team effort than a bunch of "sandboxes" with defined interface doing what is expected.
A document to help you get familiar with some basics will be helpful, but so will a introduction by a experienced person. Of course a introduction followed by some version of mentoring will always outweigh any documentation but that requires time and commitment from mentors. And to get that effective would require guidelines to potential mentors, i.e. what needs to be address during an introduction etc.

So, who should the description help. I recommend that a description if firm on what is expected by the role, and more vague of close interfaces. This will get the benefit of being clear on what is expected and will get an attentive person driven to clarify what she needs to succeed.
This kind of description will probably stay more up to date as well as it have less detail on what is owned by others. It is also useful for any mentor as guideline, if the organisation have opportunities to have mentors - updating and maintaining the document would be a given task for them.

This how I address the current description I am working - and intend to publish a bit more details here once I tried it.