I work with people going agile. Sometimes it is an awesome experience and sometimes it is quite depressing.
For example, I worked with some good, experienced people a while back. They were were pretty sad before I turned up and pretty happy that I came to help them. This is the part of the agile coaching experience that is awesome.
Before the dawn of agile:
- Business cases took longer to get approval than some projects took to deliver; and
- Worse than that, some projects took longer to die than the fading spirit of the team members on the project.
Then I arrived, crashing through the window with index cards in one hand and a mandate to free the people from tyranny in the other.
This is where I like to play.
Editor’s note – Unfortunately this article turns out to be a long read, so grab a cup of tea, or just look for some nice pictures and skip all the boring text.
Continue reading “Is it really that hard to learn agile?”
I recently wrote an article on coaching where I suggested building a toolkit of different approaches to use when coaching people and teams in different things.
This is my (very basic) tool for teaching a skill – it is called “what why how”.
I use it when I want to help someone develop a specific skill that I am confident I can teach and give feedback on. For example, running agile meetings or business scoping workshops.
Continue reading ““What why how” coaching for skills”
I wanted to introduce you to the cause and effect clock as a workshop tool for coaches
Continue reading “The cause and effect clock for agile coaches”
I ran an agile coaching course recently and, naturally, we spoke a lot about coaching.
We ran through a lot of different techniques and approaches to coaching people in agile teams, but we discovered that both “coaching” and “agile” might mean different things to different people in different teams.
Then someone asked how they would know when to apply different approaches to coaching. The answer we came up with was:
“It depends who you are coaching and what they are hoping to achieve.”
That left people a little confused about how and when to apply different techniques. So we came up with the following diagram that might help (although I have added a couple of bits based on previous conversations with people).
Continue reading “Would you prefer coaching or coaching?”
In my last article, I talked about “story walls” but in fact, I focused on task walls. The difference is minor but choosing one over the other can help improve collaboration among the team.
Task walls, predictably, are about tasks – “today I will do task 1” while story walls focus on the thing being built – “today I am working on story 3.”
Continue reading “Notes on story walls – story or task?”
A retrospective is a meeting where the team stop working and take a step back to review how well they are working and what they can do to improve.
It is generally done every sprint (or every two weeks if there is no sprinting going on).
The theory is easy – the team share their views on what went well in the last fortnight, what did not go well and what they should keep doing or change as a result.
In practice though, it often turns into a therapy session where people share opinions about the way the world is really bad (or even how the team is awesome) and then they wander off without taking on any action items.
So when your team have lost their mojo and the retros are getting stale maybe it is time to do a retro on the retro. Similarly, when you first start out as a team, it is often good to define what you might want to get from your retro.
Continue reading “Do you get value from your retrospective?”
One of the most powerful components of agile approaches is the retrospective. I often think that even if a team does not know what “agile” is, if that team pauses on a regular basis and reflects on how to get better at what they do, then they would invent most of the other agile practices for themselves.
But stopping on a regular basis can get stale after a while, so I thought I would sharer some slightly different sets of questions that you can use to keep things fresh.
Continue reading “Different Retrospectives and pre-mortems”
[Editors note – this is a long an obscure article that made sense to me and some people I explained it to. If it is not making sense half way through abort rather than continuing … it either makes sense early on or does not make sense at all]
I was running an agile course on how to facilitate good work in agile teams. We had some great discussions about conflict being good and people being unleashed to create value rather than being held back by managers who try to control them to force them to add value.
But then we had a less comfortable conversation. Someone asked what you do with someone who is being a [bad person] in an agile team.
Continue reading “Dealing with baddies on agile projects”
I went through this quick meeting with an agile class recently and I said I would post this for the crew to refer back to.
In agile teams there are a couple of core roles and then the rest depends on the kind of work the team does. But we can give some more clarity than this, as I have previously discussed here.
Even so, the role of the Scrum Master or Product Owner or Tech Lead or even others will vary from project to project and even sprint to sprint.
So I often have people sit down together and actually tell each other what they think they are in the team for. Essentially I get them to go through these questions that I got from a book called “Stand Back and Deliver.”
Continue reading “Clarifying agile roles – speed dating?”
Card sorting is a simple and useful way to gather feedback on which features people want in a new system, which problems they want solve or generally speaking, what they want.
So I was surprised recently when some business analysts I was working with had not heard of the technique and I thought I would describe it here so they can look at it again.
All you need is something people want and a pile of cards to sort:
Continue reading “Card sorting – agile BA technique 158”