I agree that this concept can backfire (fine, I'll pay the fine so I don't have to come), and there are solutions to that (double the fine for each offense). I also agree that if the majority of people need a fine to appear at the standup, then there is a much bigger problem occurring.
So, that background aside... one of the conversations appropriately focused on the issues we were having with the Product Owner. Why didn't he want to participate? Why was this an issue?
Lesson learned on that point: when this company went agile, we trained the developers, then the QA and analysts. Following the rules of Scrum & XP, we understood the metaphor of the Chicken and Pig very well. Unfortunately by following this rule, we optimized the team but de-optimized the whole value stream. It wasn't until the PO's got some agile training that they understood how to evolve for the new agile world.
This post is in response to the following comment in regards to fining the PO for being late to the standup:
Why wait for the PO for a stand up? The PO should not be in a position to cause the problem. We try and utilize the Chicken and the Pig approach.And my response:
There are many people who feel the PO is a member of the team: http://www.danube.com/blog/dan_rawsthorne/who_is_the_project_manager_in_scrumThe last thing you need is for a team to go to the sprint review and demo lots of software that fails PO acceptance. Instead of making decisions in his absence and hoping they were right, avoid this waste and just treat him as a team member. If you can't do this, then get a proxy in place (lead analyst), or get direct access to the most important users to reduce the risk (beta customer).
Thus making them a Pig.
Also, the chicken and pig concept is dead in my mind. It's a coping mechanism for bad managers: http://www.langrsoft.com/blog/2008/08/pigs-chickens-and-asses.html
As our agile team matured, we found that many of our early retrospective discussions led back to the fact that the PO wasn't accessible enough. When your PO is the voice of many customers distributed globally, the PO is very important. If you have direct access to your customers (example: internal employees), then this might not be as important.
Your statement that, "It wasn't until the PO's got some agile training that they understood how to evolve for the new agile world" jumped out at me. One of my "hobby horses" is the lack of training many folks associated with an Agile adoption seem to get at the outset and then have to try to "learn-by-doing." And an unengaged PO produces a pretty dismal initial agile experience.
ReplyDeleteIn the past two years, I have worked with, among others, two large, global firms doing agile startup efforts. One had a very engaged PO "function" (a main PO and a PO rep for every Scrum team (5)) while the other did not. The first was able to get a lot done and the PO folks participated very effectively on and with the teams. The second had BAs as surrogates for real POs (since they had to go back to real customers/business owners for approvals): the BAs were not happy with their role, felt un(der)trained, and I believe the teams could have made even more progress if this has been fixed earlier in the experience.
I do think that PO availability and communication can be achieved without thinking the PO has to be with the team all the time. But I rather liked what that first company did and would always be glad to see a PO (or PO rep) working daily on the team.
Scott- Thanks for the supportive comments. I'm also not sure that the PO has to be always present, but they definitely have to recognize their importance to the team. Without training, they continue in the "old way" and feel that writing requirements down for the team and pitching them over the wall is good enough.
ReplyDeleteI too have been part of both scenarios, one where the PO was considered as part of the team and one where the PO just left it up to the team to make decisions. In both situations, they went through Agile training. However, the biggest difference was that in the second organization, senior management was not fully on board with agile and so, the PO did not see the need to be part of the team. I strongly believe that POs do not understand the full extend of their responsibilities until they are in that role.
ReplyDelete