Team Development

While digital tools can help teams visualise and manage the Product Backlog, they also introduce challenges that can impact collaboration and transparency…

Complex digital tools can hinder team collaboration and ownership of Sprint Backlog management.

Organisations create too many specialized roles too early, leading to knowledge silos, coordination overhead, and organisational complexity that becomes impossible to reverse.

Managers constantly watching over agile teams during sprints destroys team autonomy, reduces accountability, and undermines the motivation that comes from self-organisation.

I like to think of the retrospective as a piece of art and the facilitator (usually the Scrum Master) has to learn to be the artist. This meeting is totally in the hands of the facilitator, so you can easily think that it is about the facilitator. It is not: providing a process for a retrospective is very much different from being the star of that meeting. Your role as a facilitator is to provide a structure and otherwise stay out of the way, letting the team to be on the stage.

One of the assumptions of a retrospective is that the team should come out with concrete action items they will work on to become better. While this is the preferred way, it is not the only one.

Usually the retrospective is done within the team, but in some cases there might be somebody more or somebody less…

Following the Agile Manifesto’s advice to reflect at regular intervals creates superficial continuous improvement that fails to address deeper systemic issues.

I often get questions about how to approach refactoring at the cultural level, i.e. how to promote it in the organisation. This post is an adaptation of some advises I gave to a customer of mine…

In the previous post, I introduced you to Solution Focused scales and how they can be used in a one-to-one scenario. Now we’ll extend this to a team context, but first, here are some tips…

No, this post is not about increasing the size of your development team, but about how to establish some measurements in your team - typically during the retrospectives, but not only - to support continuous improvement: let’s talk about Solution Focused Scales.

Team coaching through group processes is too slow and ineffective when time constraints demand faster development of high-performance teams.

In a conversation during the last Agile Coach Camp Germany I was reminded of something I see often in agility: motivational interventions.

While reflecting on my recent activities, I started to recognise an interesting pattern regarding the role of the Product Owner.

I reckon on the subject of games I am at the border of the agile community: agile games are very spread among my colleague coaches.

Here are the slides of today’s keynote I delivered together with Mike Sutton at the Turku Agile Day

Soft Skills Essentials for Software Craftsmen at XPDays Benelux.

I recently had a situation where two teams based in two different locations had to start working together on a project. I used the following technique to prepare each team for the upcoming meeting.

As I had announced in my last post, I talked to day at Agile Central Europe, again presenting my Solution Focused approach to Agile Coaching workshop.

Teams struggle to identify and address the true constraints limiting their productivity and delivery speed in complex project environments.

Almost every day you will notice that the existing set of rules, procedures, process, etc. you normally use in your work is not enough. What do you do then? Will you add a new rule or will you delete one?