Projectmanagement with scrum part 3

Part 1: The Scrum project management method   

Part 2: The role of the product owner on the client side

• My Scrum Master is my most important partner

• As a product owner, I depend on a strong team. That's why I should always have a good connection to the Scrum Master. The Scrum Master ensures that "his" team performs at its best and implements the wishes of the Product Owner with full vigour and maximum precision. He pays attention to the "fitness" of the team and makes sure that all problems (so-called "impediments") that could stand in the way of the team's success are eliminated.

   

• Do meetings only when it makes sense

• Sure, talking is important. But always and everywhere? Time is money, so question every meeting. Everyone is motivated when they leave a meeting with a clear message. So clarify beforehand: What do we want to achieve as a team? Do we need an additional meeting for this? Do I have other options? The Scrum Master is always there to help you as a partner.

   

• Trust the power of the team

• It is not the constant control and prescribing of the next steps that leads to a better result. Trust in self-organisation. If you wait and let the team make the technical decisions, you will quickly notice how the team develops, how it contributes to the content and what enormous performance is created. The concrete technical implementation of requirements is the team's daily bread. It is exactly this knowledge and experience that you want to use for your project!

   

• You do not need to know everything

• You have a professional team with experts. Wonderful, so you can sit back, trust their suggestions and also estimates - after all, they are not doing this for the first time.

  This gives you the freedom to concentrate on your professional tasks. The team will find ways to implement them efficiently. That is real teamwork!

   

• Be a Servant Leader

• Good leadership is leadership that is not perceived as such. And with the team-oriented way of working in Scrum, there is no classic leadership. You are part of the team and specify the technical requirements. Together with the Scrum Master, you are a "servant leader".

   

• Do you know your stakeholders?

• If you know your stakeholders and understand their views, you can bring their wishes into the project. Because their needs are more important than your personal preferences. This way you support the team and keep the "political" communication away from the team.

   

• The Time Box is untouchable for you

• Time-boxing" provides planning security. Everyone in the team knows how long a meeting will last and how much time is left for the actual work. Everyone focuses and gets to the heart of the matter. Important issues come to the fore and unimportant ones are clarified elsewhere.

   

• Use your Scrum Master and the development team

• As a product owner, you always have an overview of the status of the work, the quality and the speed thanks to the development team and the Scrum Master. If you have questions or want to clarify something:

  Talk to the team. If you have questions about the process, if something is wrong or you don't like it, or if you have suggestions for improvement: Talk to the Scrum Master.

   

• He who does not ask remains stupid

• You can't ask the wrong questions. So don't mince your words. Because you have to bring clarity to all issues. Ask what the stakeholders really want and ask the team if they have fully understood this. Ask the Scrum Master how fit the team is at the moment and what you can do to maintain it.

   

• The project is a matter for the boss - but the boss is not there!

• The web project is increasingly becoming the decisive communication and work tool. Therefore, it must also be a matter for the boss.

  First project meeting: For 45 minutes, the new design discussed in advance is presented and the next steps are recorded in the working group. The door opens and the boss comes in, has the result shown to him without being asked and picks the design apart without knowing the context. After 10 minutes he realises that he lacks background knowledge and the next meeting is waiting. He leaves the working group with the advice to revise everything again.

  Please don't do that!

  Good managers delegate and trust their employees and thus their product owner. The product owner makes the decisions within the project. Of course, he or she communicates the results and involves his or her superiors.

   

• Product owner is a stranger - please don't!

• Who is to steer the project? Internally, no one is readily available. Day-to-day business keeps everyone firmly in check. How is one employee supposed to take care of the web relaunch for 4 or 6 months? So a new position is created and filled with a new employee.

  This is a good approach if there is a willingness to give the work of a product owner the necessary quantitative significance. However, it is usually a bad choice, because the new employee first has to establish his or her standing. They are unfamiliar with the internal contexts, they do not yet know the informal channels and so they can easily run into walls.

  Relieve an experienced staff member of other tasks so that she can focus on the project with all her internal knowledge.

   

• Scrum is nice, but rules are made to be broken!

• "I can't take part in the planning today, but it will work without me." and "Today we have to talk for at least 120 minutes instead of 60 minutes, I have an idea." "Scrum, but..." - as this softening of rules is also called, only leads to loss of time, to frustration in the team and thus to poorer results. One should be aware that the few rules that exist in Scrum each have a very concrete reason. Ultimately, each rule protects either performance, product quality and/or your budget.

  To illustrate with this concrete example:

  If you extend a core meeting with 4 developers, 1 designer, 1 Scrum Master and 1 product owner with a time box of 60 minutes to 120 minutes, then it will cost you 7 hours. That is 7 hours in which a Scrum developer could implement many of your requirements that have a high business value for you. For this reason alone, the Scrum Master would intervene at this point.

   

Agile project management with Scrum from the customer's point of view

Part 1: The Scrum project management method    Part 2: The role of the product owner on the client side