This is Pierluigi's Typepad Profile.
Join Typepad and start following Pierluigi's activity
Join Now!
Already a member? Sign In
Pierluigi
Recent Activity
Image
It starts in the usual way: You're having a discussion with somebody from your current client and he/she tells you that agile practice X is bogus/useless/... and that that person is not going to use it/apply it/promote it to others. Now… what do you do? Before you realise it, you are having a conflict of interests. It all starts with your roles: as an agile coach you are at the same time: Coach, supporting reflection processes and not giving advices, finding the best question to ask instead of the best answer, focused on promoting self-organisation in the team and ensuring... Continue reading
This is the fourth article in a mini-retrospectives series. In the previous ones I wrote about how retrospectives should be done at regular intervals, but also in other occasions and how the retrospective could be done in different groups than just the team and that sometimes changes happen even without an action item being clearly formulated. This post analyses one of the most common mistakes of a retrospective facilitator: hijacking the retrospective. I like to think of the retrospective as a piece of art and the facilitator (usually the ScrumMaster) has to learn to be the artist. This meeting is... Continue reading
This is the third article in a mini-retrospectives series. In the previous ones I wrote about how retrospectives should be done at regular intervals, but also in other occasions and how the retrospective could be done in different groups than just the team. In this post I will continue to challenge the 12th principle of the agile manifesto to explain other ways to spice up your retrospectives. The 12th principle says: “At regular intervals [when?], the team [who?] reflects on how to become more effective [what?], then tunes and adjusts its behaviour accordingly [for what?]”. This time we look at... Continue reading
This is the second article in a mini-retrospectives series. In the previous one I talked about how retrospectives should be done at regular intervals, but also in other occasions. In this post I will continue to challenge the 12th principle of the agile manifesto to explain other ways to spice up your retrospectives. The 12th principle says: “At regular intervals [when?], the team [who?] reflects on how to become more effective [what?], then tunes and adjusts its behaviour accordingly [for what?]”. This time we look at the team: usually the retrospective is done within the team, but in some cases... Continue reading
This is the first in a series of posts about moderate retrospectives creatively. Traditionally the retrospective in agile software development is the reflection done at the end of the iteration. Principle six of the Agile Manifesto says “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”, so regular it is: at iteration’s end we invest some time in continuous improvement and we call that retrospective. But… is this the whole story? The Agile Manifesto writers might have had the best possible intentions, but they got the concept of continuous improvement... Continue reading
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… The best way is to have refactoring done as part of the story development, so during the sprint. It's just there. It's a way to keep technical debt low and it's everybody's job to do it. There is no reason to make a big fuzz around it as each refactoring cycle lasts a few seconds to minutes. Of course reality is different and more... Continue reading
Image
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… Tips on using scales A constructivistic approach is important also when using scales: whatever numbers the client chooses, it must be fine for you as coach. We are working in the client’s reality, so if you believe the client's 6 is actually a 2 do yourself and the client a favour and don't say it, both verbally and non verbally! You might - and should,... Continue reading
Image
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. I already discussed this technique in my Solution Focus presentation, but listening to how people use this information, I realised I did not stress a few details that are actually quite important for a proper implementation of the technique. We're using scales when we ask somebody - or, as it's usually the case in agile, a team -... Continue reading
Image
One of the concepts I hear many colleague agile coaches talking about is the concept of "resistance" of the client. Typical sentences are "he is resisting the agile transition" or "I talked to her about X and she resisted the proposals I made". Now here's one thing that is important to consider: there is no such thing as resistance, there is just bad communication! This is actually not just my statement, but also an axiom in neuro linguistic programming: "There are no resistant clients, only inflexible communicators". Let's see what it means… Resistance is an abstract word. You cannot buy... Continue reading
Image
…to coach its individuals one-to-one! Contradiction? Well, some time ago I thought so as well, but… Over the last years I had a few clients where, because of some constraints in the setting I was working with, I needed to "speed up" with the coaching program and "deliver" a high-performance team faster than I usually did. Learning the mechanics of scrum, kanban or whatever we agreed to implement has never been a problem: the people I worked with are usually pretty smart and can pick up the concepts quickly, but the team building process was taking longer and, well, I... Continue reading
Image
Last November I presented at the Deutsche Scrum the first version of my new presentation "Debunking Agile Myths". The core message of the presentation was to show that many of the things we believe in the world of agile are based on… ehm… nothing, actually! Surprised? So was I when I started checking the scientific validity of what we do. Already non-agile coaching is often a quite fragile discipline, where quite a lot of the validation of the methods is, in fact, just anecdotal. Yet apparently also in agile we are using several dubious sources and build on those, with... Continue reading
Image
In a conversation during the last agile coach camp Germany I was reminded of something I see often in agility: motivational interventions. Most, if not all, agile coaches use them in one form or another: a workshop moderated with a pot of energy on their side, a training where the reasons why agile is what it is are many times evangelistically explained with the goal of inspiring the participants, various games where motivation is either the goal itself or at least an important by-product. Yet, when I make a systemic analysis of actual organisations, motivation would be more likely an... Continue reading
Here are the slides I presented today at XP Days Benelux in Mechelen together with Dirk Lässig (@djlaessig): Change, Change, Change! This time in a workshop version, where the participants learned to use these conditions to design change. For a detailed description of what this is about, please refer to my previous post. Change, change, change! workshop xp days 2011 View more presentations from Pierluigi Pugliese. Continue reading
Here's a new post on design thinking. As promised in my previous post, some more details on what the presentation at XP Days Germany together with Dirk Lässig (@djlaessig) was about. In fact, we just delivered the same material in the format of a workshop at XP Days Benelux, where, rather than talking too much, we let the participants experience what design thinking could be. Here are the slides presented: Innovation needs waste - XP Days Benelux 2011 View more presentations from Pierluigi Pugliese. While agility has improved the way a product is being developed, design thinking addresses what comes... Continue reading
Here's a short post just to publish the slides I presented today at XP Days Germany in Karlsruhe together with Dirk Lässig (@djlaessig): Innovation needs waste. More on this topic in a future post... Innovation needs waste - XP Days Germany 2011 View more presentations from Pierluigi Pugliese Continue reading
Image
A matter of secondary gains So you explained to your team how to do X - where X is a certain agile practice you believe it will be very helpful for them - and they learned and implemented it quite well and you were so proud of the way you convinced them to change their habits until... they don't! And the more you try to bring them to the "right way" the more they go back. They even tell you they really want to implement the wonderful technique you showed them, but actually they don't. Maybe you weren't clear enough.... Continue reading
Image
So you're out in the field trying to change companies by "coaching them to agile", do you? Are you sure this is possible at all? If yes, then this article is not for you yet: please come back when you are doubting. The assumption this article is based on is that we're not sure whether a person/a team/an organisation can change at all: what are the conditions that allow a change to happen? Can we actually support our clients in implementing these conditions, thus effectively lowering the barrier to change? This very topic was the subject of my recent presentation... Continue reading
Image
While reflecting on my recent activities, I started to recognise an interesting pattern regarding the role of the Product Owner. I've seen many of them coming from different parts of the organisations: form product management, from various levels of management, from system architecture or senior programmers. Because of the different skill sets they have, the way they interact with the team from a technical perspective is different: some of them write user stories down to the last detail, some others just say the title and let the team write them, some of them ask the teams to prepare a backlog... Continue reading
Image
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. In the workshop I delivered at the Turku Agile Day together with Mike Sutton, we stressed the importance of the Observer role in coaching, giving also some instructions on what this role is about. But while reflecting on the workshop, we got the impression we should have spent some more time describing it, so here we go... 1. What is an Observer? Easy, the Observer... observes. But... what... Continue reading
Image
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, more than what I use them, and, from a purely informal and statistically not relevant poll I made, it seems that many agile coaches... run games with their teams on a regular basis schedule games sometimes even every day at a fixed time take inspiration from several games books design their own games but also don't know why games "work", i.e. why and how the team afterwards is "better" than before don't know how to... Continue reading
At the Scandinavian Developer Conference I presented today some concepts useful for coaching at the organisational level. The basic idea behind this presentation is that thinking about agile at the team level is a necessary step, but not the only one needed in order to create an agile organisation. In a parallel presentation I argued that an agile organisation supports not just teams but also the growth of the individuals both at the technical and at the soft skills levels. This time I argue that also the organisation as a whole requires attention: in too many cases coaches think about... Continue reading
Here another "service post" to distribute the slides of the Soft Skills Essentials presentation, this time in the form Yves Hanoulle (twitter: @YvesHanoulle) and I presented it at the Mini-XP Days Benelux in Mechelen, a summary of the best presentations of last year's XP Days Benelux. The presentation is basically as the Turku Agile Day, but made a bit more visually attractive in a few places. Here are the slides: Soft Skills Essentials for Software Craftsmen - Mechelen Mini XP Days 2011 Here is also a short bibliography: Status The concept of status comes from the Improvisation Theatre school. The... Continue reading
Here are the slides of today's keynote I delivered together with Mike Sutton (@mhsutton) at the Turku Agile Day to a very engaged audience: thank you for the fun! Soft Skills Essentials for Software Craftsmen - Turku Agile Day 2011 For the bibliography, please refer to this post... Continue reading
Today, together with Mike Sutton (Twitter: @mhsutton), I run a workshop called "New Tools of the Craft" at the Turku Agile Day. Here are the slides we showed and a selected bibliography... Yes And... This is a concept coming from the Improvisation Theatre. The best known books are: Keith Johnstone - Improv and the Theatre Tom Salinsky, Deborah Frances-White - The Improv Handbook Keith Johnstone - Impro for Storytellers: Theatresports and the Art of Making Things Happen Clowning At it's core clowning is about being at ease with the flaws and flops of being human, of acceptance of ourselves inspite... Continue reading
Image
Suppose you need to choose the ScrumMaster 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? I got a similar question proposed some time ago by one of my customers. Instead of giving my answer, I started asking questions instead - well, I'm a coach, aren't I? First I asked what characteristics are important for a ScrumMaster in that particular organisation: Communication Skills Motivation System Knowledge Knowledge of the Organisation and the way it works Connectedness in the Organisation Accepted by... Continue reading