Blog

Series: How to kill the Architecture Department? Part 5

31 Oct, 2012
Xebia Background Header Wave

Part 5: The Senior Software Engineer

In Scrum it is best practice to have in each sprint all the team members needed to implement the user stories in that particular sprint. Most members will be either developer or tester. Some of them will play a more pronounced part in delivering a potential shippable product. A reason for this is that they take part in the process from sprint one. The effect is that these team members grow seniority over other team members because they have more in depth knowledge of the system under development. They will be consulted more than others by the Product Owner and the Scrummaster. In our process from “Concept to Cash” we call them Senior Software Engineers (SSE). How is a SSE related to the Technical Product Owner (TPO)?

The Technical Product Owner

As we have seen in a previous post the TPO is the technical counterpart of the Product Owner. On one hand his attention is on the future: what projects are on the portfolio wall and what epics need to be implemented. On the other hand he pays attention to what the teams are working on now and on how he can guide the teams to get the right things DONE. How does the SSE complement the TPO?

Sparring partner to the TPO

Where the TPO is with only one leg in the team, the SSE plays the role of the foreman of the team. As such he has both legs in the team. In general he is an experienced developer, not only with excellent technical skills. He is also knowledgeable about the specific business domain. He can be, and often is, the sparring partner to the TPO and PO to get user stories READY. Usually the PO will organize a READY session to inform the team members of upcoming user stories and to let them estimate the stories. Prior to that session the SSE is often consulted by the PO and TPO to discuss the stories.
Because of his seniority he can easily fall in the pitfall of prescribing to the team how to implement the user stories. What can the SSE do to avoid this?

Facilitator to the teams

During a sprint the team sometimes needs to make important design decisions. For the team and especially its less experienced members it is tempting to leave this to the SSE. However, a best practice in Scrum is that every team member is equal. So, how can the SSE use his experience to let the team as a whole make the decision? The answer is by facilitating the process rather than prescribing how technology should be implemented. One way to do this is by coaching or mentoring the individual team members in their technical skills. This way knowledge is shared among all team members and all (or at least most) team members will support the chosen design decision. An interesting side effect is that this way the SSE stimulates the junior team members to grow and to get more self-confidence.
The Scrummaster has an important task in this process: to monitor whether the SSE does indeed facilitate and not prescribe. He can alert the SSE if he is prescribing too much and ask him to do a little step back.

Communication with other teams

Are developing software and mentoring junior developers the only things a SSE does? Fortunately not. There are many more, of which I would like to mention one: communication with other teams.
In an organization where there are more teams, communication is needed about technical aspects of the job. Think of chosen frameworks in a team and design decisions made by the team. These need to be communicated so other teams can take advantage of this. Because of his seniority the SSE can take the lead to arrange this.

The Senior Operations Engineer

Next time we will be discussing the Senior Operations Engineer and his relation with the Technical Product Owner and the Senior Software Engineer. Stay tuned…

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>
Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts