Archive for team
Scaling and Architecture
Posted by: | CommentsOne of the concerns about Agile has been how to scale in a large enterprise system. How do you coordinate teams and have them provide a product that is based on a consistent architecture?
Some approaches are as follows:
- Do a big design up front and design the architecture that everyone has to follow
Well BDUF do not withstand the test of time. We know any architecture will be modified as soon as we start programming. - Have an architecture review board
This ends up being a bottle neck in the process. These architects are not really doing the coding so they do not always understand the issues that are being faced. - Do nothing and let the teams be
Well this is tempting and just let the architecture emerge from each team. But you lose consistency really fast. Also, the individual components do not work together well. - Use the Scrum of Scrums meeting
This is a meeting that focuses mainly on inter-team impediments. We have to remember to keep our meeting focused on their agenda and not to try to do to much in one meeting.
So I propose that a formal community of practice is the answer to this problem. We must recognize that teams left to their own will approach architecture is different ways. This is of real concern on a large project with multiple Scrum teams.
What is this community of practice and what do we expect of it?
- A weekly meeting with one developer from each team
This has to be an regularly scheduled meeting. It can range in length from 1 to 2 hours. I recommend that the developers be rotated who represent the team and make this a monthly rotation to keep consistency. - Each team presents the code they have developed during the last week
This is a high level review of the code. At this time the architecture of the code is reviewed.- Does the code follow best practices?
There should be automated tools to help enforce best practices. So the question here may be one of accountability. - Does the code enhance the overall design of the system?
- Is there duplicated code between the teams?
- Where can the code be more efficient?
- Does the code follow best practices?
- Each team is responsible for refactoring their code
The changes will be agreed to by the community and implemented. With this continuous inspection the architecture can be refined and adhered to.
One of the guiding principle of Agile is continuous inspection. The community of practice is a necessary meeting when working with multiple teams. It will scale in a similar matter as a Scrum of Scrums.
Blended Agile Process
Posted by: | CommentsA common comment I hear in the company I am working for is that we cannot be completely committed to a pure Agile process so we are going to use a blended Agile process. There are many way to interpret this statement but I like to draw a analogy. As usual I am using a sport analogy. Most people can relate to these analogies.
Here we go. My Texas college has been playing American football for years. We are a small school and this game has been very expensive to maintain. After the latest soccer world cup we decide we want to switch over to soccer. Now this is not being received very well by our alumni. After all this college is in Texas and football is supreme. Our alumni are major contributors to the college so we cannot offend them even though it is cost us precious dollars and resources to maintain the football program.
So here is the great idea that the athletic department has come up with. Instead of doing a complete switch from football to soccer let’s move to soccer without breaking the rule and try to please our alumni.
- We will use our football pads in soccer
We made such an investment in pads for the players we cannot do away with these. Do not mind that it slows down the players on the soccer field it has been proven that pads will protect the player. - The new soccer team will wear the old football uniforms
We cannot waste what we already spent on uniforms. We know they may get in the way of moving the ball down the field. - The soccer team will huddle every time they want to move down the field
Huddles were very productive in football so they should work just as well in soccer. They allow us to determine what strategy we should take in moving toward the goal. - We will form a scrimmage line before each play
We have to know where the player are and were they will be after we start the play. We can call the play and be able to execute it.
In the above scenario we have not broken any of the rules for soccer. We have just adopted our previous experience in football to soccer. Tell me what success do you think this new soccer team will have? To switch to a new game you need to be committed to making a complete change.
Both football and soccer have very similar objectives, you move the ball down the field and get it across the goal. They use the same playing field and both have players that move the ball toward the goal. But how they do this is very different.
When switching for a waterfall to a Agile methodology you cannot have it both ways. Practices have to change in order for there to be success in the Agile process. Each have a very similar goals but a very different approach. Do not try to “blend” the approaches.
Safety of the Team (part 2)
Posted by: | CommentsI have been reading about the different meetings an Agile team has over the course of a project. I have come to realize that these meetings when done well offer a sense of safety for a team. Well thought out and facilitated meetings help the team move toward being a high performing team that provides safety to its members.
- The team chartering meeting
Any time a team is formed or there are major changes on a team you need a rechartering meeting. This meeting helps define the goals, rules and social order of the team. The members of a team start trusting each other because as a team they are making rules they will operate under. The initial interactions take place in this meeting. You have a chance to learn about the personalities of the individuals. Also, this is a time for you in encourage team members to share their past technical skills and personal goals. This collaborative even will help team members realize that they are not “alone” but have others who are willing to work with them and help them to overcome any obstacle. As the common saying goes “There is safety in numbers“ - Planning meeting
Most people have their work planned for them and they just do their job. Actually being able to plan the short term schedule can be intimidating because you are going to be held accountable for it. But being able to plan as a team helps eliminate the unknowns. There are many voices involved in doing the planning and thus the risks are mitigated. Each team members has a perspective that needs to be heard. As we learn to trust each persons input the team because a haven for creating a plan that is workable and can be believed in. The team members have sense of safety in that they know a plan is doable. - Retrospective meeting
This meeting is so critical. This is when we can celebrate our successes and correct our short falls. No one really likes to face up to their mistakes on a regular basis. This meeting allows the team to look at ways that they can improve. As we identify more with the team we become comfortable in making the personal improvements in order to help the team. We have the support and encouragement of other team members to help us grow professionally.
Safety of the Team (part 1)
Posted by: | CommentsThis issue of safety is being explorer by the Agile coaching group I participate in. How do we provide a safe environment for our teams? Here are some ideas on what it means to have a safe working environment.
- A team member as an individual
Team members are not just resources to be used to create a product for the company. Each of them has goals and passions. Helping the individual to realize his or her goals and taping into their passion make for a much more resilient individual. When the team member is doing something they really want to do and are passionate about they will overcome the obstacle they encounter. - The team encourages each other
Every team member has insecurities and areas they feel they are insufficient in. When these are manifested in a team the other members find way to encourage the other member through mentoring or helping them through difficult tasks. The goal is to have well rounded team members who excel at what they do. - The team is protected from outside intruders
There are intrusions on the team from management, product sponsors, other teams and other projects. Management has expectations and many time the teams method of meeting those expectations does not match the way management expects a project to be done. In this scenario it is important to over communicate with management. Have them understand that the team is progressing toward the goals management has set. This is difficult for a ScrumMaster steeped in Agile technology. We many times have to provide more documentation then we feel is necessary.
People, Passion, Productivity
Posted by: | CommentsThis alliteration sums up what we want to see on our teams.
People
It starts with the person. It does us good to contemplate how important each individual is on a team. You do not have a team without people, how trite but all so true. When you start treating the members of a team as resources in a company you have removed their humanity. A team members first of all wants to be respected for who they are. They are a complete person with dreams, goals, likes, dislikes, families, and a job. We a leaders must value each individual for who they are. Rarely does an team member purposefully not be productive. If we do have a situation like that we need to understand where that individual is in their personal life and where they need help. I cannot emphasize enough the value of the individual first.
Passion
When you are passionate about a task nothing will stop you. It is amazing how many obstacles are overcome when we have a goal that we are going to meet no matter what happens. We have all had experience where we worked on a project that we really enjoyed. It was hard to keep our minds off the project. Passion comes from really believing in yourself and the vision of the project you are working on.
In a class Mike Cohn commented on he did not want his team members working on open source projects. He wanted them so passionate about their work that they had no desire to work on any software outside of their job.
I know many of us downplay emotion on the job. But what would happen to our work place if everyone was passionate about their job?
Productivity
Getting the job done and doing it well what we all want. As we build up the individual and guide that team we will see amazing productivity. I am always perplexed when managers interfere with the composition of a team and do not expect any changes in productivity.
When you have a closely knit team, any change in the makeup will have a very negative affect on productivity. The worse case scenario is when a team member is removed from the team without any team input. This is like losing a family member. It will take the team time to adjust.
In the flow
Posted by: | CommentsI was reading an article by Michael Swaine on multitasking. What really caught my attention was this quote:
Free your mind to focus on a single activity and you can achieve flow.
Flow, being in the zone, whatever you call it, should be your mind’s goal. When you’re in that state, you’re totally focused and performing at your peak. Like Pete Townshend’s Pinball Wizard you “ain’t got no distractions, can’t hear those buzzers and bells.” You become one with the game.
So it’s not just daydreaming and limerick writing. It’s gaming. And that means it’s coding, too, because coding, when you’re in the zone, can absolutely be like playing a video game.
Many of us as developers have experienced times when we were in the flow. We were so concentrated on the task that we our productivity was amazing.
What would happen if the team was in the flow? I have seen this happen in the past and it has been amazing to watch. It like watch a professional basketball team in the NBA finals. Each player knows their role and for 60 minutes they are absolutely in tune with each other.
Now I realize that it is impossible to be in the flow all of the time but we should try to limit distractions as much as possible. This flow gets interrupted by the random meetings on our schedule that seem to be a must. Team members have remarked that just when they really get into the flow they have to go to a meeting. It would be nice to time box these meetings so that they occur during set times during the day.
We as a team have decided that we are going create a timebox to get into the flow. We are going to reserve the mornings in our next sprint for development tasks as a team and limit other meeting to the afternoon.
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.