It does not matter how much is reported about readiness of products, portals and the like.

Yes you argued with product management about the product readiness, you cautioned management about what the current status "really" means. Will it be understood? No. Because it is in the abstract, in the Powerpoint, in the report. It is not the real thing.

The "real" understanding starts when you accompany the stakeholders on a customer journey, which is easier with digital products. Then it becomes better understood.

Beware, the product has to have a certain maturity, because extrapolating as a non-product owner is very very hard. And the visual design has to be right as well. Not good enough, means there is no trust in the substance.

Concrete beats abstract. Don't talk about the things, show them or work directly on them.

I conducted my second "real" retrospective. I like it, it is about people.

The retrospective was conducted the second time with the same team on product development. Each time roughly 2 hours. The space between the 2 retros was about 3 months.

There were very distinct differences between the 2 retros. The first time I did not see so much "one team". There was quite some frustration in the room, which needed some space to be expressed. But there was at least one common denominator: everybody agreed to invest time in one specific topic: process descriptions.

Other results from the first retro:

• Confidence that things would get better after the retro was fairly low
• Some participants considered the retro as a good starting point for the team to really come together
• Some participants were unhappy about the lack of "concrete" measures
• There was no conclusion on how to do it. The "how" was then discussed and elaborated afterwards by 2 participants.
• there was no blame game

In the second retro I adapted the methodology to have one section which forced the participants to come up with concrete measures.

Before that I asked if the participants, looking back, if things had gotten better, the answer was quite positive ("yes"). But as a moderator, I could not really explain the root cause of this positive development. It cannot only be a retro.

The participants had to go through an analysis of their current experience with their collaboration and results, the take an outside in view, before developing concrete measures, SMART ones. The challenge here as a moderator was to make sure that:

• the discussions on how to execute the measures, on the dependencies and people to conduct it, were kept to a minimum
• the measures were indeed SMART

At the end the team was satisfied with the result BUT was still skeptical on delivering the product in time. That's a challenge for the next retro.

As a moderator I learned a lot:

• Retros make sense
• Retros have to be prepared well, having an idea on how the team ticks helps a lot to choose the right methodology out of a large catalogue
• The goal of the retros has to be very clear
• Retros are fun

IT systems are neutral and do what they are supposed to do according to what their developers have implemented.

But IT systems are done and managed by humans. The roadmap is done by humans, budget allocation is done by humans, resource governance is done by humans. And when humans act, they have interests.

Some humans believe that they act in the best interest of the company, or shareholders, or innovation, or sustainability, or revenues, or profit, or the targets they have received (which, in larger organization may contradict each other) ... and also personal interests. Hopefully the latter are not too dominant.

In this field of various interests, departments have to think about which systems they need to have a close governance aka. ownership over some IT systems or not. Then the question arises: can I trust the "other" department to do the best to achieve my goals? Will I get my roadmap prioritized in a fair way? Do we have a common agreement on the business model(s)? There is no one size fits all answer to that question.