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.

 

Abstract

 

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.

Summary

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.

Description 

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.

Invasion of Agile Hardware at Design East, Boston

Topics around Agile Development have slowly but steadily been making their way into Embedded Systems Conference program. Couple of weeks ago Design East in Boston had several sessions on Agile Development, but most noticeably 3 talks on Agile Hardware. One of them by yours truly. You can find the slides and technical paper associated with it via these links (slides, technical paper).

Agile methods are gaining foothold in embedded software development. Embedded software is not developed in isolation, but it often has strong 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 session summarizes authors observations on hardware development team members and hardware teams working with 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. This session will give you the practitioner’s view to applicability of Agile methods beyond embedded software development.

Slides from Agile 2011

Agile 2011 ended in Salt Lake City, Utah a few weeks ago. It was again great to meet the growing circle of friends in agile community. This year my own conference was a bit different as I submitted two talks and participated in the review process for Agile for Embedded Systems Development -track.

Indeed, we had dedicated track for embedded stuff. It was the 10 year anniversary for agile manifesto and this was the first time the embedded got this much attention. The track had quality sessions and averaged around 20 attendees for each session.

You can find my slide decks via the links below:



Embedded Testing Cycle - the First 3 Years, Markku Åhman and Timo Punkka

James Grenning presented the embedded test-driven development (TDD) cycle already in 2004. Whispers on the hallways of conference hotels tell that somebody is actually implementing this idea. However, there are only few documented implementation details available. Schneider Electric’s fire security team has been implementing TDD cycle as an integral part of the development process for 3 years. Come to learn from their real-life experience and mistakes in automated testing at different levels: unit testing, acceptance testing using simulation, and in real target hardware.




Agile Hardware and Co-Design, Timo Punkka

Agile software development is getting attention also in embedded software development. Embedded system development on the other hand requires different engineering disciplines working together. When embedded software team starts using agile methods, it affects also 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. This talk discusses reasons and ways to adapt agile development to co-design of system development.



Lots of other presentations, including all other embedded track presentations, are available via the conference program site.

Embedded Agile, ESC2010, Boston

Here are the slides and technical paper from my talk on Embedded Agile at Embedded Systems Conference 2010, Boston.

I had a good time at the conference. Hope you can find the material useful!

Abstract. New product development (NPD) is getting more and more challenging. Change happens all the time in all dimensions, including own organization, technology, competition, and marketplace. Agile development is targeted at working in a turbulent environment driven by continuous learning. Originated from software industry, its applicability to embedded system development has been analyzed over the years. In this paper, I present some observations on implications of embedded system development to agile development. I introduce findings on frequent releasing, automated testing, co-design including non-SW development and quality systems like ISO9001.

See you in Boston

I'll be attending ESC 2010 in Boston in a couple of weeks. You can catch me speaking about embedded agile on Tuesday 21st. You can find me somewhere in the conference throughout the week. Let me know if you're around.

Impossible, I Have Never Done That

When adopting agile planning techniques to non-software development activities an often heard argument against estimating the complexity of, say, schematic is:

"it is impossible to say, I have never done that before"

Well, firstly, in embedded software that's the situation pretty much allways, yet agile planning has proven to be efficient enough over and over again.

Secondly, we are living the era of enlightened experimentation. Prototyping hardware is drop dead cheap and fast nowadays. Buying yourself a status of "I have done that once" instead of "haven't done that before" is as easy as deciding to do so.

Thirdly, schematics can be estimated with relative complexity.

Fourthly, Parkinson's law works everywhere where humans are involved. Timeboxing early prototypes will help making the progress reliable and visible. This is however understandably very counter intuitive to the "get it right the first time" camp.

This is what is called up-front prototyping. In contrast to traditional hardware prototyping trying to validate something at the end, up-front prototyping focuses on learning. We may even know that the prototype will not work on most parts, but we just want a reliable measure of how far are we. It is even advisable to design a prototype to prove just one thing. More than one uncertanty will make the work unnecessarily complex.

This distinction between the goals of traditional validating and new era learning prototyping has gotten me concidering a new word to replace "prototype". So far the best candidate is 'product'. Using a word product throughout the lifecycle we would realise that this is aiming to production quality, but the maturity of the desing is evolving.

Of course I'm talking about prototypes that can be assembled within reasonable cycle cost. The bar however is getting lower and lower every day. Interesting exercise is to take your latest embedded development project, draw a bar of development salary cost and a second bar illustrating your prototype cycle cost. You may be surprised how cheap "expensive unnecessary prototyping" is in the big picture.

At least have a taste

We teach our children to at least have a taste before they judge anything as "yak".

We also teach engineers to try out practices before they judge anything as "yak".

"Just try it, if it does not work - ditch it".

TDD (test-driven development) is probably the most difficult technical skill associated with so called agile development especially in constrained embedded environment. It is also probably the most rewarding when in use.

The problem with TDD is that it has a learning curve. To make things worse the earlier debug-later development model has an unlearning curve. Most of the true benefits can concretely be seen after a fairly long period of time. It is not enough just to have a taste before judging, you actually need a prolonged tryout period. You most likely need some external help in the beginning. Your short term productivity suffers because of learning new skills and solving new kinds of problems.

You need someone in customer's role who is willing to talk about long term productivity as well.

Never the less I recommend to just have a taste.

Embedded Blogosphere Gets Stronger

A while ago we took a look at embedded blogospehere. That sphere is now even stronger - James Grenning has a new blog. He is "blogging about Agile Development, especially embedded". That should be interesting enough. There's already two posts about techniques that can be used to test-drive hw driver development (1, 2).

Only few seats left in Agile Finland Seminar

Agile Finland is organizing yet another seminar. It takes place March 4th in Helsinki. This morning there was only some twenty seats available.

Is There Any Value in Values?

Recently I was blessed with an opportunity to facilitate a project retrospective for globally distributed project at the end of their 9th Sprint. Project has development in Europe, China, and Mexico. It is an embedded system development project involving electronics, plastics, mechanics, and firmware development. For all the participants this is the first contact with Agile project management. As a starting exercise we had each participant try to describe the project so far with a single word. The words we got:

• "Chido" (This is something like "cool")


• "Good"


• "Good"


• "Skilled"


• "Challenging"


• "Spectacular"


• "Fun"


• "Speed"


• "Improvement"


• "Interesting"


• "To Be Finished..."

This was interesting in itself.

An article "Manage Your Embedded Projects" in Embedded Systems Design described developer motivators:

• "Achievement"


• "Growth"


• "Work itself"


• "Personal Life"


• "Technical supervision"


• "Advancement"


• "Relationship with peers"


• "Recognition"


• "Salary"


• "Responsibility"

This data is adapted from Boehm, Software Engineering Economics (1981) and Herzberg, "One more time: how do you motivate employees?" Harvard Business Review (1987). So it is a bit outdated. The data in the article is used to demonstrate the difference in motivators between developers and managers. Similar findings are presented in Motivators of Software Process Improvement: an analysis of practitioners' views (2002) and De-motivators for software process improvement: an analysis of practitioners' views (2003), both by Nathan Baddoo and Tracy Hall.

We can go on to generalize this further, and think about differences of people and organizations. Value system of people has been recorded and studied for a long time. Von Rosenstiel and Koch (1) reported that the values have changed towards respecting the uniqueness of people, individualism, enjoyment and discipline,self-development and also material values. That is not enjoyment, it is enjoyment AND discipline among other things. To me the "just words" exercise showed that agile work actually builds on these values; the project was challenging and needed lot of skill, but that just made it interesting and fun - chido. In many cases this however is not following the values of the company, which often are still drawn from old school thinking, like punctuality, hard work, modesty and other values related to duty and acceptance. This discrepancy between values of employee and employer affects the commitment level. Lack of commitment, in turn, reduces employee motivation and effort.

Of course in large organizations values are mostly just lip service, but nevertheless above should lead organizations to rethink the value in their values.

(1) von Rosenstiel, Lutz and Koch, Stefan, Change in Socioeconomic Values as a Trigger of organizational Learning, Published in (Dierkes, Meinolf, Berthoin Antal, Ariane, Child, John, and Nonaka, Ikujiro, Handbook of Organizational Learning & Knowledge, Oxford University Press Inc., New York, 2001).

Yet Another Agile Seminar in Finland

It seems to be the time for another Agile Finland Seminar. It is organized by Agile Alliance, Reaktor Innovations, and F-Secure. Guys have set out to break the old record for short notice:

On October 14th, 2006, I sent an email to the AgileFinland Yahoo! group about the next Agile Seminar taking place only 9 days later. Guess what? Everything went well even with such a short notice so this time we decided to improve and give you an even shorter notice.

At the time of writing this there are 84 seats available. Go get yours...

Agile Embedded Seminar at ELKOM2007

On Wednesday Tieturi organized a mini seminar on Agile and embedded in Helsinki, Finland. The seminar had 3 talks. First Pentti Virtanen gave a general background introduction to agile development. This was pretty much your average pure vanilla intro to agile -type presentation. The second part by Tomi Juhola was titled agile embedded in practice. I had high hopes for this as I though I would actually get to hear some new concrete stories from other Finnish companies practicing agile development. Well, it turned out that the cases presented were first the nice work of Nancy Van Schooenderwoert, and the second Jeff Sutherlands PatientKeeper. No new evidence there. The last talk by Teppo Heikurinen was about testing in agile development. The main topic seemed to be TDD. I have realized that TDD is not so much about testing, but more about design. There was some critique from audience that TDD is just like testing your own work and it has known problems. Yes in that sense it does, but TDD is a design practice which just happens to have a positive side effect of providing the safety net in a form of automated regression tests. At least this is my current understanding. This point was totally left out. Automated acceptance testing was mentioned, but that's about it. Other thing was that the value of TDD was verified with case studies from mainstream programming. I think the biggest issue is to convince the embedded crowd with studies from their own field, since basically people believe that agile has value but are not sure if it can be applied to their domain. Teppo mentioned that there are no studies from embedded and TDD, but Nancy's work is just that! I guess he forgot his colleagues presentation.

The room was full with 60+ listeners, so there is interest towards agile and embedded. I think a lot of people present were not practicing but more curious about what is all that buzz around agile and whether these methods are applicable to embedded (firmware) software development. I hope the event increased the interest even further and in the near future we would get more stories from Finnish companies practicing agile and embedded. It's nice to notice that Tieturi is taking a strong role in promoting these methods for embedded as well.

There's More Under Agile Umbrella Than XP and Scrum

Just a reminder. While Scrum and eXtreme Programming are without a doubt most widely adapted agile methods there are more. I studied many of them while reviewing their applicability to firmware development. Rod Coffin and Derek Lane have also done a nice job writing a two part article summarizing seven different methods that fall under the agile umbrella.

Agile2007: Embedded Agile Discovery Session

On Wednesday at Agile2007 conference James Grenning and Dan Pierce pulled together a discovery session for Agile and Embedded. The room was packed with people with experience on applying agile methods to embedded software development. Well, packed in this context means just over a dozen in a conference with 1150 attendees. Anyway. You really should sign up to Yahoo Agile Embedded group to follow the work of others. There are some remarkable people in this small community.

The discussion had two main topics. First, why embedded agile is getting foothold in the industry as slowly as it is. Several items were identified and the discussion is continued in Yahoo group. Second, that's correct, what else, but agile testing. People had different levels of practical experience, but the main theme was that it is important and it is definatelly possible. On the topic of safety critical embedded software and agile methods, the verdict was that this is not a problem. Safety critical embedded software actually SHOULD be developed using agile methods.

90 minutes was way too short time for anything concrete, but at least the event proved that agile embedded community exists. Thanks to James and Dan.

Jack Ganssle was also present and he posted about the conference in his Break Points column at embedded.com.

The Agile 2007 conference catered mostly to PC types, but some embedded heads showed up.

That post also made it to the latest Carnival of Agilists. This edition of Carnival of Agilists also mentions Atomic Object's approach to mocking the embedded world.

Agile embedded gets some visibility.

Seminar on Agile and Embedded in Helsinki

At ELKOM07 fair in Helsinki, Finland, Tieturi organizes a free 4h mini seminar on Agile and embedded system development on 5.9.2007. While it's free you still need to register.

Does eXtreme Development Exist?

I spent last week in Washington D.C. participating Agile2007 conference. The conference program was overwhelming with over 300 events. However while we have many implications to agile embedded systems development the agile embedded community is still small. So next time you see an agile conference ad, sign up!

Jim Highsmith is a person that has brought together agile community and general product development. I have followed his work and writings closely. He has brought work of people like Stefan Thomke, Preston Smith, and Donald Rainertsen (Reinertsen & Associates) to my knowledge. The latter two co-wrote the book Developing Products in Half the Time. In the panel discussion about agile manifesto there was a Q if the panelists believed that values of manifesto are applicable to development outside SW. (This is what tried also!). Highsmith mentioned a pure HW team that they successfully coached based on eXtreme Programming techniques. In that particular project there was no SW at all!

While browsing for the links, I found out that there is a new book out from Preston Smith:

Flexible Product Development: Building Agility for Changing Markets. It's on top of my wish list.

Embedded Blogosphere

Yesterday was yet another record breaking hot day in Helsinki, and what did I do? That's right, searched the net for new embedded slash agile blogs. I periodically do this, but normally I come empty handed. This time I was happily surprised to find Low Country Software Ramblings by Benoit Lavigne. Benoit was also wondering "Am I alone?", and later found out that "I am not alone after all!"

Via Benoit's blog I discovered Embedded Cork by Ralph Depping and Embedded Gurus. Embedded gurus seem to be a bit quiet, but there is some recent stuff as well. Names behind Embedded Gurus group are impressive; Nigel Jones, Michael Barr, Larry Mittag, Mike Anderson, and Miro Samek.

Keep in mind the Atomic Object Spin Embedded Corner, and But Uncle Bob Archive (James Grenning).

I linked them in sidebar - give them a look.

Story: Spike Up Your Coctail

I posted earlier about short, 6 week, experiment where we had weekly deliveries of firmware and true parallel co-design of plastics, electronics, and software/firmware. I mentioned I would try to write down experience report. Well, it became more like story, and you can find the whole of it here (pdf). (LINK CORRECTED 27/6/2007)


Abstract. Agile development is a term used for wide variety of lightweight software development methods following shared values1. Many of these methods and practices however can be applied to more general new product development. This paper describes a six week project using some of the practices from agile development. These practices included self organizing team, collective ownership, continuous integration, iterative planning, iteration demos, team retrospective meetings, wall work queue, information radiator etc. The project crystallized a vague idea and a draft of electronics schematic into two fully functioning prototypes. It is shown that meaningful functionality can be developed in just six weeks. This is remarkable when reflected against the effort needed in so called traditional process models with formal analysis/design and theoretical proof of concept with heavy review processes. This is possible because of today’s advanced development tools and prototyping technology. Stefan Thomke (2001) calls this an era of enlightened experimentation. Building the working prototype is more cost effective way of reliable proof of concept. Using this approach already in the fuzzy front-end phase of the project would result in huge savings in overall project schedule and budget. It was also noticed that all stakeholders of this project appreciated the approach and considered it as “common sense”. The positive side effect was the team building effect this period had.

Camp Fire

A week ago on Tuesday we organized a camp fire event at our premises. Camp fire is an event about sharing agile experiences, and this was second of such events. Roughly twenty people gathered to an auditorium after the office hours. The audience consisted of people from few different organizations inside the company; developers, managers and marketers. We had two talks; Vasco Duarte from F-Secure was invited as quest storyteller and Mikko Kaijärvi from Schneider Electric volunteered to share his recent experience.




Vasco's presentation was strong, as usual. He talked about top-down agile adaptation at F-Secure in a very realistic way. He did everything but painted a pretty picture about the journey. This is according to his experience, and literature as well, expected. When everything is laid down on the table, it tends to get ugly from time to time. It was interesting to see how within top-down approach they were able to put the whole organization into "agile rhythm". Vasco mentioned that lack of outside help, or not getting outside support enough, was the main thing he would do differently if need ever arises. Vasco presented also some cold quantitative data from theirs and others agile adaptation to support the reasoning for change. It just happens to look like we have more data supporting agile than sequential models ever had. The presentation and especially the Q&A and discussion parts showed Vasco's deep knowledge and understanding of modern project work.




Mikko presented another interesting story in a lively style. His project has applied agile project management and Scrum practices in globally distributed embedded system development project. He estimated that only 5% of development effort is software and firmware, and in addition this is coming from non-agile team. Agile practices were seen as the only option for this project to be successful. The project was started with very vague requirements, barely a vision. Teams were pretty much given. One team in Shanghai, China and another in Monterrey, Mexico, and technology and software development in Europe. The offshore teams had minimal domain knowledge and a huge amount of knowledge needed to be transferred fast. Continuous integration of mechanical and electronics prototypes was a key catalyst for communication. Mikko further identified a clear transition in team behavior from hierarchical - through a single point communication - to self managing emergent behavior actively seeking for best possible solutions in this challenging environment. The project has only been active for five months, but they expect to deliver it in September as originally scheduled. Compared to average project that would be fast according Mikko. Furthermore active early participation of marketing is expected to result in better product as well. This has potential of making yet another example of agile project management practices being succesfull also outside pure software projects.

As conclusion both talks were excellent, delivered by guys that are experienced in both, the project work and giving presentations. Hopefully people were able to walk out with something new and to be able to connect some more dots in their thinking.




After the official part the discussion continued over snack and refreshments. It was agreed that lot of the agile adaptations outside so called agile homeground is about attitude. It is about the shift in thinking towards the art of possible. Just changing your de facto answer from starting with "Yes, but..." to "Yes, and..." offers a huge potential. Vasco's message was "if you really want it, you can do it." The reward demonstrably is there.