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 🙂
Agile transformation starts by individuals followed by teams and at last gets completed by organisation level. This is potentially a long-lasting process with a lot of turbulance. Majority of the people like status quo particularly people who are above a certain level of age. They are quite comfortable in their comfort zone and are not very willing to leave it. I think it’s completely understandable.
On the other hand, Agility is a totaly different mindset. It embraces early and frequent delivery in an iterative and incremental manner. It’s extremely critical that the agile transformation is well understood throughout the whole company not only in technology teams or in part of the organisation. If this is not the case, agile teams will have face many significant impediments and at the end may probably fail. Let’s imagine a case where the product marketing teams are not familiar with agile principles or Scrum framework and in the Sprint review meeting they’ve been made a demonstration of the iteration to be shipped. It’s quite likely that there is a struggle between the Marketing teams and PO regarding the deployment decision of the iteration. PO will very likely to push the deployment so that customer feedback is received and following iterations are improved based on that while marketing guys don’t think the iteration is mature enough to present to customers and might damage the overall image of the product. On such instances, it’s key that decisions that has been made by the PO should be respected by the whole organization. POs those are supposedly selected by the management team, should be empowered enough to have the right level of authority. Without sufficient sponsorship support, POs will be underpowered and lack authority. On those cases it is very likely that they feel overwhelmed and will struggle with the major decision makers.
Okumaya devam et “Million Dollar Question: Are you doing agile or being agile?”
One of the many new practices for organizations going through agile transformation is the move from requirement documents to user stories. I’m quoting from Mike Cohn *:
“User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.”
In the classical approach, there is a requirement document that has been agreed by development and business groups after multiple time-consuming iterations. Even if both parties agree on a document after significant time and start developing the new feature, chances are part of the original scope gets obsolete or changes and things need to be reiterated and perhaps portion of the development efforts have been wasted. This approach is obviously not suitable particularly for time-critical projects. On the other hand, user stories are mutually understandable both for customers and developers and increase the communications between team members and stakeholders. User stories also allow the development team do the practical planning. As Roman Pinchler nicely puts it **:
“User stories are not about documenting requirements; they want to enable you to move fast and develop software as quickly as possible;not to impose any overhead.”
Okumaya devam et ““Working software over comprehensive documentation””
Scrum framework doesn’t mention about how the software is developed i.e. which development techniques have been used. It lets the team to decide which techniques and practices will be used. I think it’s a good idea to share the practices we benefit as a Scrum team thanks to the leadership of the Scrum Master. (A tailor-made adaptation of XP practices)
Pair Programming: All production code is written by two people at one screen/keyboard/mouse. This helps us to ship software with superior quality, less bugs, less iteration and as a result greater efficiency.
Test Driven Development: TDD is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests. Chances are the test coverage percentage of our software stack decreases due to other priorities. In any case, we focus to keep it above a certain threshold.
Unit testing: It's a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed. Unit testing is key for the team to level less buggy software.
Continuous Integration: New code is integrated with the current system after no more than a few hours. When integrating, the system is built from scratch and all tests must pass or changes are discarded. This eliminates manual work and saves time and efforts.
Refactoring: The design of the system is evolved through transformations of the existing design that keep all the tests running. In the lack of refactoring, the quality of software decreases and the probability of major bugs increases.
One of the key responsibilities of a Product Owner is looking after the backlog and building and maintaining the Product Roadmap. The Roadmap is a great tool that provides a visibility regarding the Scrum team’s work and to materialize where the team is headed to. It’s a good practice to communicate the up-to-date Roadmap with the shareholders often in order to let them know which new features and bugfixes are planned over the coming weeks and months and to notify if there is a recent change on the planning.
We are running 2 weeks-long Sprints. At the end of the Sprint Review session, as the PO, I’m presenting the PBIs (Product Backlog Item) in priority order and ask openly to my line manager and other shareholders if we share the same understanding of priorities. From time to time chances are my management team and/or shareholders comment on the priority of PBIs and ask changes. On those instances, we altogether discuss about the motives of these new requests and get fully aligned. At the end of the review we as the team get either confirmation from the audiences regarding the priority order or have an updated list of priority. Here below you can see the ~3 months Product Roadmap of our team. (I’ve intentionally made it blurry for confidentially reasons)
Okumaya devam et “How to build, maintain and communicate the Product Roadmap?”
Every single day, like any other Scrum team in the world, we spend 15 minutes (max) in front of our Scrum board for the Daily Stand-up event. On behalf of the team, I’m confident to share that we really like and enjoy our Scrum board! Here is why;
- We designed it ourselves. More precisely, Projera, the company who is coaching Turkcell during the agile transformation process, proposed a few draft layouts to give us an insight. Following that, we, as a team, gave the team a funny name (Maraba Televole) then designed the logo and the board as well as the layout indicating the various stages of a typical Sprint (PBL, SBL, In Progress, Done, Live, Performance etc. )
Okumaya devam et “How do you feel about your Scrum Board?”
Who should be your product owner ? Let’s assume that your organisation didn’t build Scrum teams yet. Should be the ideal product owner the legacy Business Product Manager or Technical Product Manager ?
I think I’ve hit to the million dollar question, right? In many organisations which are going through an agile transformation and building brand-new Scrum teams, this might be a question causing long discussions. At least, this is my feeling based on my experience in my company, Turkcell. Don’t get me wrong, I really think that this is a healthy discussion and the right decision changes according to the organization’s culture, industry the company is competing in, the size of the company, the management structure and even to the potential PO candidates, among many others.
Okumaya devam et “Who should be your product owner?”
This week, 6th of February Tuesday was World Retrospective Day. I’m quoting from the website:
World Retrospective Day is a volunteer-based, globally coordinated effort to share in the power of retrospectives.
People from different countries around the globe organized and participacted in order to celebrate it.
That’s why I thought that it would be a good idea to write a down a blog post about how our team performs it, perhaps the most fruitful event of Scrum framework.
First of all, this is an entirely internal event lead by the Scrum Master closed to any stakeholders . Typically, we organize it just after the Sprint review scheduled for 2 hours (we run 2 weeks long Sprints). At the very beginning, we have a quick chat about the past Sprint followed by the D.A.K.I. session. DAKI is the abbreviation for:
Here below you can see the output of our last Retro session.
Okumaya devam et “My favourite Scrum event: Sprint Retrospective”