Series: How to kill the Architecture Department? Part 7

Part 7: Best practices

In the previous blog posts in this series we discussed the role of technical leads (and in particular of Technical Product Owners [TPO]) in an agile software development process. Since then we have had several questions. The main question was: “I am in a classic architecture team. The development teams go agile. How can I get more involved with the teams?”. In this post I would like to focus on some best practices: how can you, as a TPO get more involved and facilitate the teams to deliver better quality?

The coaching technical lead

Teams are self-organized and very well capable of making decisions. However, they can use the experience from the TPO to make the right decisions. As I described in the post about the TPO it is my belief that the TPO should act as a coach to the teams. For a TPO (and Product Owner) it is enough to help the teams in making the decisions. But how can you as a TPO do this?

Start with improving DONE

The quality of teams is based on what they deliver. To improve the output, the teams only need to do the things that are really needed and technically right. Using complicated software architecture for a simple function is over-engineering. Over-engineering should be avoided. As a coaching TPO you can guide the teams to do things right. A technical lead has 2 focus points. One towards the future: what epics need to be implemented? The other towards the teams: what are they working on and are they doing things right? Start with the focus on the teams. Help them to make the right choices and to increase their velocity. Since you are not fully part of the teams you can be objective and reflect the teams with their choices. So, ask questions like: Why would you like to use that framework? Why this kind of architecture? How can we make this assumption more concrete?

After that, aim for the input of the teams

When the teams do the things right you can aim for the input of the teams. Usually the functional requirements are based on a vision on how an application should look like and what it should do. As a TPO you should develop an architecture that enables implementation of these functional requirements. Don’t carve this architecture in stone. Make it agile: set the framework (but not in detail), discuss it with the teams, the Product Owner (PO), fellow architects and the Chief technical Product Owner (CTPO). You might be the one that initiates this architecture, you don’t own it. You are just the facilitator. It is both for you as a TPO and for the team important to be aware of this. This way you can ensure that the team takes ownership for technical decisions and the architecture together with you. This will lead to a better, actually implemented architecture.
An architecture can’t be implemented completely from the first iteration of a project. It is usually implemented in an iterative way. It is therefore important to keep an on-going discussion about how to realize the architecture with the teams and other stakeholders. The last thing you should be afraid of is to change the architecture.

Discuss technical bottlenecks

So, the teams are doing the right stuff and the architecture is growing. The activities to achieve this are mainly focused internally: towards the teams. But for a technical lead, especially a TPO and CTPO it is also important to focus externally: towards upcoming epics. These epics, the new functional requirements, can have an impact on technical aspects of the application under development. Just like with the teams you can reflect choices towards the PO and management. It is important to discuss the issues that arise with the Product Owner, management and other stakeholders so they can be addressed. Discuss how the issues can be tackled and what the impact is on the progress and functional requirements. This is important because a PO probably has less understanding of the technical impact of the choices he would like to make. Based on the business value and the technical impact a well-considered decision can be made.

Thanks

This was our last post in this series. Thank you very much for reading the posts. Both Adriaan and I enjoyed discussing them with other colleagues and writing them. We hope with this series we gave you food for thought regarding the role of technical leads, and especially the classical architect, in an agile development process.