Part 3: The Technical Product Owner
Retrospective
In the previous 2 posts we described the agile organization model and a couple of technical roles in this model. In this post we will dive into the role of Technical Product Owner. I will compare it with what we have started to call the “classic architect”.
The classic architect
Many architects are not involved in the process of writing software. Typically they are standing on the sideline, watching the game. Their way of communicating is through documents. These documents are the result of a separate process to design the software before the developers have started building. This way of communication makes these classic architects more prescriptive than cooperative. Because of this they are sometimes more seen as advisors than as people that add value to the process and the organization. This way, although architecture is necessary, the architects place themselves on the sideline.
In an agile process this behavior is clearly a problem. The teams focus on functionality and strive for self-organization in order to continue to deliver software. Part of this is architecture. They will deliver the software whether an architect is involved or not.
The Technical Product Owner
To be able to add value to the development process architects need to change their behavior. To visualize in which direction, we came up with the role of Technical Product Owner (TPO).
What are the key characteristics of a TPO in an agile development process?
A TPO is part of the process. As such he is not standing on the sideline, but he is where the action is: on the playing field. Unlike a classic architect the TPO doesn’t look to the process from a distance but his eyes are focused in 2 directions. One direction is into the future: what projects on the portfolio wall and what epics need to be implemented. This is important because the TPO will probably have to do initiate some work and together with other stakeholders and the teams make the user stories READY. The other direction is in the present: what are the teams working on now and how can he guide the teams to get the right things DONE.
A TPO is responsible for the architectural boundaries within which the teams can operate. While the classic architect would behave more like an advisor, the TPO will take ownership. The architectural boundaries are based on non-functional requirements from the business and from other technical stakeholders, like the Operations department. Where the Product Owner (PO) will elaborate the more functional requirements for the team, the TPO’s focus will be on the non-functional requirements. This is because the TPO has more technical knowledge than the average PO. This lack of knowledge at the side of the PO was one of the main reasons for the introduction of the role of TPO.
Unlike the classic architect, a TPO is not directive. Instead he will act as a facilitator and coach to the teams. Teams are self-organized and very well capable of making decisions. These decisions are within the boundaries provided by the PO and TPO. For a TPO (and PO) is it enough to help them in making these decisions.
TPO’s themselves are organized in virtual teams. For a TPO it is more important to be with the agile teams than with his colleagues. Of course they meet to discuss the latest development in the teams or to make a decision on the architecture (e.g. based on a changed non-functional requirement). But their primary place is in the teams.
What is next?
So, a TPO is like a PO for technical stuff. His main job is to get user stories READY and to help the teams in getting user stories DONE. But what about getting from vague ideas to concrete user stories?
In many organizations a specific attitude is needed to get ideas on the portfolio wall and to go from ideas to user stories. Our next blog post will be on just that. How can the Chief Technical Product Owner help the organization to go from idea to user story? Stay tuned and drop a note if you like.
More from This Series
<ul>
<li><a href="https://xebia.com/blog/series-how-to-kill-the-architecture-department-part-1/" title="How to Kill the Architecture Department - Part 1">How to Kill the Architecture Department - Part 1</a></li>
<li><a href="https://xebia.com/blog/series-how-to-kill-the-architecture-department-part-2/" title="How to Kill the Architecture Department - Part 2">How to Kill the Architecture Department - Part 2</a></li>
<li><a href="https://xebia.com/blog/series-how-to-kill-the-architecture-department-part-3/" title="How to Kill the Architecture Department - Part 3">How to Kill the Architecture Department - Part 3</a></li>
<li><a href="https://xebia.com/blog/series-how-to-kill-the-architecture-department-part-4/" title="How to Kill the Architecture Department - Part 4">How to Kill the Architecture Department - Part 4</a></li>
<li><a href="https://xebia.com/blog/series-how-to-kill-the-architecture-department-part-5/" title="How to Kill the Architecture Department - Part 5">How to Kill the Architecture Department - Part 5</a></li>
<li><a href="https://xebia.com/blog/series-how-to-kill-the-architecture-department-part-6/" title="How to Kill the Architecture Department - Part 6">How to Kill the Architecture Department - Part 6</a></li>
<li><a href="https://xebia.com/blog/series-how-to-kill-the-architecture-department-part-7/" title="How to Kill the Architecture Department - Part 7">How to Kill the Architecture Department - Part 7</a></li>
</ul>