By Chad Greenslade
I have often been asked about my lessons learned in delivering Agile transformations. Below is the ninth in a fifteen part series examining my lessons learned while instituting Agile concepts & practices. I hope that these lessons help you on your journey to Agile nirvana.
Lesson 9: Socialize Generic Agile Concepts & Practices Prior to Full Rollout
The term “socialization” refers to the process of internalizing the norms and ideologies of a social group. This internalization, or learning process, is done by every member of the group, typically over a short period of time. Socializing a concept requires memorization, practice, and discussion of the required actions that must be taken. In a business setting, it is not uncommon for a team to require two (2) or more weeks to adequately socialize and accept a new work practice. Every group and team situation will be slightly different. Therefore, the time period required for a team to socialize concepts will differ. As team size and process complexity grows, so does the time required to socialize the concepts.
There are two (2) practices that you must introduce and socialize amongst personnel involved in the organization’s agile transformation. These are daily planning and retrospectives. These practices are widely regarded to be low impact, highly effective, and the starting point of a company’s iterative transformation. At this point, you will have identified the agile sponsor or champion, executives, stakeholders, supporters, and the agile team. All of these personnel must socialize the practices. The agile team will carry out the practices, but everyone must be on-board with the concepts. After the agile team is identified but before the agile pilot project is underway, agile team members should attempt to implement these practices in their day-to-day activities. These practices immediately illustrate agile’s core tenets of transparency of work, open and honest communication, and a willingness to improve over time. By embracing these practices, the organization can gently adapt to the organizational change required. The successes and efficiencies gained by implementing these practices will build the momentum you will need for organizational commitment.
Agile’s daily planning practice is known as the “standup meeting”. The standup meeting gets its name because no one should be sitting during the meeting. A standup meeting is no longer than fifteen (15) minutes. The standup meeting should be held at the beginning of the work day, and the team should decide on the date, time, and location. Every team member must attend and every team member must speak. In a roundtable format, each team member must answer three questions: (1) what did they do yesterday, (2) what do they plan to do today, and (3) what is preventing them from making progress. The Scrum Master must ensure that everyone gets to speak and answer the three questions without interruption. If there is time left over after everyone speaks, the team is free to openly discuss any topic. The Scrum Master must schedule the meeting and publish minutes afterwards. A common anti-pattern of a standup meeting is not everyone getting to speak. If you find that this is occurring, topics raised by speakers running over their allotted time must schedule separate meetings to further discuss the topics raised. The Scrum Master can act as a facilitator to schedule meetings or activities to impediments to progress.
Agile’s retrospective practice is a thirty-to sixty minute meeting held at the end of every development cycle. A typical agile development cycle is between two (2) and four (4) weeks. The purpose of the retrospective is for the team to review the work they just completed and identify opportunities for improvement in processes, designs, or any other work practice deemed by the team to be inefficient. The meeting agenda for the retrospective is as follows:
(1) What did the team do well? It is critical to recognize and celebrate successes. It builds the team’s confidence and validates the team’s value contribution to the organization. It is important to spend an adequate amount of time celebrating successes. Sometimes the team must look hard to find them, but going through the exercise validates the team’s learning and informs their improvement decisions.
(2) What did the team do not so well? Before team members will share failures, they must be assured that they are in a safe environment. It is imperative that every team member believes that they are all in it together. Over time, the team will get better at identifying opportunities for improvement. Don’t expect miracles overnight. Iterative evolution is the goal. Any team, especially at the beginning, will go through stages of development, and it is important to consider the developmental stage when asking team members to admit possible mistakes.
(3) What does the team want to improve? The team makes a commitment to improve items in the next development cycle. The chosen improvement items must be realistically achievable. This is not the time for lofty or overly ambitious goals. Incremental improvement over time is the goal. Have the team brainstorm and create a list of potential improvements, and then have them select an item, or items, from the list that they can realistically accomplish within the time constraint of the next development cycle. Open communication and team commitment is the goal. The Scrum Master should maintain the master list and track progress made on the improvement opportunities. The list should be revisited at each retrospective meeting.
