One of the jobs of an Agile Coach is to support the Team. But what does the Team need?
There are several possibilities to find that out. The common ones are „Retrospectives, Reviews, Stand-ups, One-on-Ones (formal or at the water cooler) but there is at least one more and I call it „Teaching Probe“.
Why should you try the Teaching Probe?
- It only takes 5-15 minutes (in case your team complains about too many meetings, like every team 😉)
- It takes place in the Team location (no need to find an extra room)
- It limits your preparation time (1-2 flipcharts are enough)
- It helps you to focus on one very specific topic (otherwise you will run out of time)
How to do it?
- Prepare 1-2 Flipcharts for a small topic, a topic where you are unsure whether it resonates with the team or not.
- Schedule up to 15 minutes with the team after the daily Standup in the Standup location. I have used the backside of the team board in the past and it worked well.
- Present the topic to the team (Give them enough information so that they can decide if it is interesting for them at the moment.)
- Ask the team if they have
- learned something new,
- learned something old (something they had already forgotten)?
- Ask them what they want to do with the information. There are three options:
- Do nothing (the topic is not interesting enough at the moment)
- Make a decision to conduct a small experiment right away
- Schedule a meeting to talk about the topic in more depth (Talking about it during the next retro didn’t really work for me since I forgot about it or the topic was pushed back by more recent stuff)
Please leave a comment if you want to try it or if you have already tried it.
Is the works council really the enemy?
No, of cause not but it’s a provoking title which probably attracts more people.
Once I was talking with a guy from the Bigpoint works council about Management 3.0 and we came quickly talking about the implications for individuals. I usually can’t remember when a specific epiphany occurs but this time I could.
The focus of the works council is a single employee. Every single one. The one who doesn’t like to be more agile, the one who hates change and even the one who hates everything and should leave the company for good.
The focus of the Agile Coach or Scrum Master is the improvement of a whole team, especially regarding the frequent changing requirements.
Here are two quotes from Wikipedia regarding the works council („Betriebsrat“ in German) in Germany:
„The works council is responsible for protecting the standards which are beneficial for the employee.“ („Er hat darüber zu wachen, dass die zugunsten der Arbeitnehmer geltenden Normen eingehalten werden..“)
Standards are not per se bad. They help us to do things efficiently because we don’t have to negotiate every single action over and over again but they turn into a burden if they don’t lead to effective behaviors anymore. Standards are hard to change, especially if they are beneficial for individuals (as opposed to teams) and if a works council is present.
An example could be that everybody is free to stay in his/her home office on short notice without having asked the team for permission.
So, I don’t think work councils are generally bad but you should always keep in mind the goal of every works council:
„The works council is responsible for protecting the standards which are beneficial for the employee.“
Every once in a while someone in my work life mentions this word above, mostly in sentences like „We have to be more professional!“ or „That has to be be handled in a more professional way.“ Afterwards I have often ask myself: What did he or she meant?
My biggest fear is that it meant something like „We need to document more“, „We must stabilize our architecture“ or „Our client must describe precisely what he/she expects“.
All the examples above can be interpreted as „We don’t like uncertainty. Please let us do something so that the environment feels more certain and less scary“. Here my fear pops in because I know that some amount of uncertainty is necessary and even good („If everything seems under control, you’re just not going fast enough.“ –Mario Andretti)
When you hear someone using the word „professional“ next time, please ask him or her for the precise need which should be fulfilled in that special context and leave a comment in the section below. I will do that too.
I have worked as a developer for several years. From time to time an analogy from my interesting past comes to my mind and I ask myself whether this is helpful or not.
I currently ask myself if it is helpful to model a team as a set of classes.
What kind of questions do you want to be able to ask the team? Which questions/informations should only be asked within the team?
I have set up a github project (I am using ruby) to model these questions. (https://github.com/afuerstenau/planets/blob/master/team.rb). Feel free to fork the project and play with it.
I have seen different boards from several teams during the last couple of years and one thing that occurred to me was:
If your board doesn’t change over time something is wrong!
Why is that?
The board of a team reflects it’s process and the process depends on several variables: The team compilation, the surrounding environment and the understanding of the team about the surrounding environment.
So, if the board doesn’t change, it could mean that
- The teams process is perfect
- The teams environment is stable
- The teams process regarding the environment is perfect
The teams process is perfect
This means that there is blind understanding between all team members. Everybody knows what to do under all circumstances. It must feel like a well-oiled machine.
The teams environment is stable
The number of stakeholders is stable. The customers of the team are the same over a long period of time. The technology doesn’t change. This could happen in very large organization, where the team is responsible for an internal product.
The teams process regarding the environment is perfect
Even if somebody is on vacation and the next team member is sick, the third team member knows perfectly well how to cope with the requirements from outside the team. Everybody knows what the other team members where doing before they left for vacation or got sick.
So, I think I made my point clear. Even if some team has achieved some kind of perfection within one of the fields above I can’t imagine that this is possible for all three. It is much harder to imagine that some team might have achieved it for more then a few days.
There is a great model from Jurgen Appelo, called the fitness landscape where he describes the possibility of a team to adapt to changes of the surrounding environment.
It would be nice to here from you. What are your observations?
In my department work about 80 colleagues in several teams (more than 15 at the moment). Almost every team tries to be more agile and is holding Stand-Up’s and review meetings. Not everybody is interested in the progress of every team but a lot of colleagues are interested in at least several topics or teams.
The most important stakeholders for every team are invited via an outlook calendar entry and they attend the Stand-Up and reviews quite often. Every now and then it turns out that two teams have solved the same problem or that one team has produced a bug in the product of a different team. These things could have been avoided if someone would have attended the review or the Stand-Up’s.
The natural reaction was to set up a list of all meeting times and locations and have it printed out and put on the wall somewhere. The problem is that these informations tend to change over time. It’s not changing that often but it happens and having to change one more location makes it not easier.
But, is „How can we provide meeting time and place in a more efficient way?“ the right problem to solve? Or should we assume if a problem like „solving the same problem twice“ or „bug created in one product leads to a huge amount of bug searching time in a different team“ as a bad smell? Is it the problem that so many teams have to interact with each other?
If I take Dunbar’s number into account (He proposed that humans can only comfortably maintain 150 stable relationships) and I assume that the average team consists of 7 members that leads to 21 teams which should be able to interact. That seems like a pretty big number to me and I can’t imagine how so many teams should be able to interact. But how many teams should be able to interact with each other and when do you think you have revealed a bad smell?
I am very curious about your comments.
On Monday, 27th of August, the fearless hamburg group met at Bigpoints headquarter in Hamburg.
We tried to do the following things:
- Come up with a vision for the group (We did but I can’t remember the vision at the moment. Mhh, may be that’s not a good sign.)
- Find a new name for the group (We did: „DenkanStoos Hamburg“. The word „denkanstoos“ can have several meanings. 1. Remember stoos! or Don’t forget stoos! 2. „To give somebody something to think about“. I like the new name. :-))
- Clarify what we are going to do during our next meetings (We did it more or less. At least we came up with a tool to group the topics in a useful way. The future will tell how it works.)
The last point needs some clarification. We wanted to solve the problem that some participants want to focus on the whole society while others want to get some new ideas for their team. So we came up with this matrix. The y-axis contains the following levels (top to bottom) society, company, team, individual. The x-axis contains various entries (left to right) Empowerment, Gamestorming, Structure, Communication. The idea is that we could agree to talk about empowerment on one or more levels and anybody can decide for himself if he want to attend the next meeting.
Please feel free to add some comments if I was able to turn them on on my first blog post. 😉