To team, or not to team – That is the question

Teams are the holy fundament that agile resides on. Teams should be autonomous and cross functional. Teams should be kept together over longer periods of time to become good at what they are doing, to be high performing. This is sort of ”common sense” in the agile world today, we all know this. But what if the team model doesn’t fit your needs?

To team, or not to team?

It happened during one of our biweekly meetings that discuss continuous improvements to the process. The question ”Why can’t we split the team?” was raised. The discussion started and soon the more general question ”Why do we work in teams at all?” was brought up. I was sort of defending it, teams are the way to go and we should not change that, but afterwards I started to think. This blog post holds those thoughts.

Questioning teams

Some background first. We have a relatively small development department. It is currently divided into three teams. Each team has their own set of responsibilities. Personnel has stayed fairly intact over time so everybody knows each other in the department. Each developer has a broad competence, meaning that most of them can do all types of work. Some of the developers have ”special competence” regarding certain areas.

Back to the question about teams. It was raised because only two persons is allocated to work with one of our responsibility areas. Two persons are not a team. Why not have a kanban board for that responsibility area, and have a daily meeting where people that has an interest in this responsibility area can participate? The kanban board then don’t belong to a team, but rather to a responsibility area (this could be one of your products for example).

This thought is not new. I recall that I have read in a David J Anderson book that they had a kanban board and a daily meeting with 50 participants (yet the meeting took less than 10 minutes). I hardly think those 50 persons thought they belonged to the same team, more that they shared interest and participated in a work flow (depicted on the kanban board). I also know that Spotify makes many small organizational changes. On a regular basis (quarterly?) they form the teams (they call them squads) needed. Afterwards they evaluate and re-forms the teams if needed.

”Temporary groups”

I have an example of this that I would like to share with you. We needed to make a new release of one of our old products (that is not in our main focus anymore). Before when that have happened, we have spread out the work on the individual teams, to be fair to the persons that holds the ”special competence” needed to make the release. Work has then not become prioritized and have been dragging for months before it got completed.

This time we thought to try something different. Why not setup a ”temporary group” (I call it so in lack of a better name) and take out those ”specialists” needed from their current teams. We prepared a kanban board and set a time for a daily meeting. Work started and the focus was really good, the ”temporary group” completed the release work in 13,5 working days! The same type of release took two to three months in lead time to perform when working the old way. After the release was done, the persons in the ”temporary group” re-joined their former teams.


What I am trying to describe is to have ”temporary groups” that forms some sort of task force to come together to solve a particular mission, then they are scattered to be able to join in on something else. Do you have experience in working in this manner when it comes to software development? I would really like it if you can share your stories!

All the best,
 Tomas from TheAgileist

Smells like team spirit

During my vacation I had a great talk with two of my wife’s relatives. They are both into team sports; one is a youth soccer coach and the other is a professional ice hockey player. My main question to them was: How do you get good team spirit?


(Picture taken from

UEFA U21 2015

Earlier this summer Sweden won the European championships in soccer for players under 21 years (UEFA U21). How could that happen? Sweden is a small country with only nine million inhabitants. Large parts of Sweden are covered with snow during parts of the year, not making ideal conditions for practicing and playing soccer. During the tournament Sweden competed against more respected ”soccer countries” like England, Italy and Portugal. They had teams packed will already well established players with ”star status” in their respective clubs.

Not having the best players on the individual level, there most be something else that made this possible. My take is that it was the team spirit. A strong force that is created when a team comes together as one. Like the following quote:

”The whole of the ant colony is greater than the sum of the ants.” – Andrew Stellman & Jennifer Greene, taken from the book ”Learning Agile”

Factors for team spirit and thereby success

Back to my question about team spirit, here are the answers I received:

  • Trust – A team can’t function if the individuals don’t trust each other. Without trust you don’t have a team, what you have then is individuals grouped together. Trust is the fundamental base for a team.
  • ”Högt i tak” – A Swedish phrase that roughly translates to ”height up to the ceiling”. This means that there is a climate in the group that allows different opinions to be expressed without fear of them being turned against you. This may sound a bit fuzzy, so let’s break it down a bit:
    Questioning – If only one or a few voices are to be heard in a team there is no questioning. Without questioning not all brains are used to make the best decisions possible. Utilizing all brains in the groups is better then just using one! The climate in the team must be that everyone has the possibility to discuss and influence important decisions before they are taken.
    Dare to fail – Without trying out new things and thereby risking failure, no learning takes place. Without learning there is no moving forward. Barely holding up status quo is not an option anymore, your competitors will destroy you!
    Dreaming – Months before the UEFA U21 tournament started no one thought it was possible for Sweden to win! All except one person, John Guidetti, one of the key players in the Swedish team. He thought it was possible, he even said it in media. By formulating the dream, the others in the team bought into it, and made it happen! John Sonmez has a great saying for this: ”Act as if, them become!”.
  • Humble – For the team to be truly successful each individual needs to put the goals of the team first, before any individual and more ”egoistic” goals. The team players needs to be humble to the greater course of the team. This comes very natural for Swedish people, it’s part of of DNA to be part of a group/team and to put the goals of the team first. You can even say that is part of of our social democratic legacy (however now the society is being more and more focused on the individual, like in many other countries). There is another Swedish phrase for this, ”laget före jaget” (translates to ”the team before my own needs”).
  • Acceptance of roles – In a team, different roles and competences are needed. When you are assigned to a role, you need to accept that and not complain that you want to do something else. In a soccer tournament this is especially true for the players that are substitutes and get very little time to play in the matches. They need to hold their head high, not whining, and still contribute to a good team spirit.
  • Time limit – For a team to come together the ”extra effort” needed has to be time limited, like during a tournament. A ”bubble” can only exist a certain time before it pops.
  • Underdog – Swedes like to be the underdog, with no initial pressure, building up confidence for each match and then finally winning it all. It seems to be very suitable for our mentality. Other countries may need the pressure of being favorites from the beginning to be able to ”get that little extra” to win.

How this translates into the world of software development

Some great answers above, but I guess you wonder how they can be translated to our world of software development? Here is my take:

  • Trust – This is a basic foundation for any team!
  • ”Högt i tak” (Everyone is free to express their opinions without repercussions)
    Questioning – As stated, the right level of questioning needs to be present to reach the best decisions in a team. If not, we a back in an old ”command & control”-manner where only one or a few persons make all the decisions.
    Dare to fail – Without the courage to fail sometimes we have no experiments that in turn leads to continuous improvements (kaizen).
    Dreaming – Any team needs a visionary person. Might it be a person in the team or someone ”external” that can influence and ”sell” the bigger picture. However, the ”dream” must be seen as reachable, otherwise the ”dreamer” will just be neglected.
  • Humble – The goals of the team must be treated over the personal interests of the individuals.
  • Acceptance of roles – If you are a developer that is your primary focus. But if testing skills are needed at a certain time, the same person shall not turn those tasks down. Even if you are a striker in soccer, you have to participate in both offense and defense.
  • Time limit – In an organization that works day out and day in, it’s harder to find natural time limits. However, a project is naturally time limited and the time boxing aspect also exist in Scrum with the sprints. These can be used as time limits to create focus.
  • Underdog – What we can take away from this is to set the right expectations for the team. The right motivation will make the team perform better. If the expectations are unrealistic, they will be neglected as stated earlier.


I hope you have got some more ideas on how to create team spirit. It all starts with trust, then humble team players will come together and reach the challenging goals set for the team!

All the best,
 Tomas from TheAgileist

Lean Change Management

The Christmas holiday is for me time to read and reflect. This year was no exception. My Agile endeavor has continued during 2014, but it feels like we have reached a plateau. Agile acceptance and adaptation are high within the IT department, the challenge now is the rest of the organization. That must change during 2015! 

”The only thing constant is change” – Heraclitus

If change is a natural part of life, how come it’s so hard and sometimes painful? To find out, I did my normal routine and started to search for books on the topic. Pretty soon I found ”Lean Change Management” by Jason Little. The subtitle of the book is ”Innovative practices for managing organizational change” and it was released 3 October 2014.


Lean Change Management Cycle

The book introduces something called the Lean Change Management Cycle that consists of:

  • Insights
  • Options
  • Experiments (with the sub-cycle below):
    – Prepare
    – Introduce
    – Review

This non-linear, feedback-driven model for managing change is explained in more detail throughout the book. Insights is the understanding of the current state in the organization. Options have a cost, value and impact. They include one or more hypotheses and expected benefits. Hypotheses are turned into Experiments. Prepare is the planning stage of the experiment. Introduce is where you put the experiment into real action, and Review gathers the outcome.


Without a framework or some sort of mental model, change management can be very hard. The book presents two frameworks.

Kotter’s 8-step Change model

This was introduced by Dr. John Cotter and holds the following steps:

  1. Create Urgency
  2. Form a Powerful Coalition
  3. Create a Vision for the Change
  4. Communicate the Vision
  5. Remove Obstacles
  6. Create Short Term Wins
  7. Build on the Change
  8. Anchor the Change in Corporate Culture
McKinsey 7S Framework

Tom Peters and Bob Waterman created the 7S Framework in the 1980s.

  • Hard factors
    – Strategy
    – Structure
    – Systems
  • Soft factors
    – Shared values
    – Skills
    – Style
    – Staff

Other valuable information in the book

Blast radius is a model for understanding the consequences of a change before it is introduced. Hypothesis creation template is a you can imagine a valuable help when you create your hypotheses. As you might have understood by now I’m a big fan of visualization and this book holds two more good examples of that:

  • One-Page Change Plan
  • Strategic Change Canvas


First I would like to quote the author:

”My goal with this book is to help other change agents find a more people-centric, and feedback-driven approach to change”.

This book gives great ”tools and thinking” for change.  I believe that I now have everything needed to proceed with the necessary changes in 2015. If you want to know more, you can visit the Lean Change Management website. I also found the following short introduction on YouTube.