Lessons Learned from Agile Transformations: Part 10

Tenth in a Fifteen Part Series

By Chad Greenslade

I have often been asked about my lessons learned in delivering Agile transformations.  Below is the tenth 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 10: Train the Team in Agile Concepts & Practices

While you may have some team members with prior agile experience, you must regard your pilot team as being unfamiliar with agile.  You must increase the team’s agile knowledge as quickly as possible.  There is only one (1) proven method to accomplish this; you must send the entire pilot team, along with the Sponsor, to an agile “101” class, or an agile boot camp.  An introductory agile class is typically three (3) days.  Five (5) day agile “boot-camps” are also available.  Certified agile trainers will facilitate the course. I believe the most common and effective course is one that certifies attendees as scrum masters.  The scrum master course typically provides the baseline foundational agile knowledge that your team will need to be successful.

The reason this training is so important is because attendees learn about and perform the agile processes and ceremonies during the class.  Attendees learn “by-the-book” agile concepts and tenets and perform the processes and ceremonies as they were intended, and not adapted to fit any specific organization.  Your pilot team should not be taught how to adapt agile to their organization at this time.  Adaptation will come later as the team masters the techniques and makes informed decisions about which adaptations truly make sense.  Adaptation too early typically results in a team falling back into old waterfall-style habits.

Agile training attendees will learn that they must deliver software frequently, at the end of each sprint, and the processes must be carried out to realize this objective.  When training is complete, the team must assess how existing enterprise tools and processes support and / or hinder their ability to deliver software frequently.  The team must understand how they will use existing tools and processes within the new agile context.  Most tools and processes can be adapted to agile.  You will need to engage the owners of these tools and processes to educate them on the support required for your agile project to be successful.  If changes to existing tools and processes are required, be prepared to have multiple conversations with tool and process owners to get them onboard with the support required of them.           

By the time your team has completed agile training and understood how existing tools and processes will support their agile project, they will need to know where they will physically sit each day.  Conventional agile wisdom dictates that teams sit co-located and in the same room whenever possible.  Given today’s remote work IT culture, rarely have I seen this play out exactly as specified.  The COVID-19 pandemic has exerted additional pressures on agile teams by restricting their abilities to sit in an office.  I have found that collaboration tools coupled with a structured and well controlled sprint execution framework can keep all team members adequately engaged, and negates the need for team members to sit next to one another.

Lessons Learned from Agile Transformations: Part 9

Ninth in a Fifteen Part Series

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.