The cause and effect clock for agile coaches

I wanted to introduce you to the cause and effect clock as a workshop tool for coaches

IMG_20170814_130546

Continue reading “The cause and effect clock for agile coaches”

Notes on story walls – story or task?

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?”

Different Retrospectives and pre-mortems

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”

Dealing with baddies on agile projects

[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”

Clarifying agile roles – speed dating?

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.”

IMG_20160511_002553

Continue reading “Clarifying agile roles – speed dating?”

Velocity is great but meaningless on its own

I just wrote a couple of entries on “velocity” and now I want to look at some of the implications of using it.

Here I will be looking at how we interpret velocity and how we can use it. In particular I will be looking at how it relates to concepts such as “done”, “regression testing” and “showcases.”

Continue reading “Velocity is great but meaningless on its own”

What does a velocity chart look like in an agile team?

In my last article I gave a brief description of “velocity” and how I might use it in a training course.  I ended up measuring progress in “coffee points.”

This allowed me to plan my training topics and to share our progress during the day with the students in the class so we could continuously plan during the day.

All great stuff – but you might not actually know what a velocity graph looks like.  So this article runs through how I might draw my velocity graph as a “burn-up chart”, “burn-down chart” or something else.

Continue reading “What does a velocity chart look like in an agile team?”

Can I still use a use case on my agile project – even if the cool kids don’t use them anymore?

I have been told that use cases are very old fashioned now and that all the cool people have moved onto agile user stories.

But I am old school and I still like to pull the old approaches out every now and then and take them for a spin.

I found myself explaining use cases in both a lecture (where the company wanted me to explain them to the BA teams) and a small team where people had been doing use case diagrams but not really use cases. Then I got asked in a BA course – “do you use stories for agile projects and use cases for waterfall ones?”

My answer was “it depends – probably just ask the BA”. But the student responded that she was a BA and that all the other cool BA’s would make fun of her if she wore the wrong clothes to school or used the wrong tool on the wrong project.

Continue reading “Can I still use a use case on my agile project – even if the cool kids don’t use them anymore?”

The humble trade-off matrix

I have been doing some business analyst training recently and I spoke about a “trade-off matrix” a couple of times. A couple of people have asked for a good link to explain what one is and why they are so cool. So I looked on the web and couldn’t find anything decent enough to send through.

So I thought I would describe what a trade-off matrix is here. I will also briefly mention why they are useful and then mention a couple of variations that people might not have heard of.

Continue reading “The humble trade-off matrix”