Are self-organizing teams better or the same as self-managing teams? What about self-directing teams? Working with teams can be challenging due to change and complexity. So, the idea that we could have self-organizing teams or self-managing teams can sound valuable, scary, or both!
What do these terms mean, and where can they be confusing? Let’s dig into each one.
I’ve been training, talking, coaching, and writing recently on the topic of commitment and realized that anytime that comes up, it reminds me of the old (seems old – but not really that old!) discussion on commitment or forecast. I still find there are many questions on this topic. It certainly has not been put to bed. The approach I like to take is to step back and ask “what is the real problem?” Is a word stopping you from succeeding or is something else causing the problem? What am I talking about? — I’m talking about when the Scrum Guide was updated to change commit to forecast.
No, I don’t hate agile project management software — it can serve a purpose. At issue is if there is an actual purpose and if it is misused. Often the software stalls progress or worse, move us backwards. For any readers who are not familiar with agile or don’t work in software — the idea here is that instead of using the monitor to display some type of software tracking tool, the new scrum master just used sticky-notes and stuck them on the monitor. What is the simplest thing that works in your world?
Have you been in a situation where no one would bring up the problem that everyone knew was “in the room?” I’d guess that everyone has been there. So often, we don’t bring up the “elephant in the room.” For anyone who has not heard of this, the elephant in the room is a saying for the real or obvious truth that is not being addressed. Given an elephant in a room would be hard to miss, when people ignore it, they are typically pretending it is not there.
I always considered this six question format to be the Baseline Agile Retrospective Format. I say baseline instead of standard because a baseline is something to build on, not an ‘always the way’ standard (I know I’m splitting hairs here).
I believe the six question baseline agile retrospective format is a solid way to teach people how to do an agile retrospective. They can see, relatively clearly, the different parts that should be included. It can be a useful starting point to address additional questions and challenges.
Many people dislike the 3 question, plus-minus-delta retrospective. I am one of them. The plus-minus-delta agile retrospective leads to many problems. I say it was never the “standard” in the title, so why are so many people confused? Or…am I the one confused?
While co-coaching recently, the other coach and I had a brief exchange about how the “standard” agile retrospective was not good. I was a little confused, since while I certainly do not always use ‘the standard’ or baseline agile retrospective, there is value to it — at least I thought so? The baseline retrospective I employ is a solid method to teach people how to do an agile retrospective. I asked a few more questions and realized that while we were both using the term “standard retrospective,” we had different definitions of the term.
Fist of Five Voting is a deceivingly simple process you can use to check-in, learn, gain consensus, and/or vote to understand where people stand on an issue or idea. I say deceivingly, because there is so much more you can learn about what is really happening in a team if you are paying attention.
I find there are many tools I (and others) use without being entirely sure of the idea’s origin. As I work on other articles, I realize some people may not be familiar with concepts such as Fist of Five Voting. So I’m working on building these ideas out to fill in those gaps. The source of Fist of Five is sometimes attributed to American Youth Foundation, however I can’t find a reference on their website.
I wrote about agile team retrospectives in a recent article and find that the term retrospective can be used in many different ways. I’ve heard people ask, “Did you just change the name from lessons-learned to retrospective?” Although there are similarities, there are some key differences. Let’s review a few types and consider the issues with most lessons-learned meeting.
While agile team retrospectives have a team focus on celebrating, learning, and improving their relationship on a regular basis, there are other types of retrospectives.
