Archive for team
Command and Control
Posted by: | CommentsI have just started reading Collaboration Explained: Facilitation Skills for Software Project Leadersby Jean Tabaka. Over the next several posts I will basing my comments on material I have read from this this book.
As you know, I am very interested in what is involved in creating a high performing team. Why do we not see more high performing teams in corporate America? I believe that the “command and control” management philosophy contributes to this.
Now if you ask most ScrumMasters if they use command and control and they will say no they do not. But is this really the case when they are working with teams?
Here are questions you should ask yourself about you interaction with the team:
- Are all decisions involving the team made by the team?
- Does the team feel they control their destiny?
- What are the factors that prevent the team from being empowered?
Review you own style of facilitating. Then ask the team to evaluate you style of facilitating. As with all Agile processes this constant inspection helps us to improve how we interact with the team.
Team vs Team
Posted by: | CommentsI have been thinking about teams and teamwork. Every company I have worked for will say that they have teams of developers working on a project. But what type of team are they working on?
Growing up I participated in teams sports. As I reflect on my high school years there were two types of teams I played on. I participated on both a track team and a football team. Let’s look at these teams.
Track Team
On a track team each team member has their own specialty and tried to excel at it. We as individuals tried to finish high in our event so that we could get points for the team. The team that had the most points in the end won the meet. When I ran the two mile run it was up to my performance in how I finished. During training I would get suggestions from others on technique but individual performance was key to creating team success. No real collaboration was need when we participated in the meet. The only place you saw collaboration was in the relay races.
Football team
I also played football in high school. This is a team sport where collaboration was critical. We had a play book to memorize. Each team member had to know their position on the team and usually several other positions in the event someone got hurt. We huddled together, heard the play and then we executed. Practice during the week focused on the execution of the plays in order to prepare for our game on Friday night. We worked on perfecting our “product” so it we could have a good “demonstration” for our “customers”.
In my experience most teams in a large organization are like a track team. The teams are made up of highly skilled developers with very little collaboration between the developers.
A Scrum team is more like a football team. We have a play book we must execute against. Our understanding of the play book and our role on the team is important for success. Also, being able to learn other roles and assist where ever needed is important for a team.
What type of team are you on?
Culture: Competence verses Team
Posted by: | CommentsFor most of my carreer I have worked in organizations with a competence culture. This is a culture that relies on very good developers who do their job well as an individual. The individual is recognized for their contribution to the organization. I have to admit I have performed well in a competence culture. During my tenure at Texas Instruments I obtained the position of ”Member, Group Technical Staff”. This is Texas Instrument’s first level of recognition of key technical leaders.
The competence culture seems to have served most of the companies I work in well. So what are the downsides of such a culture. Here are some of my observations over the years.
- Knowledge hoarding
Knowledge is the key in the competence culture. The more you know and understand the greater the recognition. You do not have time to mentor others because you want to make sure your corner on knowledge is protected. - Individual politiics
It is who you know and can impress. Now no one would admit this directly but we act it out. We make sure we get invited to the right meetings and talk with the right people. - Lack of code ownership
As we move about the company we leave our current projects to work on new better projects. No one really owns the code. It is left for others to fix the bugs. How do you track down who can work on a bug when no one owns the code? Take a look at some legacy code. How did the code become such a mess? Was any one really proud of the code? - Lack of continuity
No one really understands the legacy code because the individuals are gone who worked on it. There is no shared domain knowledge.
How does this differ in a culture built around teams. Here some of my observations:
- The team is the priority
The idividual becomes a contributor on a team that is greater the sum of it individuals. We work first and formost for the team. Other commitments take a lower priority in the company. - The team grows individuals
In participating on the team we become better and more well rounded developers. The individuals share their knowledge with each other. We work on helping each other to enchance their skills. - The team respects individuals
All of us have important contributions to make to the team. The most junior developer is considered a very important member of the team. We listen to and respect all voices. All of us have blind spots and it takes others on the team to protect us from ourselves. - The team become the repository of knowledge
We as a team take responsibility for the software we are working on. We as a team own the code we work on. If a defect is found in our code we will fix it. It is the teams code not an individual’s code. So if an individual leaves a team others in the company know who to turn to when a defect is found in our code. - The team become the champion of quality
We set our standard of quality. We want our team to be recognized for producing quality products. We know our reputation as a team depends on this and we cannot hide by moving on. We are really proud of our code.
This ideal culture built around teams takes years to build. You cannot be reforming teams every 6 months and expect to create a culture based on teams. Teams need to be in place for years. Sure the members of the team may change but the team itself will live on.
In order to have long lived teams it is best to have 7 members on the team. This way even if two team members move on at the same time you still have enough core team members to move forward and train new team members.
Team Formation
Posted by: | CommentsI have been helping a new team form over the last 2 months. As the ScrumMaster I have been really interested to see the team become a high performing team. Team dynamics are really hard to understand especially in a new team. Here are some principles I believe are really important to help the team become a performing team.
All Teams Go Through the Storming Phase
Why do team members try to fool themselves that they do not need to go through a storming phase? I see this in many teams with which I have worked with. They will tell you that they get along and they have passed the storming phase. I know it is not so. We have not experienced “Fierce Conversions“, conversations that are courages, authentic an clear. We definitely need these during the storming phase. And without them we will never really get out of the storming phase.
Confidentiality
It is so important that what is discussed in the team and how we come to our decision is held in strictest confidence. Because I have worked with teams in multiple environments at work and outside of work I learn to live by this principle. But that is not so in a new team that is going through the storming phase. During this phase difficult issues are faced and not all team members agree with the team decision but will abide with the decision to see if can work. Team members must not express their displeasure to management for a decision that team has made. Team players keep it within the team.
As a coach I have challenges ahead of me to help the team. They are great people and make a great team. Helping them requires that I understand my own style of coaching better that I can lead them to understand these principles.
Who Makes a Good ScrumMaster
Posted by: | CommentsWe have created 7 new Scrum team as we transition toward Agile in our business unit. Each of these teams has been assigned a ScrumMaster. Each of the ScrumMaster has been given some training. The teams have started using the techniques of Scrum such as a planning session, daily Scrum meeting, sprint demo and 3 week iterations. Some teams have started doing retrospective. But are we actually realizing the full benefits of Scrum?
The ScrumMaster plays a pivotal role in helping the team adopt the spirit of Agile. They need to bring the team to an understanding of why certain practices are important. I know for many years as I lead ScrumTeam I have failed in getting the team to understand why we use certain practices.
Here are some qualities of a good ScrumMaster:
- Be a listner.
They need to really understand the team. How are the team members relating to each other? Are they really working together? Do they respect each other? - Be a Team Coach
They take responsibility for the team’s adoption of Scrum. It is important to monitor the teams progress toward adopting the practices of Scrum. - Be a Team Member Coach
The team is made up of individuals. The ScrumMaster takes interest in each individual so that they can achieve their maximum potential. Each individual will accept the tenants of Scrum in varying degrees. We need to know where the individual is in their own adoption of Agile. - Be Humble
They are not doing this so we can enhance our personal resume and show everyone what we have done. We take pride in what the team is doing. It is what the team has accomplished that makes a difference. The ScrumMasters roll is that of a servant-leader. - Be Passionate About Agile
A good ScrumMaster really believes in what they are doing. They have an enthusiasm for Agile. They have been trained and are continuously doing self training in Agile. They want to do the best job they can. - Leave it to the Team
A good ScrumMaster does not make decisions for the team but lets the team make their decisions about the process. The ScrumMaster will train and guide the team but will not make decisions for the team.
There are other traits that are good but the ones I have listed I consider to be critical. Unfortunately I have not witnessed these qualities in most ScrumMaster I work with.
How a Team Thrives
Posted by: | CommentsIt is really exciting to see team meet their potential. This is one of the most gratifying experiences I have had as a ScrumMaster. What did make the team such a success? Here are some observations:
- The team was co-located in a large office. Our desks were around the perimeter of a very large and spacious room. This allowed for us to communicate freely.
- We were “isolated”. The team was located 200 miles from the corperate head quarters. The team was self organizing and knew what their objectives were.
- We could move fast. We were working for a startup company. There was less bureaucracy to have to deal with.
- We respected each other as team members. We had been laid off together froma previous employer and knew each other well.
- We were not afraid to try new ideas. Our team tried new technologies with impunity.
- There was no fear of failure. We were confident in our own skills and the company wanted us to try new ideas.
These factors help us to be a very productive team. We were always presenting new and exciting features with everyone of our sprints.
These are all critical factors in forming the team that is high performing.
Team Members as People
Posted by: | CommentsThere is a human side to being a ScrumMaster. So many times we forget about this. Do we as ScrumMasters really look at the members on our team as people or as objects. Now I know this seems like a silly question. You will say of course we do think of them as people. But is that really the case? Think about the following:
- Do you ever think of a member of the team as a problem that has to be fixed or do you really try to understand his or her reason for their behavior?
- Do you spend time learning about a team member’s hopes and aspirations?
- Do you know the names of their significant others?
- Are you really concerned with their professional and personal growth?
I know this may seem necessary because we are technical professional like dealing with one and zeros and not with the soft sciences. But as a leader it is important you really know the members on you team not about them. But I must warn you that you must be sincere in this venture. You must check you own attitudes about team members and make sure you are really concerned about them.
Product Owners
Posted by: | CommentsWhat does a product owner do? What is his or her responsibility? Who makes a good product owner?
These are all critical question when adopting Agile. The role of a product owner is unique to Agile. It is the combination of multiple roles.
An excellent new book is being published on the role of the product owner:
I have been reading the electronic version of this book and found it to be very informative. The chapter headings are:
- Understanding the Product Owner Role
- Envisioning the Product
- Working with the Product Backlog
- Planning the Release
- Collaborating in the Sprint Meetings
- Transitioning into the Product Owner Role
Roman Pichler, the author, does an excellent job of presenting the material. This book is another excellent addition to the Mike Cohn series.
The book will be available the middle of April.
Sit with the team
Posted by: | CommentsTeams are core to agile practices and a ScrumMaster plays a critical role in optimizing team execution. One of the common impediments that interfers with this is the team work area or lack thereof. Without a common workarea it is very difficult to really understand what is going on with a team. The daily standups are a very inadequate way of tracking team progress. So much more is learned when you hear the intra-team discussions. It is these informal times expose what is really going one with a team.
We as ScrumMaster need to keep in continuous touch with the team. It is imperative that we sit with our teams as much as possible. This is the only effective way you can be an effective gate keeper.
One for the team
Posted by: | CommentsAs a ScrumMaster I am really sold on the Agile methodology. My enthusiasm can create angst for the team. I am really proud of the team I am working with right now. They have overcome many obstacles and really embrace Agile. They do not have a “cargo cult” mindset but a real commitment to be the most productive team in the company.
The team is willing to be a leader and will take on the risks. Because of this can do mentality I wanted to have all who were interested to view our first sprint demo. So what I did was use the largest distribution list for our department for our invitation list. Well this was a mistake and really caused the team to become very uneasy. They pointed out that we had overcome many obstacles in this sprint but there was not really much to show for it in the demo. We have completed one user story well and it is “done” according to our new standards of acceptance but it was only one user story.
They were correct. Perception is everything and we only have a “simple” user story to display for all of our work the last 3 weeks. The extended stake holders would not really understand what was involved in what we accomplished.
So I canceled the original meeting and invited a much smaller group to stake holders to the sprint demo. A lesson learned on consulting the team before make a major decision on who to invite to our sprint review.