Applying Agile to Life: Taking Retrospectives outside the Workplace

Summary: 

A lot of what agile teams do can be used effectively outside software development teams, and even outside the typical business organization. For instance, retrospectives and the practice of talking about what went well, what you should keep doing, and what can be improved can be applied anywhere—even to families. Read on to learn how to bring continuous improvement into your daily life.

I regularly tell people that I view agility as a mindset rather than frameworks, practices, ceremonies, or roles. Consequently, I believe that a lot of what agile teams do can be used effectively outside software development, and even outside the typical business organization.

My company’s agile practices group facilitates retrospectives not just with development teams, but also with the people team, UX research, customer delivery and implementation, and recruiting, just to name a few departments.

With that in mind, I recently had an idea to try something new. Over the New Year’s Eve weekend, my wife, daughter, and I spent a few days with my parents and my brother’s family (wife, son, and daughter). On day one, I asked my family members what they thought about having a retrospective at the end of our time together. Because most of them didn’t know what a retrospective was, I briefly explained the concept, purpose, and execution. Everyone was on board with trying it out.

The idea had come to me after hosting family members at my house for a weekend earlier in the year. As someone who is always thinking about continuous improvement, I had noticed a few things that could have made the weekend better for us all. My wife and I had a quick retrospective and shared ideas about what we liked and what could have been done differently, like me helping more with the dishes. It made me realize how beneficial a retrospective could be outside my work context, which convinced me to try it out at the next opportunity.

On the last day of New Year’s Eve weekend, I gathered everyone together in the family room. The group of eight ranged in age from seven to sixty-four. I started by asking who had taken part in a retrospective before. My brother, who is a fellow agile coach, and my wife had, but it was interesting to find out that my eleven-year-old nephew had participated in one at school, too. I then explained at a high level the purpose of retrospectives—how we would collect the data, the discussions we would have to dig deeper into topics, and what we would try to achieve as an output.

Next, I created two columns on cabinet doors by placing stickies up high with the words “What went well?” on one and “What could be improved?” on the other. Earlier in the day I had populated some stickies with my thoughts about the weekend, so I put them on the cabinet as examples to ensure everyone had a shared understanding of what to do. I gave some brief context to each of my stickies, asked if anyone had questions, and then put ten minutes on the timer to allow people to capture their ideas on their stickies.

After time was up, everyone added their stickies to the cabinet doors and gave a brief explanation of their thoughts. Occasionally someone would ask for clarification. As the stickies were placed on the cabinets, we grouped similar themes so we could easily tell what were hot topics to dive into.

We had some great discussions. At times it was funny and other times it got a bit emotional. There were some valuable insights and recommendations. People volunteered to take on actions and captured them on sticky notes so they could remember to follow up.

There were some great improvements we suggested:

  • We found that some people want to get out of the house more, so a couple of us took on action items to investigate activities for next year (museums, shopping, go to a movie, etc.)
  • My nephew said he didn’t want to go to an Italian restaurant again for New Year’s Eve dinner because we’ve done that two years in a row. He also said that the long table at dinner wasn’t great for communication because it was hard for people at the ends to talk to one another. So next year we’ll be eating at a round table not in an Italian restaurant
  • Some were not interested in the same old board games, so one person took the action to review the game cabinet, and others will bring games from their houses
  • Multiple people thought it was too cold outside, so we are considering going to Mexico next year!
  • My niece even said the toilet paper feels like sandpaper and they need to have softer toilet paper. Someone else who lives in the house agreed! Despite living in the same house and using the same toilet paper, they had never discussed it

When I originally proposed the idea, I wasn’t sure what to expect; it seemed like it might be a bit silly. But everyone was engaged and had fun with the retrospective, and we came away with some great action items for improving our times together— and our next gathering will be better because of it.

This real-world example just demonstrates the universal power of retrospectives. How have you incorporated agility into your life outside the workplace?

This article was published at AgileConnection.com on 5/23/2018.

Using Sprints for Agile Coaching

I recently stepped into a new role where I am now responsible for moving high-level, organization-wide initiatives forward. At the same time, I was trying to increase engagement within the Agile Practices group of agile coaches and ScrumMasters. I wasn’t sure of the best way to get the work done, but I had an idea: Why not use the same agile process we ask our development teams to use?

We could form a team, create a backlog, estimate how much work we could get done in a sprint, do the work, show off the work, get feedback, and then talk about how we could improve. It wasn’t exactly an original idea, but I thought it could be an interesting approach.

I started by identifying the first area of focus, which turned out to be improving the ScrumMaster hiring process. After learning more about the current process and discussing with others, it seemed like clarity could be added around expectations while making the new process more experiential and focusing on involving the right people.

I was looking to form a team to make this process better, and fortunately, four agile coaches with very different styles said they would be interested in helping. Three of them confirmed that they would be able to put in some effort over the next two weeks, although we ended up changing the sprint length to one week.

Regarding the sprint length, we discussed and decided that because this was a side project, a shorter sprint length would help us focus and not procrastinate. For all of us, this was not our primary responsibility, but we agreed that we could spend time working on it. “After all,” someone said, “hiring is the most important decision we can make.”

Acting as the product owner, I wrote user stories about getting a shared understanding between product and engineering expectations, minimum requirements for potential candidates, various hands-on exercises, and several others. After adding acceptance criteria, I shared the stories with the agile coaches team for review before our first sprint planning meeting.

In sprint planning, we reviewed the stories, discussed them, edited and added to them, reprioritized, and wrote new stories. The feedback from the other coaches was extremely helpful, and the stories and backlog were in better shape because of it. Collaborating to get a shared understanding of the work was beneficial, and the conversations we had gave us a whole new perspective on what we were trying to achieve. Each person brought a unique view for what they thought was important and what could be done to get the most value out of the interview process.

Next, we estimated how many stories we thought we could complete, then discussed how we would get the work done. Even though we weren’t coding anything or dealing with legacy systems, we knew that unforeseen obstacles would come up, so we took that into account. Considering there were four team members and the work was relatively new to all of us, we decided to pair on our stories throughout the week.

During the week, each pair found a couple of times to collaborate and work through their stories. It was fun and energizing to bounce ideas off each other and consider new ways to approach problems, while knowing that we were creating a structure that would benefit all of us in the long run. Having great coworkers would benefit our Agile Practices group, our teams, and the organization, so keeping that in mind was motivation to focus on being creative but also pragmatic.

Near the end of the week we got back together and showed each other what we had accomplished. There was some feedback and discussion, and everyone was happy with the progress that was made. We updated the backlog to reflect the feedback and found that some of the stories were no longer relevant, so we removed them. Shortly after, we reconvened to have a quick retrospective, where we discussed some insights into how we could improve the process. We noted a couple of action items and even changed a story in the backlog based on the retrospective discussion.

We still had some work to do, so the following week we met to refine the stories. We continued the process until we were happy with the new ScrumMaster hiring process.

Overall, the agile coaches group thought it was a nice way to organize the work that was being done, keep people focused, and deliver value. It also gave us an appreciation for the way we encourage our teams to work. Discussing the work to be done as a group, building in short iterations, getting feedback, and looking for ways to improve are not just practices for development teams—it is an effective way to achieve any goal.

We followed through with improving the process, and eventually we hired a talented ScrumMaster. That person has done a great job of supporting their teams and contributing to the larger Agile Practices group. We even had a retrospective about the new process that they experienced and discovered even more ways to improve.

The learning never ends, so of course, we continue to iterate.

This article was published at AgileConnection.com on 11/8/2017.

Code Health Kaizen

For the last year, teams within an organization I have been working with have been taking team health surveys on a monthly basis. The survey invites teams to evaluate themselves on categories such as backlog health, continuous improvement, collaboration, and the release process.

Typically, the survey data is used in team retrospectives to focus on what is going well and what can be improved, as well as to view trends. A number of people have asked how we could use the data to tackle organization-wide issues that affect all teams. After some thought, I decided to engage a group of interested individuals to discuss how we could focus on one issue and improve.

The issue of code health was chosen for a few reasons:

  • It consistently ranked in the bottom five categories in team surveys
  • Code health is something that engineers have control over and can improve
  • Leadership does not need to be involved in improvements, making them easier to adopt

We decided to schedule time for an open discussion and invited anyone who wanted to attend. I planned for the event by having a loose structure and some ideas but made sure to leave space for the participants to help set the agenda.

Brainstorming and Planning Actions

We held a one-hour discussion over lunch in order to minimize conflicts. About fifty people attended, which made the meeting standing room only.

I facilitated the discussion, and we started by talking about what everyone in the room wanted to get out of the session. After discussing goals, we documented them on a whiteboard wall.

Next, the group developed an agenda, which was also written on the wall. I wanted to be able to come back to the agenda generated by the group to show that this meeting was for them.

After creating the agenda, wehad a brief discussion about what it means to have good code health. The group had strong opinions—some ideas piggybacked on others, and some led to disagreements, but one thing was sure: we could have had a great discussion for hours. 

Next, we used the Circles and Soup innovation game for retrospective analysis to identify what issues were in our control, what we could influence, and what we had to live with. People wrote ideas on sticky notes and grouped them, and then we talked about some of the higher-level themes.

Some of the back-and-forth discussion that followed led to ideas for actions, and a few people felt passionate and motivated enough to volunteer to own those actions. Others pointed out that code health should start at the team level, not with organizational initiatives, which was a fair point.

Near the end of the session, I asked the group what comes next. As in any retrospective, you don’t want a complaining session—you want to identify measurable actions to be worked on in an effort to make improvements. One engineer spoke up and said that we should get together again in a month to check in on our progress. I offered to own that action.

Before closing the session, I went back to the list of goals the group had come up with to see if we’d addressed everything. We didn’t get to all the items, but we did get through five of six.

Overall, the discussion went well, and it felt great to have several actions and specific owners for them. It was also nice knowing that people wanted to get back together and follow up. Despite differing viewpoints, this topic had sparked a great deal of interest.

Turning Ideas into Outcomes

There was a buzz about code health after the session, and it didn’t take long for people to start taking action. One group led a charge to roll out a new testing framework to all teams. An engineer started working to standardize the README files in all repositories. Another engineer contacted me about starting a book club for continuing education. Another group formed, calling themselves Engineering Education, with the goal of spreading engineering knowledge throughout the company and offering a forum for learning. There was an organic, bottom-up movement unfolding, and it was great to see.

During the original code health discussion, there was skepticism about how much leadership actually bought into the importance of code health. I knew from discussions with leadership that it was very important. I also knew from previous initiatives that bottom-up efforts can be strengthened by top-down support, so I worked with leadership to craft a message that demonstrated their support for healthy code.

After a couple of weeks, it was clear that the Engineering Education group was gaining steam. They had a Slack channel and weekly meetings. They organized tech talks with strong attendance and powerful discussions. They created a team spotlight, where a member of the Engineering Education group would interview a product development team and the information was sent out in an email. The content included a picture of the team, team member names, what they worked on, applications supported, languages and frameworks used, some challenges they faced, approaches to improving code quality, and what they could help other teams with.

When I attended an Engineering Education meeting,I was happy to see considerable attendance. The group had a backlog of items they went through, providing updates. Discussions followed about what could be done to move items forward and about new ideas.

After the month had passed, we had the follow-up session to discuss the progress of code health initiatives. It was decided that the Engineering Education group would lead the way. All the other initiatives had grouped under that umbrella, and it was a natural way for everyone to keep a pulse on what was happening and how to get involved.

Maintaining Momentum

The next steps for the group include promoting themselves (via word of mouth, internal newsletters, digital signage, and posters), getting involved with new hire orientation, and possibly creating courses for the company’s continuing education program.

I really enjoyed watching the different groups and initiatives form and then ultimately come together in solidarity. To me, it demonstrated what can happen when people are passionate and have the autonomy to be self-directed. The team health survey simply provided data and insights. But those insights led to a conversation that motivated and empowered people to share, learn, and improve themselves, their teams, and the organization.

This article was published at AgileConnection.com on 8/9/2017.