Scaling the Product Owner Role

At XP Days Benelux 2013 we talked about why and how the Product Owner role is scaled in organizations. You can find my slides here (pdf).
[EDIT 1.2.2014]
InfoQ Interview on the topic can be found here.
Come to this workshop to learn how to scale the Product Owner role in order to harness the true potential of self-organizing Agile teams. You will learn by doing, but you will be also hear a real-life story.
Using Agile development methods development teams improve their capability to deliver through transparency and predictability. However, this does not bring the outcome companies are seeking if the developed features are not the right ones. The product owner role in Scrum simplifies the interface between business and development. This obviously brings immediate relief in many cases, but in practice, the responsibility of the Product Owner is far too wide for a single person in all except the most simplistic scenarios. Naturally the pragmatic Product Owner works with number of domain experts and other stakeholders. Things in real-life get even more complicated, as organizations have multiple product lines, yet the development should be aligned with the company’s strategy. To add to the challenge, for example embedded system development including own hardware platform development brings additional concerns, such as less flexibility than software development and dependency on external suppliers. To date, the practical information on how to do this remains limited.
During this workshop you will will create a framework for scaling the Product Owner role. Continuous customer collaboration at different levels, with different focus, will also be covered. Your work will be guided with a real-life story linking the exercise to reality.


My Hardware and Co-Design talk at Scrum Gathering

Couple of weeks ago I attended my first Scrum Gathering in the city of light, Paris. On the first day I was offered an opportunity to present my Hardware and Co-Design talk. You can find the abstract below, and slides are available here.


Agile methods are gaining foothold in embedded software development. Embedded software is not developed in isolation, but it has dependencies to hardware development. The system development is facing the demands of ever increasing amount of change and learning. Agile methods aim at helping in these challenges. This talk summarizes authors observations on hardware development teams using Scrum during the past 10 years. Teams have varied in terms of disciplines involved and collocation.

Come to this session to get the practitioner’s view on using Scrum beyond embedded software development.


Agile software development is getting more and more attention also in embedded software development. Embedded system development on the other hand requires different engineering disciplines working together towards a shared goal. When embedded software development begins using agile methods it triggers a need for change also in other disciplines. Agile development emphasizes continuous learning through experimenting and collaboration instead of following a detailed up-front plan. Agile embedded software team expects different behavior in system co-design.

In addition to the above, product development in general and not only software development is facing the demands of ever increasing amount of change and learning. Change happens in several areas, such as technology, competition and marketplace. This is what agile methods aim at tackling. This implies that new product development in general could benefit from knowledge created on agile development.

This presentation summarizes authors observations on hardware development team members and hardware teams using Scrum and agile methods during the past 10 years. Team configurations range from collocated cross-disciplined team (electronics, printed circuit board, mechanics and embedded software) to globally distributed teams of different disciplines. Several real-life products will be used as examples.