unicolet.org

A note-to-self kind of post on a playbook to turning around a struggling sw engineering team. Core principles always behave trustworthily slow down and make time to address problems do you have the right people? if you can't get consensus, seek consent Foundational engineering best practices With regards to engineering best practices, the following are foundational and should be part of the execution somewhere between steps 4 and 8 of the playbook: trunk-based development continuous integration no separate tester or devops team (this can be relaxed after the team begins performing), seek out a stream-aligned team instead SCRUM with its process is useful to align the team and at last one main stakeholder automate as much as you can, especially the parts that come up often for discussion; one obvious but often overlooked example are customized coding styles (use the consent-over-consensus principle to reach a decision) If the team resists them or does not make progress, then see the...

This LinkedIn post hurt 😅: The metrics they create for engineering help them convey to the board and to the other non technical department how engineering is helping the business move forward, how engineering is adding value. Not what the DORA metrics say without any relationship to what the company is trying to achieve. As a huge DORA fan, I am hurt that DORA is not the pinnacle of clarity that I want it be, especially since I have it on the deck I present the board each quarter. The fact is that Adelina Chalmers is right. The language of business is accounting and engineering performance should be ultimately connectable to bottom line impact. If it can't, there is a disconnect which will ultimately lead to a rough wake up call. So what can we use instead? A similar question was asked in the CTO Craft slack. Here is my take, straight off the top of my head (so probably still a bit rough). Considering that a C-Level/Board would be talking at the level of impact , we need to con...

Photo by Daniele Levis Pelusi on Unsplash This week I joined a Risk Storming workshop led by Beren Van Daele . Disclaimer: my attendance was spotty due to overlapping events, but I think I got a passing understanding.   One aspect of the workshop stirred my attention, and it was the mention of fears in the context of goals vs fears. Obviously anyone wants to achieve certain goals, so it makes sense to set goals and to mention them in a workshop like this. However when setting goals there are certain second-order effects or side-effects that we want to avoid, minimise or eliminate entirely. Here are a few reasons why I found intriguing (and valuable!) the explicit mention of fear. Acknowledge fears when planning Acknowledging fears and taking them into account into planning is a desirable trait in any wise person who seeks...

Today I came across DevLake on the DORA Resources page. DevLake is an:  Open-Source Dev Data Platform for Productivity It seems to be an incubating Apache Project which means it might still be a bit rough around the edges. It's going to be interesting to look into it.