We as a team will go through phases as a team, forming, storming, norming and performing. But how do you know what phase you are in? Do you go through these phases multiple times?
In my experience the forming stage is fun because the team is new. The members are creating new relationships. We are learning about each other skills. The team is usually working on a new and exciting project. This is a great time.
The storming phase may not be recognizable. In a small team you will phase through this phase with minimal disruptions and become a norming team. We are focused on a project and we want to meet the goal. So team members may not think anything about the storming phase.
But in a large company a team may not remain small or stable. You may have multiple members are added to the team and what happens? You are again in a forming phase. The storming phase is around the corner. But what I have seen happening is that the original small team will act as a team within the larger team. The original team members do not want to “include” the new members. It is very difficult to break into this inter circle. The new team may say that they are a performing team but in actuality they are a forming team that is avoiding being a performing team. You will recognize that they are not as productive.
We have a seen a team grow to 14 members in size. They think they are a good team but this is not the case. In looking at how the team is performing we see the stories are not being completed, team members are not communicating with each. We are seeing different design approaches. The team is dysfunctional but do not realize it.
So the team decided it needs to be self-organizing. So one of the top issues is to break the team up. Well this has lead us into the storming phase. We are now getting issues out and realizing there are problems. I hope that in the weeks to come that we can working through this storming phase and eventually become a performing team.
At the company employees me we have had a very pleasant surprise at our last internal meeting. The president of the company made an announcement that the whole company was moving to agile. This is going to be a move starting at the top. He said that his personal organization was moving to agile and was evening revamping the workspace to support agile.
He informed us that every aspect of our working environment from the physical workspace to having permanent co-located teams was going to be affected. This was a bold announcement because I know many in upper management did not want a agile environment.
As with many of my coworkers who have been involved with agile at the team level we have a wait and see attitude. My hope is that we are really moving to agile as a company.
We had an interesting planning meeting. This is the first time the team pointed out that they had not confidence in finish user stories because of interdependence on other teams. Half of the user stories were moved to the next sprint. The product owner is now prioritizing other user stories in case we need to pull user stories.
Also, yesterday the team started to be more self-organizing. We are beginning to learn how to make decisions as a team. It also helped that we had our planning session in a room that is more open and large enough for the team.
It has been almost a year since I have posted. Well that is now changing.
It has taken me a year to recover from some very difficult experiences implementing agile within an organization. As a passionate pursuer of excellence it is difficult when others do not share the same desires and goals. The team wanted to pursue excellence be a truly self organizing team but management did not have the same vision. There are only so many times you can run into the management brick wall and to wear yourself out.
I have had the privilege of working just as an individual contributor on new team. I am not the Srcummaster which is very unusual. But in the last year I have neglected being a coach. A team needs a coach, especially the Scrummaster. Hopefully I will be able to perform this role of coaching. Leadership lies with the Scrummaster and I must support that role as a servant leader.
I really appreciate that amount of time we spend in planning for a sprint. For a two week sprint we spend one day in planning. I know in the past that teams that I worked with thought this to be a “waste” of time. They wanted to start programming. My new team is developing a habit of doing sprint planning which will be very beneficial.
We are tasking our user stories with a high level of detail. Most tasks are not more then 4 hours in length. This is helping the team to better understand what needs to be done. During the planning session yesterday we moved some user stories to the backlog because the product owner was not clear on the requirements. In the past this would have lead to development churn or wasted time during the sprint. It is much better to discover this at the beginning of a sprint through sprint planning.
Planning for the two week sprint also helps the team to understand inter-dependencies. Having smaller sprints gives the freedom to move stories to the backlog.
We are starting all over again. This is a time of new beginnings. I have joined a new team and this time I am not the Scrummaster. This is a switch for me. I believe this will be a good role for the next 6 months. It will help me understand the technical challenges being faced by team members.
This team I am on is very new. I reminds me of 3 years ago when I first joined my current employer. Here is how they are new:
- New to the company. Most have only worked for the company 3 or less months.
- New to the process. Most have not worked with agile before.
- New to each other. Most did not know each other 3 months ago.
So this team must go through the forming, storming, norming and performing stages. It seems that every time I work with a new team that they think they are different and do not have to go through these phases. Now matter what they think they will progress through each of these stages.
Another observation is that the team is not good at planning for a two week sprint. They are overly optimistic and have committed to more work then they can get done. I know they are new and want to prove themselves but they do set themselves up for failure.
We 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.
We just finished our first sprint for a new feature. I have noticed that the initial sprint many times is very difficult because you do not have any code with which to start and the new feature is just written on paper.
A goal of Agile is that every sprint delivers working software. I know in the past that has been a real issue in the early sprints. How do you develop working software in three weeks?
The key to developing working software is to do figure out what is the scaffolding that needs to be in place to create a minimum working system. It is critical to understand what are the essential feature that are required for a working system. How much of the “happy path” can you “hard code” to create working software?
Defining what is essential is not easy. You have to take a look at your high level design and determine what is a working system that will be a true initial representation of the final product. What we build in this initial sprint will create the foundation for subsequent sprints.
I have found out that it is critical for the technical development lead to take leadership in this area. He or she, with the help of the team, can create the vision for this first sprint. Once this vision is established the team knows exactly what they are working toward. They can see how all of the pieces fit together to meet the goal of working software.
In the case of this sprint we had to create a vision that was not really a user story but was a overriding goal that we had on the white board in our team room. We could always point back to the vision for the sprint and see how we were doing. All team members agreed to the vision so this became a great unifying theme.
As the result of this vision for the sprint we came up with great sprint demo of a working feature. It provided the product owner and stake holders clear understanding of the functionality and how the feature will evolve in the future sprints.
Adopting Agile in an large organization presents many challenges. This is especially true when a project contains multiple teams that have to create an unified product. One must be able to parse a project so that individual teams can work on a sub-system and have it integrate smoothly with the product.
In the organization I work with we have added a new step in the process. I will call this our Sprint 0 iteration. This iteration is used to create the initial backlog for the release. The participants in the meeting involved the team working doing the programming, the lead architect, best practices team, product owner, service representatives, user interface designs, quality assurance and management.
The goals are as follows:
- Understand any major architectural issues
- Identify where the software has to interface with external subsystems
- Define how to communicate with external systems
- Define the overall system constraints
- Have the product owner clarify the requirements
- Define the initial user stories.
- Size the user stories
Even though I believe very much in team making its own design choices, having the experts available to assist the team is very beneficial. This allows us to better understand what we are developing. This has given us a level of confidence in our estimations for the upcoming sprints.
This does not minify the role of the product owner during a sprint. Their involvement is very critical to the team maintaining their velocity during a sprint. The product owner has to constantly reviewing the working software to make sure we are on track with the expectations.
We finished an additional development iteration. This iteration was unusual in that we were adding features to a product that was to be released September 27th but the schedule was slipped because of another project dependency. So this iteration involved last minute planning and development. This in itself caused us to take on user stories where we as a team had no background. So this moved the team to the next level of performance. Here is what we did and the outcomes.
- Responded to a high priority user story
The business had a user story they wanted done. There are five scrum teams and most did not have the bandwidth to take on the story. We as team made a commitment to the business to do this story.
- The teams quickly estimated user story sizes
We are learning how to trust our initial sizing without doing extensive designing. We had a very short time to estimate so we had to finish them quickly and abide by the estimate.
- The user story was used correctly
We had the user story narrative along with at most three lines of acceptance criteria. The user story was actually used as a talking point with the product owner. The product owner refined the requirements during the sprint by reviewing work in progress. The daily demos were an excellent catalyst in firming up the requirements.
- The product owner was available
To do this user story we got a commitment from the product owner to block out 90 minutes of their day exclusively for the team. The product owner is remote so we could not just go over to her desk. This worked well because we had her dedicated time every day.
- The team demo incomplete stories daily to product owner
Because our product owner was available for 90 minutes a day we used this time to do daily demos and to get feedback. There always was a reluctance with the developers to demonstrate incomplete user stories. The developers had to do this because the product owner did not understand what they needed in the final product. The requirements became clearer as the product owner responded to features that were partially complete.
It was really a pleasure to see the team perform so well. In the sprint we created the user stories, designed, built and tested the feature. We made our commitment to the business in finishing the feature in one sprint.
We as a team are really excited about what we can do in the future base on our performance in this sprint.