
With all the hubbub around the World Agile Qualification Boards and other certifications, I wanted to make sure that teams were getting the most out of their capabilities. So I’ve created the Agile Object-Oriented Maturity Model Certification. You can get all the details at the site. Sign up today!
Steven List asks if Retrospectives are an antipattern. The question actually came from Chris Matts, and was a point I agreed with – the more mature a team, the less likely they will need formalized retrospectives.
To explain more, check out Patrick Kua’s Model for Understanding Retrospective Impact. The key thing that struck me is how I envision teams working in that model. let’s say we divide it into 4 quadrants – Dysfunctional/Chaotic, Dysfunctional/Nurturing, High Perfoming/Chaotic, High Performing/Nurturing.
This is the typical Death March team. Communication is extremely vital for the teams, especially when you are looking for any edge. However, because everyone is heads down, it is going to take an experienced facilitator to help them get value and to force them to lift their heads up once in a while. So I see Retrospectives being formal, and requiring a lot of work to get information. Sadly, the information gleaned may not be able to be put to use in certain Death March scenarios, which may lead to the whole concept being rejected as a useless waste of time.
Here, I’m assuming Patrick means a team that has good communication skills and trust, but that isn’t getting anything done. I’d expect retrospectives here to still be a little more formalized, but not quite as much as the above. However, the information gleaned would be amazing. This would be the stuff formal retrospective dreams are made of.
This team is the polar opposite of the above one. In this team, stuff is getting done, but it is utter chaos as people follow their own way, don’t work together, and generally work as independent entities. Retrospectives may not be seen as needed, and might be rejected since what will be changing here isn’t process, but people.
In this team, stuff is getting done, and people are communicating. The need for a formal retrospective is minimal – likely at the end of major milestones just to recap. But mini, informal retrospectives are constantly happening. The team has a “issues” board on their Big, Visible Wall, and when things are posted, they are dealt with then, or during the next standup. And if it involves a bigger group, a retrospective is called on the spot.
Respect is perhaps one of the most fundamental tenets of any team. Before a team can even begin to address the 5 Dysfunctions, they must learn to respect each other.
Fundamentally, there are two different meanings for respect – one being a reverence for a particular person. For example, we may have significant respect for our parents, or our mentors, or those who have accomplished much – for example, Albert Einstein. In this case, we look towards the excellence of the person to determine the level of respect we show.
However, in our day to day dealings, we will work with many people for whom excellence may not be the first word that comes to mind. It is in these cases when it is vital to work on the respect we show – the acknowledgment that the other person may have differing ideas, or that how we are communicating may not match up with their needs.
A great example of this is the Dreyfus Model experiment I blogged about some time ago. If you aren’t familiar with the Dreyfus Model, it is a model for learning which defines a set of levels and the needs at each level. It looks like:
Let’s say we feel we are at an expert level for some topic. And let’s say you have a challenging co-worker who comes to you to talk about that topic. What he’s saying doesn’t make any sense, in fact, it seems utterly wrong. There are several ways we can approach this:
I’m sure you can guess my answer – None of the above. The problem is that we’ve likely already flipped the bozo bit on them, so we may not be listening to the problem as closely as we could. And thus, we might be missing some important information that shows that either everything isn’t as hunky dory as we think – or that there are documentation or diagrams that we could provide to help people understand things better.
Respect, by itself, is hard to practice. There are two key areas we can focus on to improve our skills in this area:
Changing how we view others and communicate with them is not an easy road. But experience has shown me that the more you work at it – the less bozo bits you flip, the more you adopt a style of inquiry and learning – the easier it becomes, and the more insight you gain into your team, and more importantly, the people who fill those desks next to you.
I’d love to hear stories about how you’ve used tools and practices like those above in situations where respect was hard to come across.
Everything is now finalized for the first Day of Ruby event, which will be held May 16th in Tampa, FL. This is a free event for anyone interested in getting hands on with Ruby and Rails (especially .NET and Java developers). For all of the details, and to register, head over to http://tampa.dayofruby.com or follow us on Twitter at DayOfRuby. See you there!