1 – WHY THIS BOOK
Thinking about how to implement teams in the company, and in projects from the Incubator program, I thought that “The Discipline of Teams” could be a good book with some theories in it that could 1) give me some ideas, 2) back my efforts and 3) bring me some guidelines.
In our company we are currently working in creating a new team based methodology (called iScrum). I also wanted this book to give me some insights about it.
2 – FEELINGS ABOUT THE BOOK
Although the book has some really key and good basics, I have the feeling that through some chapters, it repeats itself quite a lot. At the beginning it was easy to read, but as I started to advance, I found that the reading wasn’t giving me more new knowledge.
Despite this, the book worked for what it was intended:
1 – I know have some theories that I can implement in the company and iScrum.
2 – Things are already happening in iScrum methodology that is being mentioned in the book (for example, we are focusing on too much individual single leadership work, although we work in a team). This book gives me the confident to know that this is not a rare case, and that a solution can be found.
But as I was saying before, as you move forward in the book, you find out that no more new theories are introduced, but only talks about different situations and how it affects to teams (or how teams affect to situations). And in my case, I felt that it was repeating itself, and it wasn’t so much valuable for me (maybe for others, it is).
3 – KEY IDEAS OF THE BOOK
3.1SINGLE LEADER vs TEAM DISCIPLINE
When talking about effective groups, you can work in SINGLE LEADER DISCIPLINE or TEAM DISCIPLINE. One is not better than the other one. You just need to know when each one fits best.
Summarizing a lot, Team Discipline is needed when you need to make 3 out of 1 + 1. This means, having time for dialogue and understand each others role to be able to make a job better than if each one would “do its part”. Single leader, in the other hand, is about doing individual work, and getting it done effectively. 1+1 = 2.
Team Discipline should be used when collective work has to be done, based on complementary skills and distributed value among all other team members.
3.25 FEATURES OF THE EFFECTIVE GROUP
You can know when your team is an effective group, if:
– Everybody understands why they work together, the vission.
– The group communicates and coordinates effectively.
– There are clear areas & responsabilities.
– It’s a time effective process (no time wasted on unnecesary discussions).
– There is a clear sense of accountability: individual and team measures and indicators.
I think this theory was key for the team to understand if we are on an effective group, or not; that’s why I even put it in theory during one coaching action: I made everybody grade, from their point of view, from 1 to 5, how much they thought they accomplished each one of these features. This way, the team had a clear situation of where they were and what they need to improve. And also, to know what perception has each other. It was quite an interesting workshop, followed by quite an interesting dialogue.
3.3OUTCOME BASED GOALS (SMART GOALS)
Goals of an effective group should be created based on outcomes. They have to be clear, and leave no doubt about if the goal has been achieved or not. That’s why goals have to be SMART:
- – Specific
- – Measurable
- – Aggresive, but achievable
- – Relevant
- – Timebound
This theory has also been interesting to apply during our coaching sessions. Now, all goals are SMART, and we have introduced this definition in iScrum methodoloy. All tasks and goals have to state clearly how they are achieved, and in which time frame: “The document has been given to the customer and they have approved it”, or “Pass the draft version of the document to the customer”, etc.
Although the book says that all goals should be outcome based, not activity based; I think that activity based goals are good very short period goals for team tasks (for example, “estimate three new projects in one month” is an outcome based goal; but “estimate this project and deliver it to the customer and agree a meeting to make a demo of it” is an activity goal. For me, the first one is valid for the common team goals, and the second one is valid for the team tasks. That’s what we are doing in iScrum.
3.4HOW TO PERFORM IN TEAMS
Although there’s really a few things new in this “performance agenda” from the book, it’s interesting to note how some key things that we are introducing now (when working in teams), are defined in the books. The book says that in a big project, you should work as follows:
- Define the project aspiration and visualize it with a SMART GOAL.
- Break it into subtasks
- Divide taks and assign responsabilities => This is what we do in iScrum. And actually, the book says “everybody should participate in everything, there should not be ‘reviewing positions’. Everybody should dirt their hands with tasks”. That’s something that we are introducing now: trying to fusion the “project manager” – “Analyst”, and “programmer” in one role “developer”, so everybody does more or less the same, although with different skills that everybody is aware of. That way, everybody knows who can ask for help and learn through the process. It’s working well in iScrum, and I think that in software consultancy sector, it makes the difference.
- Progress awareness, what is being done, and what isn’t, and why.
- Decide if tasks need SL strategy or Team Discipline.
- Analyze results, measure and make adjustments. The most important thing is to communicate the sense of progress, to know that the team IS NOT STUCK. We are making progress, we should celebrate it accordingly.
- Differentiate two kind of meetings, to know progress (short, concise), and the ones to work (training sessions)
- In iSCRUM we do 2 meetings: daily meetings (5 minutes to tell each other what we did yesterday, what we are going to do today, and if there is something that blocks us from doing it), and sprint meetings (like TA training sessions).
In this chapter, I also started to think the need of developing the Team Learning Contract, creating a common vision and define the SMART GOALS, break them into subchallenges, and make a plan. Also, the more gamified this process is, the better.
Team Discipline should be used when there is a task (that needs collective work), that cannot be done if each one would do it individually, or maybe it could, but the team learning needs to grow at the same rythm as the team.
When I see Team Academy, I see big groups working in Team Discipline (around 15 people each). I have always though that smaller groups would be better. In this case, the book agrees with me, and gives 6 reasons to be small groups.
This chapter also talks about the importance of feedback, and I see clearly the Motorola as a great template to do team-feedback.
3.6TEAM DISCIPLINE DISAGREEMENT
It’s interesting also, how in chapter 6, it talks about consensus. After my MINN trip, I’ve always thought that consensus was a great tool: you make everybody agree. But this book gives one step further, and talks about constructive disagreement.
There’s one failure in consensus: it sometimes makes you get to a point of no return. It’s better that voting, of course; but when everybody defends their position, at the end, one will have to “surrender”. In that case, we are loosing the creativity of what could happen if we integrated both solutions.
This book proposes to celebrate disagreements. And as an exercise, when disagreement happens, then, each one should try to defend the other one’s idea, and build from the dialogue that happens there.
It might be an interesting tool to put in practice next time disagreement happens (it won’t be far from today) XD
3.7APPLYING TEAM DISCIPLINE’S COMMON PURPOSE + GOALS + APPROACH
Common purpose is a need in Team Disciplines. The whole team must OWN the purpose. WHY DOES THE TEAM EXIST??? WHY WHY WHY.
In intrapeneurial teams, it is possible to match the “organizations purpose” with yours. There are good examples in the book. The team has two think as if there are two purposes:
– The broad purpose: by the organization. Example, “be a referer in software development”.
– The narrow purpose: you make it yourself for your team, “develop software with only 2% of bugs”.
Once the team has their common purpose (what the team is for), the team has to create their common GOALS, based on SMART GOALS.
As stated before, the team can work these goals through a Team Learning Contract. Once done, the team can answer the questions provided by the book in Figure 6.1
It is important for the team to have the sense of progress: the goals are being developed, and achieved.
A good working approach is:
– Find earyly wins
– It’s better to stablish only FEW expectations from others to start (but define them and state them clearly) “I expect from you to be here everyday”, or “to help me in every analysis because I am new”, …
– Bring fresh ideas once in a while => cross fertilization, maybe with other teams, or even with top managers to check what we are doing and how iScrum is being developed.
– The importance of good constructive feedback (“feedforward”).
– Goals not based on activities, but outcomes.
I think that accountability is needed, and is key to measure yourself and the team. The book gives too much importance to the “mutual accountability”, and only few importance to “individual accountability”, but I think both of them are superimportant.
– Individual accountability: is what gives us confidence. It’s easy to understand. It’s easy to check how I am among the rest of my team learners.
– Mutual accountability: to have the sense of the advance of the team. Dialogue is needed to talk about it. Based on goals + deadlines + timeframes.
It’s important to remember that in Team Discipline, there should be no “finger pointing”. The whole team is responsible of success or failure. If one inidividual is failing all the team, it will be obvious at the end, and finally will leave or do only low-level tasks.
3.9 SIX FLAGS to CHECK IF YOU ARE IN A TEAM DISCIPLINE OR NOT
It’s curious because I disagree in some of these definitions:
– Beware if there is a name in each task: I think the operative tasks have to have leaders and operational people: who is going to do it. I don’t agree with the book when they say that if you do this too much, then you are single leader.
– Only account based on money. Find also some other “outcomes” indicator.
– Too many one to one meetings.
– Meetings to tight, no time to creativity meetings or working team meetings (training sessions).
– Leader only “reviews”, does not do any real work. This one is interesting because is something new in iScrum that we are trying to implement clearly.
– Team doesn’t have a purpose more than the one of the organization.
It is also important the language used in the team. Maybe you don’t realize, but too manys “I / me”, and too few “we / us”, really indicate something wrong.
Also, dialogue and feedback is based on proper language, so it is important to remember it and check it out sometimes.
As an interesting exercise, the book proposes that one observer checks the language and gives feedback after the session of how many “I” vs “We” there were, how the agreements where achieved, etc.
The books talks in a couple of chapters about Groupware and Virtual teams, and tools to make the team more united. In this case, I feel I didn’t get anything new, maybe because we work with people in Argentina and we have experience in that. Although we have problems integrating the team in Argentina with the ones in Bilbao, the book didn’t give me any new insight about it. I felt disapointed about this.
For me, main ideas in Virtual Teams are:
– Logically, it’s not the same to work with someone in the same place and room, than with someone outside. You need contact to make trust, passion and common purpose.
– Today’s techonologies can’t overcome this problem: there’s the need of physicial meetings once in a while.
– Software helps, but DOES NOT REPLACE this contact.
– Software has good points that you should take advantage of: ability to asynchronously communicate through message boards / emails, versioning systems, etc. But they should be used as a TOOL, not as the GOAL itself.
– Not only is about software, but also about difference in cultures. It’s not the same Argentina as Spain, for example. How do they work in teams in Argentina? The book here advises about making one “team character” of their own in the team.
3.12THE TEAM GETS STUCK, IT HAPPENS
It’s important not to frustate if the team gets stuck. It happens. It can also be seen as an opportunity: 1) gain commitment, 2) be more confident when the obstacle is overcome 3) learn a lot during the struggle.
The book also explains why teams usually get STUCK.
- Unclear goals
- Mistaken attittuedes (“me vs. The team”).
- The team does not have the needed skills. One of my biggest fears: what if we are trying to build something but we don’t have the skills?
- The team changes, people come in and out
- Time pressure
- Lack of discipline & commitment & spirit.
While I was reading them, I realized that these were my own fears. These are the fears I have when thinking that maybe, team development doesn’t work in the company.
Options to get UNSTUCK:
- the team internally solves it: “gets closed until they solve it”. Check the COMMON PURPOSE, WHY do we exist. Maybe reset goals, easier ones? Check if any member is an obstacle.
- The team needs external help to solve: only if (1) doesn’t work. (It happens know too much in our company that we need external help to much, we go to our managers’ office to help us with the problems. We should try to work them as a team first!). Other tools that can help: new members (maybe only temporary), external facilitators or coaches, training, etc.
There are sometimes that the TEAM IS DEAD. It is important to detect it, because putting to much energy on that, doesn’t help. In that case, it is better to leave it alone, or make a drastic one-time change.
I think from these points, the first one “a team leader that cannot give up control”, is what is more common: you cannot go and say, “you all are equal now”. It’s not the way to do it, and you can’t start from there. But to change it, is not a matter of time, is a matter of seing results somewhere, and learn from there. That’s why I quit from coaching my last team, I prefer to put efforts somewhere else, and when results come, then I can come back and try again.
3.13HOW TO CREATE CHANGE IN THE ORGANIZATION
There is also a chapter only for “teams and change”. From that chapter, I get overall the idea of “how to lead the change in the organization”, with these key points:
- Focus on performance, and measure outcomes.
- Not many “team dynamics”, start little by little.
- Train groups, not inidividuals.
- Using teams is the mean to get something bigger, not the goal itself. “Si usamos equipos, es el medio para llegar a un fin más grande, no es el fin en sí mismo”.
- Take care of the language.
- Create a critical mass of change leaders. I think this also is important.
Although not in the book, this chapter also remembers me the theory I’ve been working on about how to focus communication in a proper way. Now what happens is that communication is difficult to make it through everybody. It’s impossible to managers in the company to talk to everybody, and unnatural to do it through emails to explain how things are going. We create different spaces to talk about different matters, but it’s impossible to explain it all.
In small teams, this doesn’t happen, because everybody has the space, time and trust to talk about it, in the corresponding dialogue.
For me, the solution is to have these change leaders, that also work in a team, and are the “conductors” of the communication. And are leaders who team learners in their team trust, so they will have space, time and confidence to talk with them about things that matter, and the vision of the company is conducted through them to everybody in the organization.
The change leaders’ team consist of people in which the majority of the workers trust, as they are natural leaders in each one of the teams.
4 – SOME SPECIFIC IDEAS TO REMEMBER IN SHORT TERM
From all of the above, here are some short ideas to remember in short term:
– Get the Team Learning contract: define SMART goals, make subchallenges, a plan, and gamify it. Also play the questions in 6.1. But make clear: WHY DOES THIS TEAM EXIST?
– Consensus vs constructive disagreement. Celebrate disagreement. When there’s disagreement, we could try to force ourselves to try to defend the other’s position, and see what we can build from there.
– Bring “managers” or other team learners to iScrum mettings, to cross fertilize.
– The importance of accountability: individual (from tasks) and mutual accountability (from
– Check language sometimes.
– The team needs, in a lot of cases, external help to solve problems. It happens know too much in our company that we need external help: we go to our managers’ office to help us with the problems. We should try to work them out as a team first!
– Create a critical mass of change leaders, a change leaders team.