Archive for team
When it all comes together
Posted by: | CommentsWe all know the different phases of team development: forming, storming, norming and performing. In this last sprint I saw the team go from norming to performing.
In my 6 years of Agile practice this last sprint was as close as I seen a team do all of the best practices of a Scrum team.
It started with an excellent planning session at the beginning of the sprint. We actually took 3 hours to do our sprint planning. The product owner did an excellent job of clarifying the requirements and the team came up with a very comprehensive set of tasks for the sprint. Our testing engineers participated and helped us understand the issues we would face in testing our code.
The sprint started on a Wednesday and by the next Monday we were completing the first of the user stories and QA was doing their final testing. The user experience designer (UED) was constantly updating the high fidelity wireframes to reflect the necessary changes in the user interface. We had a hour of the product owner’s time each day to clarify ambiguities in the requirements. Through the rest of the sprint we were finishing new user stories and they were accepted by QA, UED and the product owner.
Our velocity actually increased during this sprint. We brought forward two user stories from the next iteration into the current iteration.
Team members stated that the last days of the sprint did not seem like a mad rush to finish the user stories. We only had two user stories out of 16 that needed to be finalized and tested in the last two days of the sprint.
The sprint demo was flawless. It was the climax the hard work and excellent team work of a performing team.
Quality and the process
Posted by: | CommentsQuality of software or any product that we sell and provide a customer seems to be talked about but not effectively addressed in most software processes. In the process of reducing the size of my technical library I have been looking at some of my “old” books. It is interesting to see how many of these books are referenced in new books that are published.
The book “Improving Software Quality: An Insider’s Guide to TQM” by Lowell Arthur (1993) is one I was just perusing. In the preface he has a section on eliminating the testing group. Wow, this is a book on Total Quality Management and they made a bold statement such as this. Tell me how many companies have eliminated their testing groups to improve quality?
Here are some other quotes from the preface:
Create a constancy of purpose toward quality and continuous improvement
This is a underlying principle in Agile development. The whole team is involved in process improvement through constant inspection.
Institute leadership instead of management by numbers
That is the goal of self-organizing teams. Leadership is distributed among the team members in that they agree to common goals for quality and hold each other accountable. Just having a list of defects and managing this list is not a sign of a quality organization.
Drive out fear so that everyone may work effectively.
Time and time again I hear the complaint that a person is evaluated by the number of defects that are found in their code. This creates an environment where people want to cover up any problems they discover. I just recently had to defend the number of defects that were recorded against our team during a clean up sprint (these were actually new requirements). I want any defect to be recorded so we do not have them reach the customer. Removing the fear of recording defects goes a long way to creating an quality product.
Break down barriers between departments and work groups
Simply stated, have cross function teams. If everyone is on the same team you have no barriers.
Eliminate slogans, work quotas and management by numbers. Substitute leadership.
What would our managers do? I guess I am being a little sarcastic. But so many activities our managers do do not enhance quality.
Remove barriers that rob workers (management, professional and craft) of pride of workmanship.
Nothing encourages a team more then a job well done that exceeds customer expectations. We want to be proud of our work.
Nothing new is under sun as wise King Solomon said. Agile development provided solutions that provide for a quality product.
Rhythm and development (Part 2)
Posted by: | CommentsI last addressed how important rhythm is to software development. But what disrupts rhythm for a team?
- Crises scheduling
A crises arises and management decides that we have to address the crises. The team has planned iterations to meet a release schedule but now this schedule is preempted. This is like asking a painter to paint a different section of a house. He has to climb down the ladder, move the ladder and climb back up. The team will have to “climb down” current project and “climb up” the new project. - Team member shuffle
Performing teams have worked out their rhythm. They know want needs to be done during an iteration. They have built trust among themselves. When a new member is added or a member removed the team rhythm is destroyed. You have to recreate the trust that helped the team perform so well. - Requirements churn in a iteration
This happens when a product owner changes the requirements for a user story during an iteration. Work already completed has to be redone. Productivity is decreased because the goals of the sprint has changed.
These are some rhythm disruptions I have observed.
Rhythm and development (Part 1)
Posted by: | CommentsWe see rhythm all around us. Day and night, awake and asleep, 7 day week, the years, the seasons, and music. Rhythm is very much a part of our lives. When the rhythm of our lives is disrupted we may become anxious or our productivity decreases. I know from personal experience if I do not get my Sunday afternoon nap my workweek is affect adversely.
Rhythm is important to any development process… Rhythm can battle complexity, keep competition off-balance, maintain sanity and predictability for architecture and development teams.
Software Architecture Organizational Principles and Patterns, Dikel, Kane and Wilson Page 73
This is one of the underlying principles of Agile that we are aware of but have a tendency to assume. As you will notice from the above quote this is a principle that is recognized as a good practice for architecture.
What are the benefits of a team getting into a rhythm?
- Predictability
Our customers and stake holders know they will see working software on a set schedule. When the stake holders see the team meeting their commitments with scheduled demonstrations a sense of order comes over the project. - Managing requirements
We can manage many requirement “crises” by instructing the stake holder we will consider the new requirements in the next iteration where the product owner can prioritize the requirement. All new requirements are reviewed so no one feels they are being ignored. - Periodic inspection
Continuous inspection is the mainstay of Agile development. Knowing that we have our customers reviewing our work will make us comfortable in that we are creating software the meets the needs of the customer. - Demonstrations of working products
We have working products that are tested and ready of the customer to use at the end of every iteration. This help guarantee quality. We are “putting the stake in the ground” which helps us to make critical design choices expediently. We cannot get into analysis paralysis if we know we have to deliver working products.
I am sure there are many more benefits of being in a rhythm. But as noted above rhythm is very important in Agile development.
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.