Subscribe
Posted on March 31st, 2009
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!
Posted on March 25th, 2009
In general, I highly agree with Scott’s comment on Steven’s original post – the need for a formalized, required, scheduled retrospective is a sign that communication isn’t happening on the teams that should be. In my opinion, it’s a great starting point with the right facilitator, but we should strive for more spontaneous ways of getting the information out we need to get out.
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.
Dysfunctional / Chaotic
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.
Dysfunctional / Nurturing
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.
High Performing / Chaotic
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.
High Perfoming / Nurturing
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.
In general, I highly agree with Scott’s comment on Steven’s original post – the need for a formalized, required, scheduled retrospective is a sign that communication isn’t happening on the teams that should be. In my opinion, it’s a great starting point with the right facilitator, but we should strive for more spontaneous ways of getting the information out we need to get out.
Posted on March 19th, 2009
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:
- Novice – Needs to be told exactly what to do. Very little context to base decisions off of.
- Advanced beginner – Has more context for decisions, but still needs rigid guidelines to follow.
- Competent – Begins to question the reasoning behind the tasks, and can see longer term consequences.
- Proficient – Still relies on rules, but able to separate what is most important.
- Expert – Works mainly on intuition, except in circumstances where problems occur
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:
- Cut the person off, and inform them they are wrong and why they are wrong, so that way you respect their time and prevent them from having to tell the whole story
- Listen politely to their story, and then explain to them why they are wrong
- Flip the bozo bit on them, tune out for as long as you can, fading back in just long enough to say, uh-huh, then finish with some vague answer to make them go away
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:
- Recognizing when we’ve flipped the bozo bit – The “Bozo bit” is a mental switch that is triggered by some condition where we just don’t want to deal with the person. “Flipping the bozo bit” is an easier out than dealing with the person and the issues. Watch for signs of when you find yourself shutting someone off without hearing them out, and ask yourself, “What would make this person act in this way, or think this about the system?”
- Understanding the other viewpoint – Without a doubt, the biggest impact on my career has been Appreciative Inquiry (for an example, see Kent Beck’s great article on Appreciating Your Way to XP). Look for situations to apply it – this will be difficult at first, because it is much easier to not engage people. But if we want to change how we build software, we must recognize that without communication, we are nothing
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.
Posted on March 1st, 2009
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!