Blog

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.

One of the concepts I hear many colleague agile coaches talking about is the concept of resistance of the client. Typical sentences are about resisting the agile transition or proposals. Now here’s one thing that is important to consider: there is no such thing as resistance, there is just bad communication!

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

Agile practices are often built on unvalidated assumptions rather than solid scientific evidence.

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

Organisational change initiatives fail because they don’t address all six essential conditions that must be present for successful transformation to occur.

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

In my work very often I stress the role of the observer: it’s a vital one when practicing coaching techniques and it’s an incredibly useful tool to use in every coaching activity.

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.

Coaching Organisations as Systems, i.e. Agile as a Systemic Change at the Scandinavian Developer Conference 2011.

Another ‘service post’ to distribute the slides of the Soft Skills Essentials presentation at the Mini-XP Days 2011 in Mechelen.

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

Suppose you need to choose the Scrum Master for your team and there is no ’natural’ candidate available. Suppose you have two alternatives who could do the job, but you are not sure who fits best?.

Soft Skills Essentials for Software Craftsmen at XPDays Benelux.

It’s not just about teams! - ‘Agile as a systemic change’ presentation at the Italian Agile Day 2010.

I am a strong believer in the solution focused approach. Over time I answered several questions on this topic: here are some of them.

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.

This is a short post to share the slides of the presentation I gave today at XP 2010 in Trondheim.

Here’s a short post to publish the slides and the handout for the third version of my Solution Focused approach to Agile Coaching presentation.

Last week I went to Kraków for the first edition of the Agile Central Europe conference. The news is that the conference was, IMO, a great success - so here’s a short report about it.

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.

Agile practitioners need accessible training opportunities to develop advanced coaching and facilitation skills.

I attended recently a meeting of project managers where ‘agile methods’ was the subject of the evening. I noticed an interesting cultural aspect: what do you fear about Scrum?

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

Here’s a metaphor I use often when coaching people. It is called the lifetree and I use it as a tool to raise awareness of the resources of the past and the possible futures and to identify strengths and weaknesses and learning paths.

Teams and organisations struggle to develop shared values and principles that create alignment, agreement, and effective teamwork in agile environments.

One thing to consider when you start your next organisational improvement campaign, be it introducing agile, improving your agile practices or, in fact, any sort of change you want: you are not in control of what happens. You never were. You never will be. No matter how much the official org chart of your company claims you are in a control position, you are not.

During my presentation about Solution Focused work in Agile at XPDays Benelux I stated that asking ‘why’ in coaching can be dangerous and should be avoided. The purpose of this post is to add some more information on this controversial topic.

Last week I was at the XPDays Benelux conference where I presented a session about Solution Focused work in agile.

Last Friday I went for my first time to the Italian Agile Day, a day of full-immersion in the world of the Italian Agile community, even free as it’s autofinanced through donations.

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?

Have you ever wondered what makes Agile so special and so productive? My guess would be because it closes loops and allows fast and useful feedback.

Last Thursday and Friday, Sept. 10th and 11th, about 70 agile fans met in Baarn, Holland, for the Agile Open 2009 edition.

I was at a conference recently, following a project manager’s presentation about the project he was leading.After just a few minutes into it, I felt lost in his words. I realised what he said until then was… more or less nothing!

There are a lot of people out there calling themselves ‘Agile Coach’. I’m one of them as well. But what are we exactly? What is our role in an organisation? What value do we bring each day we work with software teams?