Regular retrospectives are important in our projects at TIMETOACT GROUP Austria as they help us to reflect on how we are doing as a team, what works well and what can be improved. We vary the format used based on the project context and the specific goals we want to concentrate on.
Our team has been working on a project for the last year and a half. We have worked in a very disciplined manner, systematically maintaining high quality in both our technical solutions and client engagements.
“The project exceeded all expectations”
This is one among our favourite samples of the very positive feedback that we received from the client. We were interested in figuring out the project’s principles and practices that characterize and guide how we work. In contrast to past retros, where we reflected what can further be improved, we chose a format where we could shift attention to what was working well so far. Second, we where looking for clear principles that future projects could be based on.
Could we make the implicit practices explicit and extract a “blueprint” of our project?
Different Perspectives
Firstly we followed a format where we collaboratively placed post-it notes in different sections such as reflecting on what we want to repeat and what we want to avoid in the future. Then we tried to characterize the project into the following categories: technology, processes, scope and schedule as well as people and finally, we used What is, what is not? What do we (not) do?
We will discuss in detail some (maybe) surprising post-it notes from each category that were written in these exercises.
“Tools & Tech are quite irrelevant”
We found out that due to our focus on business processes and business value in our development the specific choice of technology does not matter. Just as the client would not care which programming language we are using, where we used event sourcing and where we don’t, which libraries we picked or where we buillt things from scratch: we did not care either as regards the technology itself. It is all about the best choice in the business context. We have strong opinions on how to make software fast, intuitive, maintainable and so forth but if consensus is hard to reach – and sometimes it is – then it is due to the uncertainty about the effect on the business and not about technological preferences per se.
“People sort out things themselves”
No one is involved in decisions in an area where they are not qualified. The project manager, for instance, does not make technical decisions as he does not work in that sphere. The developers in team make decisions about when to skip a pull request, when to question a requirement’s detail, or when to raise a question about different implementation variants, etc. While we were optimizing for throughput and flexibility, it is essentially the shared trust and sense of responsibility that makes things work well.
“Find good release scope without rigid processes”
In the early phase of the project we agreed with the client on a biweekly release schedule. By using Kanban so that we are not tied to a fixed schedule, we could deploy releases earlier or delay them to make sure that intermediate feedback was incorporated. While this may not carry over to other project contexts, high quality standards for most features are crucial in our domain, which deals with sensitive information. In that regard, moving a release from Thursday to Monday would never hurt, everyone would rather tradeoff a small delay in order to avoid risk. On the other hand, nobody complained when we could release things a few days earlier either. 😊 We also had biweekly, sometimes weekly meetings with the stakeholders which were simply skipped when no decisions had to be made. It has always been about making the right choice in the specific situation, with the judgement of developers being the most important voice.
“Constantly improve and adapt”
As the projects matured, the nature of developed features kept changing, new challenges arose and the team changed. In the course of this, our specific form of collaboration kept changing as well. For instance, in the early phase of the project (where we barely knew each other) we formalized responsibility with ownership of epics to distribute some of the high coordination demand. When we grew together as a team having explicit epic owners provided no additional value, so we dropped it. Another example: We had regular stakeholder meetings on Tuesdays where we received feedback and requirements for the next steps. Although we also want to avoid meetings, we had regular internal calls on Wednesdays in order to sync up as a remote team (working at four different places) and form a shared understanding of where the project needs to go. When the projects matured, additional information could be incorporated in on-demand extensions of the daily standup and we would skip the weekly call. By the way, when we are working together closely on the same topic, we also skip the daily standup. What value would it add?
The Blueprint
We finally clustered all the Post-its notes and gave each cluster a name. Here is what we came up with, the four guiding principles for our project, so to speak. (We leave it to the sharp-minded reader to draw connection to the four paragraphs above. 😊 )
Value
Autonomy
Flow
Joy
In summary, when making decisions, including technical ones, we look at the potential business value and decide on the option that we think adds the most. The decision is autonomous. Everybody decides, what to decide and what not, with whom, and specifically and maybe most importantly: when and how. We try to give enough room so that everybody can work their way. This may also be a reason for a good project flow, both organizationally and on an individual basis. Flow requires that we are neither bored nor overwhelmed or overworked. We focus on achieving and maintaining high quality in a sustainable way, working continuously on small, measurable tasks, and supporting each other proactively. Of course, that also brings with it some joy. 😊
