First PO job application & test work
Hello everyone
So I have just come off of my first test time as an applicant for a scrum product owner position and I am thoroughly beat. I know that a lot of things went wrong but I do not really care about how the ideal situation should be but rather what I could have done better. If any of you have any input on that after ready my account of the events please feel free to comment as openly as you like.
So I applied for the position as a scrum product owner for a product that is a online platform for medical services. As I have an extensive background (~20 years) in Web related project management and full stack developer the topic of the product didn't pose any big hurdles for me.
After getting through the initial interview and a second interview with members of the board I was invited for a test period of 3 days. I was provided with a possibly real idea for a new feature for the product. I was then asked to set up the backlog for the product including prioritizing and milestones and then prepare for a sprint-kick off meeting for a 4-week sprint and a team of 8 developers. The result of this was to be a mock sprint 1 planning with a duration of 2 hours (this was cut to 1.5h) later on.
I spent the first half day discussing possible technological solutions with the person who came up with the idea, the TPO of the company and two of the developers that were made available to me. I then had a clear vision of what the feature could be and how it might be realized. I spent the rest of the time creating features and backlog items for said features. In the end I had 6 features containing about 50 backlog items. Two of them were very rudimentory as they were to represent a vision of what the stakeholders would like the product to maybe become in the future. I do not think anyone ever looked at what I prepared and only what I was able to show during the presentation (close to nothing) of this actually mattered.
The way I went about writing the user stories was pretty straight forward who-what-why. I set up the aceptence criteria as specific as I could without knowing any details. My assumption was that this would be a point of discussion during the sprint planning and that I would be able to finalize the wording of the acceptance criteria together with the team.
This is how the final test / mock-sprint-planning went:
- 15 Minutes: I explained the vision of the product
- 15 Minutes: I explained my milestone planning and why I was basing my assumptions on (this was probably too much)
I then started by explaining the features and going into the first user story items. This is where things started going completely wrong. After almost 30 minutes I was still not able to get past the first user story as team members were trying to go into details on how an implementation could be done. The scrum master wasn't really helping, as the only thing she really did was point out words I had used that might be inconclusive. I tried to cut things off - which did mean that I interrupted a team member once or twice - trying to explain that this was not the time to go into details. My (naive) plan was to at least explain the basic concept of my sprint planning to the extent that I would be able to do a planning poker for 4-5 user stories. As the also wanted 15 minutes of the total time for their internal discussion I was left with less then 45 minutes to do this - which was futile.
the criticizm I recieved was as follows:
- I spent too much time elaborting on the vision of the product
- I cut members of the team off (yes I did)
- I did not have focus (I tried hard but I failed.)
here are the questions I have:
The vision is the one most important thing for me as product owner. The criticizm was, that the team does not need really need to know the vision, all they need is work items they can pull. I do not agree with that - if the team can not share in the vision I do not think that I am doing scrum. I could just do kanban but that was not the position I was applying for.
Should I have even attempted to prepare a mock-up sprint planning under these time constraints? I knew from the start that I would never be able to cut a minimum of 6 hours sprint planning down to 1 hour. I thought I could get away with those 4-5 items.
I know cutting off others is not ok but under the time constraints what was I supposed to do? (I did not do this in a rough manner.) Just sit there, wait and watch the clock running off?
After the whole thing I was told that the team members didn't really know what I was trying to do because they have never worked with scrum before. I knew that the company was transitioning but as the person I was working with was presented to me as the "temporary product owner" I just assumed that I would be taking over a scrum team. I probably should have tried to find out more about what the current state of scrum/ agile was - but is that really also on me as someone applying for a po position?
Thanks for any input!
What emphasis did you, or anyone, put on agreeing and then committing to a Sprint Goal?
No professional knowledge is required, but:
1. Organizational strategy and vision, strategy and vision extending to the product
2. Priority
3. Maximize the value of products from strategy and vision
4. Responsible for ROI
One purpose of an interview is for the candidate to find out whether the organization is a good fit for them.
From your answer and your actions, it sounds like you have certain expectations from an employer, and perhaps one conclusion is that this was not a good fit for you.
It's obviously not a completely fair test, and it seems strange that the organization don't appear to have made much allowance for the team's lack of Scrum experience, or the high level of stress there would be from such a tight timebox for a new Scrum Team to plan a 4 week sprint on a new product, having done no prior refinement together on these items.
There is a reason the Scrum Guide allows up to 8 hours for this event.
Also, continuous improvement is an essential aspect of Scrum; so in a real world example, I would expect the Scrum Team to find ways to improve Sprint Planning over time.
But it's good that you're using this as an improvement point.
In terms of what you could have done, like Ian is hinting, there should probably have been a strong emphasis on the Sprint Goal.
Perhaps you could have tried to take control of the situation from the outset, by setting the expectation of your ideal Sprint Goal, reminding everyone of the timebox, and seeing if you could agree to find a mutually acceptable Sprint Goal within the timebox, even if a lot of the specifics would have been unclear within that time, the Development Team might have embraced uncertainty, had the Sprint Goal provided enough flexibility, and particularly if there was trust that further discussion could be had around acceptance criteria and the specific details at a later stage.
The vision is the one most important thing for me as product owner. The criticizm was, that the team does not need really need to know the vision, all they need is work items they can pull. I do not agree with that - if the team can not share in the vision I do not think that I am doing scrum. I could just do kanban but that was not the position I was applying for.
I see this as important, whether using Scrum, Kanban, a combination of both, or any other method for complex product development.
If the Development Team understand why, they are more likely to have better conversations and make better decisions than by just taking tasks and processing them.
@Ian: That was out of the question for me in that time frame. I was just trying to have 4 user stories understood so that I would be able to explain why planning poker is important to me and what I try to find out using it. I could not imagine how to actually commit to a sprint goal within those constraints but you are right - that would have been something I should have at least thought about.
@Simon Thank you very much for your thoughts.
It's obviously not a completely fair test
I think (hope) that everyone acknowleded that afterwards. I was obviously a test balloon (that burned). I believe the division director responsible for the transformation just gave some people the task to come up with ideas for my test work and never actually put much thought into how the whole process would play out. I think the idea I was presented was great and the team members I talked to were very helpful. I don't think the division director has much experience with scrum (if any at all) just a romantic vision of what things can be like. I will recieve the final feedback next week - I think he was dissapointed in how things went (as was I) and he has to sort everything out before he makes a descision. It is definately not an easy one and I am also still not certain whether this is really good for me. Considering that I really love the work of a product owner and here, not in any one of the larger technology cities in germany, I do not have many options. And I want to get started on my scrum journey some time... I am 40 now and If I keep working as a developer for another 5-10 years I don't think I will ever get that opportunity. :(
there should probably have been a strong emphasis on the Sprint Goal
I don't really see how I could have done this without beeing able to explain what we want to do. But I think this shows my main flaw: I didn't really consider the time constraint at all. I should have just thought of something that could be acchieved in one hour instead of accepting that I will fail and just try to make the best of it. Of course it was not obvious to me in the situation that I was accepting failure - but looking back that was obviously the case. I knew I needed much more time to do what I was envisioning but I did nothing about it.
the Development Team might have embraced uncertainty,
The uncertainty factor was actually a big part of my planning and I had a (I think) pretty nice approach to that. I did mention my personal expectations for the sprint goal in milestone planning, which they liked, but I never got to the point where we could have committed as a team. The two relevant developers (one was from a different team and was just there for the numbers) actually said that they were motivated and would like to start exploring the ideas I had laid out and start "developing this thing". This actually made me pretty proud because they were saying this after just half an hour of me trying to explain what we wanted to do.
On the other hand I always have it easy with developers because I am one of them and I have a harder time speaking with management. They actually called me speaking with the developers "developer latin" (I can't find a better translation) meaning that they had no idea what we were speaking about. I should probably try to avoid that kind of thing as hard as possible when I am not just talking with the developers.
Taking your feedback (Ian and Simon) I think that understanding the common vision is not as important as I made it out to be. Considering the constraints I could have planned to elaborate on this later on and tried to focus on getting the first sprint on track even within these big limits.
Thank you very much for your thoughts! I really believe that I know now where I went wrong. Instead of just trying to bulldoze my way through the constraints I should have thought about what was most important on a more minute level. I do not need everyone to have a common vision - all I need is an agreement of how we are going to get started and then I would have had 4 weeks to elaborate on and explain the vision.