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.

Let’s Take It To The Parking Lot

Last week, I was facilitated a retrospective where we focused on meeting satisfaction. While talking about the daily scrum and what could be improved, an engineer brought up the team’s use of the “parking lot”.

If you’re not familiar with the “parking lot”, it’s used when a discussion is going a bit too deep, taking the team off track and not applying to everyone. Saying “put it in the parking lot” means that those concerned can have a separate discussion after the meeting. Similar to the classic business cliche of taking it “offline”.

Back to the retrospective… the individual rightly mentioned that when the daily scrum ends and transitions to the parking lot, the team typically remains in place, listening to the parking lot discussions. So, the parking lot essentially becomes an extension of the daily scrum. In addition to that, the engineer’s desk is adjacent to where the team stands, so he has to wait until everyone leaves so he can take his seat.

We briefly discussed what we could do to combat this pesky parking lot issue. I had the idea to create an actual parking lot that was off to the side – about six feet away from where the team stands up – in the hope that this would clear up the congestion. I used blue painters tape to create a small 6’ x 3’ area where individuals can now literally “take it to the parking lot.”

The first day after construction of the parking lot was complete, it was being used for discussion and the engineer sat comfortably in his seat.

Experimenting with Daily Retrospectives

 

I really enjoy experimentation at work, and I get a lot of value out of it. I think it’s a great way to unleash creativity, try out new ideas, continuously improve, have fun, and see what works and what doesn’t work.

One team that I coach had been playing around for weeks with the idea of doing a daily retrospective. The team is small—only two or three developers—and works in one-week sprints, so things move quickly. It’s also a research and development team, so being creative and thinking outside the box is important—these values are even stated in our team working agreements.

In an attempt to mix things up a bit, we decided to try daily retrospectives. Here’s how the experiment went.

Iteration 1: For one week, at four p.m. each day, we huddled in our team pod and discussed for about five minutes what went well and what could be improved from that day. This was beneficial because the day was still fresh in our minds. Sometimes it can be hard to remember what happened four, five, or ten days ago, so having a quick touchpoint each day is helpful.

After our discussion, if there was anything relevant to focus on for the next day, we would capture an action item or two. We would write the actions on sticky notes and put them on the team’s physical whiteboard in order to make them visible and make sure the team remembered to work on implementing them.

Iteration 2: After the first iteration completed, we decided that discussing our thoughts out loud put people on the spot and was not a great option for quiet team members. So this week—again at four p.m. each day—we huddled in our team pod, but this time we had each person write one idea per sticky note about what went well and what could be improved, and then they dropped their notes into a box. After each person had placed their sticky notes into the box, the retro was over (again, about five minutes).

For the most part, there were no discussions, other than someone asking, “What did we do today …?” Questions like that led to some chuckling, but then team members recapped what they had done, and it helped the team remember the day and come up with improvements. At the end of the week, we gathered in a conference room to open the box, and there was a lot of excitement and anticipation, kind of like opening a gift. No one was quite sure what to expect, but everyone was eager to find out.

We grouped the sticky notes on the wall to identify themes and patterns, then discussed them and captured some action items. This retro was fun and full of energy, and the team really liked it.

Iteration 3: This iteration was very similar to the second iteration, except I had upgraded from a cardboard box to a glass jar (per a team member request), and the team used different colored sticky notes for each day of the week (pink for Monday, orange for Tuesday, blue for Wednesday, etc.). When Friday rolled around, we met in a conference room to discuss the thoughts from the last five days.

However, this time when we opened the jar, we created a timeline and grouped the sticky notes based on day. We put the “plus” sticky notes (what went well) above the line and the “delta” sticky notes (what could be improved) below the line, and we grouped similar sticky notes together but all still broken out by day. At this point, we walked the timeline, discussing and capturing action items. The team liked this third iteration even more than the second.

Iteration 4: The team liked the third iteration so much that the fourth iteration was just about the same. The only difference was that one developer ranked each day on a scale of one to five stars, with five being the best, by drawing the number of stars on the sticky note from the corresponding day. It was interesting to see how his star rankings correlated with the amount of overall team pluses and deltas for each day.

In addition, because this particular developer is quiet, I asked him to walk the timeline and facilitate the retrospective. One of his goals is to improve his communication skills, so this gave him an opportunity to work on that. He did a great job, and it was nice to see him step out of his comfort zone.

Overall, it was very rewarding to see an idea quickly go through multiple iterations based on immediate user feedback. When we started our daily retrospective experiment, we really had no idea what was going to happen, and that was fine. What we ended up with by the last iteration was a retrospective format that easily captured thoughts in the moment and led to rich discussions and solid action items. It also enabled team members to grow their skills and demonstrated the value in starting small and iterating. Finally, it generated excitement and engagement, even leading to more experimentation and other benefits for the team.

For now, the team is happy with where they landed and they want to continue our daily retrospective style, but I’m sure that before too long, we’ll be trying something new again.

What experiments have you tried lately? What experiments would you like to try out?

This article was published at AgileConnection.com on 1/24/2018.

Continuous Improvement Board

Earlier this year – after a large, stressful release – a group of Agile Coaches facilitated a retrospective involving people from over a dozen dev teams. In order to address the retro takeaways and make the progress visible, a Continuous Improvement Board was created.

The goal of the Continuous Improvement Board was to provide a forum for people to promote and champion ideas to bring positive change to the organization. We wanted to empower people who had identified areas of improvement so they could make their ideas visible and find others who were interested in solving a problem or moving an idea forward.

The Continuous Improvement Board is in a centrally located area that receives a lot of foot traffic. Initially, people just jotted down ideas and added them to the board. After some time, we adjusted the process so that people needed to write user stories for the ideas. We thought this would encourage people to give their ideas more thought and not just throw any random idea on the board in hopes that someone else would do the work for them.

Some Continuous Improvement Board examples:

  • The creation of an Engineering Handbook to document coding standards and how to be a responsible engineer, which can be used during new hire orientation
  • The creation and implementation of team health surveys to get a pulse on how the team thinks they’re doing based on various categories (which also shows interesting trends across the organization)
  • The creation of Empowerment Surveys for various groups (PO, Engineering Managers, etc) to identify what can be improved
  • Seemingly minor things such as people would like to have beef jerky added to the snack supply

Overall, the Continuous Improvement Board has been an interesting experiment that has provided opportunities for collaboration, creative thinking and learning.

How do you and your organization focus on continuous improvement?

New Agile Acronym – EFCIC

Recently, I was preparing for a couple of speaking engagements and was thinking about how to summarize what Agile means to me.

What I came up with was Empowerment, Flexibility, Communication and Collaboration, Iterating on Feedback and Continuous Improvement.

Written out as an acronym, this spells EFCIC, which kind of sounds like efficacy, which means “the power to produce a desired result; effectiveness”.

Well, that sounds like a pretty good goal and something that Agile can help with, so here is my new Agile acronym…

E mpowerment

For Agile to work well, teams and individuals must be empowered. Empowered to make decisions, empowered to estimate effort and complexity, empowered to fail and learn from mistakes, empowered to ask questions, empowered to be creative, empowered to develop their skills, etc. If teams are empowered, they are more likely to be able to face challenges that come their way.

F lexibility

Let’s face it, plans rarely go as expected, especially in software development. The ability and need to be flexible is essential. Having the mindset that things are going to change can help be prepared when the time comes… and it will. If teams are flexible, they will be able to quickly pivot and head in a different direction when necessary.

C ommunication and Collaboration

To me, communication and collaboration have a strong correlation and both are really important. Teams need to have strong internal communication so they can become high performing and external communication so they can work with other teams and identify dependencies. Collaboration – whether it’s pair programming or working with the PO to define a feature – will help teams get the most out of each other and also increase team cohesiveness. If teams communicate and collaborate, they are more likely to be on the same page, come up with better solutions and continue to improve.

I terating on Feedback

Don’t fool yourself and think that you’re going to build a product right the first time. Instead, build something small, get feedback, iterate on it, get more feedback, iterate, feedback, iterate, feedback, etc. If teams iterate on feedback, they are less likely to waste time and more likely to build the right product.

C ontinuous Improvement

Even if your team seems like they are firing on all cylinders, chances are that there are some improvements that could be made. Focusing on continuous improvement is important so teams don’t get too comfortable. Experimentation is one of the keys here because it helps people think outside the box and leads to new discoveries. Even if the experiments don’t work, at least you know what doesn’t work. If teams focus on continuous improvement, they will challenge themselves and the status quo, benefiting not only the team, but the organization as well.

Does EFCIC represent the way that you view Agile? I would love to hear your thoughts.

5 Things Learned From Steve Jobs

Last week, I (virtually) attended the Lean Startup Conference and heard Guy Kawasaki – former Chief Evangelist at Apple – speak about 10 things he learned from Steve Jobs. Below are the 5 that caught my interest, along with some of my thoughts…

1. Customers can’t tell you what they need (you need to help them figure it out)

I think it is important to keep in mind that building the right feature takes collaboration and communication. This is similar to how a Product Owner presents a user story to the dev team and then there is a discussion to clarify points, add acceptance criteria or discuss why another approach could be a better idea.

2. Changing your mind is a sign of intelligence

This is very much in line with Agile thinking, which is why we work iteratively and incrementally and why continuous improvement through inspecting and adapting is so important.

3. Engineers are artists – treat them like artists

Just like an artist, engineers need space to be creative and innovative (no micro-managing). They also need time to work on their craft, for example, time to refactor so they are not introducing technical debt.

4. Innovators ignore naysayers

There are many reasons why people will say something can not be done. Perhaps they don’t understand the vision, maybe a particular idea threatens them or they don’t like thinking outside the box.

5. Some things need to be believed to be seen

Guy explained this as the idea of sometimes people won’t take the time to see something until they’ve been convinced of the idea. So, really understanding the benefits of a feature, being persuasive and convincing people of the idea many times is the first step.

Please let me know what you think.

Agile Experimentation

I am a big proponent of experimentation and find it particularly useful within the Agile space. When teams are working in short time boxes, a quick experiment could add a lot of value. On the downside, if it doesn’t add value, the team can choose to end the experiment and hopefully they have learned something. With an eye toward continuous improvement, perhaps the team wants to try another.

Below are a couple of experiments that teams I’ve been coaching have tried.

Experiment #1

During a retrospective, I brought up the topic of communication. How was communication within the team? Did they think it was strong? Were they all on the same page and did they know what each other was doing? Most people said it was very strong. One person said that they knew what everyone was doing and another said they would like to know what everyone was doing but they weren’t quite there yet.

I took this opportunity to suggest a communication experiment. How would the team like to give their daily scrum update for another person on the team? For various reasons, everyone thought it would be a fun experiment, so we decided to try it for a week.

The exercise started out pretty well, actually. Around day #2, things started to become a bit more challenging and by the end of the week, the team was ready to end the experiment. The team realized that although they had good communication, there was still room for improvement.

Experiment #2

Another team had recently been broken up and was reforming. They were clearly in the “storming” phase and were having problems with their throughput. In a retrospective, we focused solely on what could be done to increase throughput and start seeing work flow across the board. A member of the team had the idea to start using a daily team goal.

The plan would be that during the daily scrum, the team would identify the top priority for the day, how much of that the team could finish and who would help get it done. The plan is similar to the typical daily scrum, but much more focused on the team rather than the individuals.

The daily team goal helped the team focus, increased their collaboration and led to a lot of swarming. The experiment received positive reviews in and out of the team and is still being used today.

I viewed both of these experiments as positive. Even though they had differing levels of success, it felt good to try something new and I believe that the teams learned something from both.

What kind of experiments have you tried?

Teamification: Agile Team Self-Selection

Earlier this year, while consulting as an Agile Coach, I was involved with an interesting experiment. The experiment asked individuals to self-select into software development teams. Team members would be allowed to choose what products they worked on and who they worked with. The event was called Teamification Day.

I had never done anything like this, so I was excited and also interested to see the process and results. A lot of effort went into preparing for the event. The Agile Practices group – which I was part of – took the lead by designing the event and communicating information.

Setup

Each work package (epic or larger) had an assigned Product Owner and dev lead. The PO and dev lead worked together to design a presentation that explained their work package. This would be used on Teamification Day to educate and recruit people to their team.

Each pair also had a board that would later be used to indicate interest in a specific work package and would eventually indicate the final roster for that team. This board contained valuable information, such as:

  • Standard constraints: The required makeup of teams (ex. 3-5 devs, 1 PO, 1 Agile Coach)
  • Team is able to deliver end-to-end solution
  • Where the team would be co-located (Chicago, for example)
  • Team information: Name, value stream and work package
  • Skills desired: Ex. One FE dev, two BE devs, UI/UX and also specific knowledge if necessary (Elastic Search, Java, Kafka, Nifi, Selenium, etc)
  • Team adjustments: After each round, teams would use this space to identify what they still needed or what they have too much of

The Agile Practices group created the boards and then had a couple of dry runs to see how it felt and what issues we thought needed to be addressed. There were a handful of issues and ideas – ranging from ‘will the areas be too chaotic with so many people and so many questions?’ to ‘do we need flags to indicate the team’s location, whether the team is fully formed or not fully formed?’. The goal of this event was to allow roughly 200 people to learn about 25 different teams, ask questions and then choose their own team – so we knew there were going to be obstacles.

Curiosity Market

On the morning of Teamification Day, there was breakfast – along with excitement and anticipation – in the ballroom. After some short messages from various leaders, the Curiosity Market was opened. The Product Owners and dev leads stood by their booths and pitched their work packages – explaining what they would be working on, why people should be interested and exactly what kind of team they were looking to form. The room sort of resembled a science fair.

Since there were so many teams, several rounds were run and the time slots were staggered – with some presenting and others taking a break – to give everyone an opportunity to get the information they desired. As is typical with many Agile events, the law of two feet was encouraged to allow people to move around and do what made the most sense to them.

Team self-selection

Following the Curiosity Market was lunch. The Agile Practices group discussed how the morning played out and went over last minute coordination details for the afternoon. We discussed that despite (what we perceived as) a successful morning, the afternoon would be more complex. Anything could happen as people started choosing teams. However, we had discussed possible scenarios and were armed with techniques to facilitate various situations.

As the self-selecting portion kicked off, some teams were formed quickly, as there were some individuals and groups who had previously discussed where they would like to be. The rule was that anyone could put their name on any team board – even if that team ended up having 15 people who wanted to be on it. After a couple of rounds, most of the teams were squared away, but there were some teams who had too much of one skill and not enough in other areas. The event facilitator asked teams to call out what they needed – for example, ‘we need two front end devs’ or ‘we are short one tester’. At that point, teams would know where the gaps existed and could go discuss and recruit people to help complete the team.

After a little more discussion and pitching from Product Owners, all the teams were formed.

Post team self-selection

Months after the teams self-selected, things seemed to be going very well. Individuals seemed happy with how things turned out and in a recent survey, the self-selection process was called out by many as a positive. There were only a handful of people who did not get one of their top choices and providing the freedom to choose your own destiny was appreciated. Of course, not everything is or was perfect – there were a couple of people who have been traded to help better align teams and when teams moved on to different work packages, the work was not the same, which was a little disappointing for some.

Another interesting idea that has been rolled out are job boards. A job board is a place where teams can advertise that they are looking for a skill and others can view the board to see what team they would like to join. There are certain constraints – for example, people need to be on a team for 3 months before moving – but people will also be allowed to switch teams if they’d like.

Summary

Overall, I am grateful to have been a part of this self-selection Teamfication experiment. By most measures that I see and hear, it was a success. It provided the freedom and autonomy for people to choose teams for themselves, which conveyed a message of trust and accountability. Self organization was center stage in this experiment and it proved, to me, that empowering individuals can be a strong force.