I’ve just finished reading the book called “Agile Product Management with Scrum” by Roman Pichler. I had really enjoyed it. It provides valuable insight regarding not only about the Agile Product Management but also tips and tricks to become a great product owner.
At the last part of the book, there was a section that I found very interesting and insightful. It’s the following table that has been referenced to Lyssa Adkins, author of “Coaching Agile Teams”.
When I’ve came across this table, I’ve openly criticized myself and think about if I’m having attitudes of items in the “Don’t” part. My sincere feedback to myself was there are times I might fail to “protect the team from outside noise” and instead of “incorporating change between Sprints” there are Sprints in which I allow change to jump in to. I thought I’m doing not bad at the other items. I’ve decided to ask openly to the development team their feedback by commenting for which item they think my overall attitude is on the “Do” part and for which in the “Don’t” part.
Generally speaking, they agreed with me regarding my improvement areas that I’ve found out by doing self-criticism. Almost all of them thought that it’s very positive and bold move that I’m asking their feedback in this way. On of my colleagues told that he is aware of the pressure I’m carrying on my shoulders and he is ready to support me as much as he can. It made me feel better that they are sensible to the challenge of my position and do empathize. What I’ve done later on upon receiving their feedback is I’m no longer including the development team to the email exchanges I’ve been doing with the shareholders in order to isolate them. Earlier I was keeping them in the loop so that we can be aligned as a whole team. Besides, I’m putting more effort not play to much with the SBL and keep the ground as stable as possible.
In a nutshell, as product owners we are the ones who are carrying the biggest responsibility to maximize the value delivered my the development team. As a result, we are the ones who are under fire most of time. In order to become great Product Owners we have to improve our expertise and acquire the know-how required for the domain while being kind, patient, empathetic, open-minded and also cool 🙂
From my perspective, the beauty of Scrum framework is running Sprints for a short period of time (typically 2-3 weeks) and at the end of it being able to judge the team’s overall performance objectively. Setting a goal for a few weeks timeframe and going for it enables the team to get disciplined and stay focused. Historically, we had 6-9 months long projects with potential delays. This leads the teams easily jump into the comfort zone and adapt a relaxed and ‘take it easy’ type of attitude due to the long time for the project completion. Generally speaking, the human nature has a tendency to delay most of the work to be done towards the deadline. ( Remember your university finales :)) Therefore, setting digestible, S.M.A.R.T Sprint goals developing iteratively and incrementaly is an effective way to accomplish significant achievements within a certain timeframe.
Well, how does the team monitor if bringing the Sprint Goal to DONE status is something already secured or it is at risk ? Even though, it’s not mentioned in the Scrum guide at all, best practices propose “Burndown Chart” for that purpose. As the Scrum Institute put it precisely:
The Scrum Burndown Chart is a visual measurement tool that shows the completed work per day against the projected rate of completion for the current project release. Its purpose is to enable that the project is on the track to deliver the expected solution within the desired schedule.
Okumaya devam et “How does the Burndown Chart help us to meet Sprint Goals?”
Let’s imagine a typical Sprint of 2 weeks duration. If the team is delivering software continuously since more than a year it means that the team had run around 26 Sprints past year. Do you think it is feasible that each and every Sprint has been finalized with success? Obviously, it is not surprising that a number of Sprints fail to accomplish the Sprint Goal. Well, even though it’s not the best scenario, a mature Scrum team is supposed to manage mentally and emotionally the consequences of a failed Sprint.
Every professional aims to be successful at personal level. Similarly, everybody enjoys being part of a winning, successful team. Nevertheless, it is very likely that a Sprint could not achieve the targeted Sprint goal and fails due to several reasons such as bad planning, dependencies, challenging Sprint goals, changing scope etc.
Okumaya devam et “How to handle a failed Sprint and how to avoid it ?”