Q:A friend was telling me about a new challenge at his workplace where a consultancy is structuring some key I.T. projects to make the business more agile. The particular issue was with finding product owners for each of the teams in the projects. In the short term senior management is persuaded that very experienced key people – some with, and some without an I.T. background – need to be freed from day-to-day responsibilities to become product owners, but longer term they will need to return to their day jobs, so replacements will need to be recruited or trained. Issues we discussed included whether the new product owners would be sufficiently empowered and given access to adequate training by their superiors and how to encourage this to happen. Also, when those POs do “return to the fold”, is it reasonable to expect that their replacements will just pick up the empowerment and training in the handover and on-the-job or will that also require special attention? Can anyone see any issues with this approach or suggest ways of increasing the chances of successful outcomes?
Ivor Chomacki – Solutions Analyst
The Panel’s Answers
In my last organisation I encouraged the business to supply the Product Owner. Given that all projects are business projects then the business should provide someone who is responsible for the business outcome. This worked very well for us. However, we were constantly training new Product Owners. In my view this is a good thing as it helps with the organisational cultural change. To retain some consistency we created a product owners team, where we put Business Analysts on the PO team, to provide support with the detail and to carry out analysis. For large projects, bringing new product to market etc. we had full time POs but often they were part time. This worked for us as the BAs were full time. The Product Owners where always responsible for the backlog and made decisions on priority. As they were often senior managers from the business the empowerment issue was never a problem as they often reported to the executive project sponsor anyway, and were accountable for the outcome.
Roy has touched the key matter here. A PO should be empowered to make decisions and accountable for the results. Imagine that the PO has the budget and pays for the team every sprint, in turn the team builds a product that generates revenue. The thing however is that as you say they never have the time .. this is why BAs come into play. I call the ones I have recruited “Agile Analysts” there is one thing however that I would recommend. Do not make them a part of the PO team, make them a part of the delivery team. This way they will be responsible for delivering the product. The PO’s job will be to prioritize and use stories but the team has to figure out the “How”. Often it requires a lot of trust on the PO’s side … but he or she still has the reviews
I think it is a reasonable approach to put people with good knowledge in the job in the short term and then recruit to fill the roles permanently. As for a hand over, each person is different and comes with different knowledge and personalities.
One approach I really like to hand over is to pair for a while, and then pair less. If you measure the amount of communication and questions asked between the new person and the old person, and when this drops to a low level, you can consider the hand over complete.
I literally saw this working where the new person would get up, walk across the office, and ask her question. When the person stopped walking across the office so much, the old person could move on to something else. Obviously with digital conversations this is different, but the approach could be the same.
The main point being that for a time, both people are pairing on the same job. Don’t rely on documentation hand overs or too small a time together. A few days is not going to cut it. At least a sprint, more like 2 would be better.
Large Scale Scrum has a concept of a technical role fulfilling this role until a true PO who understands the business can be found. This role whilst being performed by the non business person is called ‘Temporary Fake Product Owner’. I think by naming it thus, we can see how important it is to have true POs as POs and not techies.
February’s Q&A Panel
How should a scrum team deal with a situation where the “scrum master” / team leader does not appear to be following scrum principles and values?
January’s Q&A Panel
The passing of another year allows us to pause and reflect on the previous year, as well as to set out a path to further develop and address the challenges for the upcoming one.
What then, for you, were the key learning points, either from the numerous thought leaders in attendance at AWA events in 2015 or from your own experiences, and where do you think there is further work to be done in 2016 to ensure even more success with respect to scaled agile adoption?
Enter a Question
Volunteer to Answer