10 mistakes of young PO (conclusion)
And now 3 main mistakes. If they are done over and over again, I’m afraid that from a young PO you can go into the role of a former PO. Start here and here .
8. You cannot dismiss anyone from the dev team
Otherwise the whole team will be demotivated
In reality, a self-organized team is not afraid to discuss problems, honestly voice to another member of the team that "in fact, we are not going to chat here." For example, if a person appeared on the team - a procrastinator, they discussed all this in retro, realized that “this will not work” and with the words “ This is Sparta ” ... said goodbye to him. (I don’t even know how to continue working in such a team :)
RO - he is the manager, the owner of the budget, and, accordingly, if he does not immerse himself in the affairs of the "self-organized" team and does not monitor its "health", it is unlikely that such a story will end well. You and the team tried different things, but it doesn’t help? Then dismissal, warning, and all that stuff is your area of responsibility. Although the best practices indicate that such decisions should be made by the team, very few of them grow to such a psychological level of interaction.
I want to talk about two cases from my practice. Our team has 2 cool examples.
9. Any business must be completed.
No, not any. In general, an extremely rare thing needs to be completed in product development. Of course, if that very end is correctly defined :)
For example, you came up with a feature, lied about it, she lives in the imagination, the prototype is beautiful, and she also has that button blue with a white border. Fortunately, there is a life-saving mvp that will not let you do anything superfluous. The client will receive first of all the most necessary, and only after that - something necessary, then additional and only sometime something for the soul.
Many PO beginners worry that they haven’t done any of their ideas (epic) “from and to”, this feeling makes you take tasks that will bring little value, but will spend a lot of resources, meanwhile the client will suffer from a problem that you could quickly and just decide.
This way will work by itself if the tasks have a precisely described user story, I will draw how it looks:
10. Work and fear losing your job
You come to a new company / start a startup, but at the same time you work and make decisions based on past experience. In the new realities, there will certainly be people / rules / opinions who will tell you that here “it’s impossible ”, but “it’s not accepted ”, and “do not utter this word at all. This becomes an artificial restriction for the product, it is often based only on speculation, subjective opinions and fear of other people. But you do not know this, and build concrete walls around your product, which they do not allow him to develop.
Example. Our team spent six months without servers for the product, because “such rules - everyone here waits for a server for 6 months”, they cost like Ferrari F60 America, and cloud hosting is prohibited. Ok, wait - the server under the table is not so bad.
Take a chance, try it. Didn’t work out? Try again! Or it turns out you don’t have to build a concrete wall or it can be broken, or the worst thing that can happen is that you will find out that it is really impossible to demolish it. But along the way you will find out the context of the problem as much as possible, you will find more options for solutions. Yes, most likely you will anger someone with your attempts to break something that cannot be broken. Nobody will punish you for trying to do everything possible for the product and the company, and even more so they will not fire you :) the first three times - for sure. On the fourth - it’s possible, but you did everything you could.
By the way, now we are hosted in the cloud, and deploy virtual machines in 1 minute in the quantity in which we consider it necessary. And I'm still working here :)
8. You cannot dismiss anyone from the dev team
Otherwise the whole team will be demotivated
Yes, in the classics of the genre, the scrum team is self-organized, and you sit on the “throne” and prioritize the backlog. No matter how)
In reality, a self-organized team is not afraid to discuss problems, honestly voice to another member of the team that "in fact, we are not going to chat here." For example, if a person appeared on the team - a procrastinator, they discussed all this in retro, realized that “this will not work” and with the words “ This is Sparta ” ... said goodbye to him. (I don’t even know how to continue working in such a team :)
RO - he is the manager, the owner of the budget, and, accordingly, if he does not immerse himself in the affairs of the "self-organized" team and does not monitor its "health", it is unlikely that such a story will end well. You and the team tried different things, but it doesn’t help? Then dismissal, warning, and all that stuff is your area of responsibility. Although the best practices indicate that such decisions should be made by the team, very few of them grow to such a psychological level of interaction.
I want to talk about two cases from my practice. Our team has 2 cool examples.
- The first example. Forced . the developer took part in the planning, discussed features, supported, fumbered, and then could say: “Guys, I have 2 months training.” He came back, all in a circle again. But the team itself could not tell him anything, did not want to and was silent, and part of the work stopped, the whole team delayed these planned tasks and, of course, did not have much time. I watched this for a long time, talked with the developer, as a result, we said goodbye to him. And nothing happened to the health of the team, everyone said: “Yes, the right decision, but in general it would be nice to make such decisions as a whole team” (matured :)).
- An example of the second . Positive . The developer suffered from procrastination, it is completely not clear what he was doing. But on the retro, the team said it wasn’t good, they described the pros and cons of the person from their own team. And you know what? We realized that we simply did not understand each other. The developer began to work in a different way, he manages a lot, writes better. That is retro enough. So sometimes the team’s enlightenment also comes if there is a good scrum master who will help start talking.
9. Any business must be completed.
No, not any. In general, an extremely rare thing needs to be completed in product development. Of course, if that very end is correctly defined :)
For example, you came up with a feature, lied about it, she lives in the imagination, the prototype is beautiful, and she also has that button blue with a white border. Fortunately, there is a life-saving mvp that will not let you do anything superfluous. The client will receive first of all the most necessary, and only after that - something necessary, then additional and only sometime something for the soul.
Many PO beginners worry that they haven’t done any of their ideas (epic) “from and to”, this feeling makes you take tasks that will bring little value, but will spend a lot of resources, meanwhile the client will suffer from a problem that you could quickly and just decide.
Turn off the perfectionist and have a great feeling for a while. There will come a time when the client will be quite satisfied, and it will be possible to do all the tasks at the end of the backlog (although I myself have not yet been at this stage of product development, but understanding this helps to make decisions easily).
This way will work by itself if the tasks have a precisely described user story, I will draw how it looks:
10. Work and fear losing your job
You come to a new company / start a startup, but at the same time you work and make decisions based on past experience. In the new realities, there will certainly be people / rules / opinions who will tell you that here “it’s impossible ”, but “it’s not accepted ”, and “do not utter this word at all. This becomes an artificial restriction for the product, it is often based only on speculation, subjective opinions and fear of other people. But you do not know this, and build concrete walls around your product, which they do not allow him to develop.
Example. Our team spent six months without servers for the product, because “such rules - everyone here waits for a server for 6 months”, they cost like Ferrari F60 America, and cloud hosting is prohibited. Ok, wait - the server under the table is not so bad.
Take a chance, try it. Didn’t work out? Try again! Or it turns out you don’t have to build a concrete wall or it can be broken, or the worst thing that can happen is that you will find out that it is really impossible to demolish it. But along the way you will find out the context of the problem as much as possible, you will find more options for solutions. Yes, most likely you will anger someone with your attempts to break something that cannot be broken. Nobody will punish you for trying to do everything possible for the product and the company, and even more so they will not fire you :) the first three times - for sure. On the fourth - it’s possible, but you did everything you could.
By the way, now we are hosted in the cloud, and deploy virtual machines in 1 minute in the quantity in which we consider it necessary. And I'm still working here :)
All Articles