Author Archive
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?
Change – It Starts With One
Posted by: | CommentsI just finished an excellent book on change:
It Starts with One: Changing Individuals Changes Organizations
This book does an very good job explaining how to move an organization through change. As with Agile the principles in this book are simple but difficult to implement. Here are the three principles of implementing change in an organization:
- See”…we must understand that people will not change if they fail to see the need and they often fail to see the need for change because they are blinded by the light of what they already see—the powerful mental maps that have worked well for them in the past.”Our own successes are often the reason we do not see the need for change.
- Move”First, even after we have helped people see that the old right thing is now wrong, and we have painted a picture of the new right thing, that new map must have a clear destination or vision.”People need a clear vision for change. But change always involves personal risk. These risks must be mitigated so as a person moves through a time of incompetence they know that their will be rewards along the journey.
- FinishSo many times change is not successful because people get tired or lost.Change is hard and it is so easy to go back to doing what you comfortable doing and are competent in doing. During this time of change constant feedback and encouragement are needed.Also it is easy to get lost when making the change. Often people wonder are they making a difference or are they performing the correct tasks.
This books gives excellent examples and tools to use to help implement change in an organization. As Agile coaches we are often in the middle of change in an organization. I know from personal experience it is helpful to have additional insights on how to manage change.
Problems With a Release Plan
Posted by: | CommentsI work for a Fortune 500 company and we are implementing Scum. Within the Scrum framework you are to do a release plan. When working for a start-up company this was very straight forward because only one team was working on a product line and we could create a credible release plan. But in a large organization release planning for a team is much more complex. We have a product that has multiple teams and multiple product owners. At this time our release planning is not working. We have not had a successful release plan. Here are some of the reason I believe this is true:
1. The product owners are not empowered
The product owners do not really have control over the product. There are other stake holders that really are driving the product. Therefore the product owners are always reacting and are not able to set a true product road-map.
2. There is not one Product owner for the overall product
This person would handle the priorities for the product as a whole. Our product owners need direction and coordination from the lead product owner. This would help protect the individual product owners from all of the stake holders that are seeking to set priorities.
3. There is no vision for the product
There has to be an overall vision for the product. Why are we doing this product, what are our goals, etc.? This vision must be clear and concise. This vision is what we look to when the product owners set their priorities in the backlog and when there are conflicting priorities.
4. There is no vision for the periodic releases
Each release must have its own vision. What is the reachable goal for this release? How do we coordinate our teams to meet this release goal.
Without these basic fundamentals in place it is going to very hard for the product owners to create a credible release plan.
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.
Are You Reading?
Posted by: | CommentsI believe that a college education’s purpose is to train you for a lifetime of learning. I myself have a liberal arts degree in biology and chemistry. My present occupation has little to do with my degree but my education helped to train me to learn.
Reading good authors is an inexpensive way to do self training. People are always amazed at how many books I own. A good friend of mine asked me how many linear feet of books shelves I have. I never considered that question before and the estimate I came up with is 250 linear feet of shelf space. Needless to say I am an avid reader.
This amount of shelf space has caused some friction with my wife. So now days I do not buy physical books if I do not have to. If I buy a book I try to get the Kindle version or the mobi version. I have readers for both. I read them on my TabletPC which is a slate form factor and on my iPod touch. It sure beats adding more book shelves and pleases my wife.
I have a subscription to safaribookonline. This is really a great technical resource. There are thousands of technical books available for you to browse or read. What is really great is the Rough Cuts section. This allows you to read books published by Addison-Wesley before they are released. In the last six months I have read all of the new Mike Cohn Signature books weeks or months before they were published.
I have listed some of my top books for Agile practitioners in the side bar of my blog. Please take a look at these books. I will be adding more books in the future.
As I always say “Leaders are readers and readers are leaders”.
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.