Experience Report

Yes, You CAN Let Your Teams Self-Organize!

About this Publication

‘Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.’ This principle from the Agile Manifesto – that teams are ‘self-organizing’ – may sound simple; however, supporting self-organizing teams can be one of the more significant cultural changes that a company in transformation faces. People are working on projects they want to be a part of which is a huge win!

1.     INTRODUCTION

Rob Reed and Faye Thompson are scrum masters and agile coaches at American Electric Power (AEP), one of the largest electric utilities in the U.S., serving nearly 5.4 million customers in 11 states. AEP is currently in its fourth year of an agile transformation. This experience report tells the story of Rob, Faye and their department within AEP going through its agile transformation, highlighting the management support of enabling teams to self-organize based on incoming project work. AEP is nine years into their agile journey.

The teams we are a part of have explored dynamic reteaming, self-selection, interviewing and hiring new team members, pairing and co-training in order to build the strongest teams possible for the work at hand. All of this was done with the support of our management, and through incremental change. While our path wasn’t always easy, we did learn a lot along the way. We want to share our story so that you might start to envision a future reality in which your teams can be trusted with organizing themselves.

‘Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.’

This principle from the Agile Manifesto – that teams are ‘self-organizing’ – may sound simple; however, supporting self-organizing teams can be one of the more significant cultural changes that a company in transformation faces. This is especially true in a large enterprise. You may see hierarchical structures and processes in place that prevent teams from aligning themselves around work to be done. You may even go so far as to think ‘there’s no way that would work here.’ But we’re here to say that it can work, and it can yield happy, productive teams who are more energized than ever before to deliver value for your customers.

Supporting self-organizing teams can be one of the more significant cultural changes that a company in transformation faces. The teams in the Distribution department within AEP were faced with a problem; the most valuable projects to work next were not a great fit for the existing project team structure due to skills needed to complete the work. We came to a fork in the road. How can we best handle completing the projects with the teams we had currently assembled?

2.     Background

Rob – I began my agile scrum career as a project manager who was working on projects at AEP when the company decided to begin their agile transformation. I was asked to transition from a project manager to scrum master. I agreed, as most dedicated employees would. What I didn’t realize at that time was how painful the transition was going to be.

Faye – I have been working as a scrum master and agile coach consultant for over a decade. After some time in the financial services, healthcare, advertising, aviation and automotive industries, I became interested in the work that AEP had been doing in working toward greater agility. I joined the Distribution department midway through an active project.

AEP’s lean and agile transformation has been underway since 2009. With a focus on value over process, the journey has been gradual, with many successes and setbacks. IT funding remains project-based; however, as departments accept the enterprise-wide invitation to explore agile frameworks as a way of working, they are also embracing the concept of standing teams.

For our department, the decision to keep our standing teams together, and to bring new work to them, had already been made. However, a grass roots movement to experiment with dynamic reteaming was taking hold. Our partner business units wanted to realize value sooner, but the team felt they needed more people and did not have the right skillsets to deliver in the desired timeframe.

3.     OUR STORY

Our department was almost two years into our agile transformation. We had created two agile teams that worked on longer term projects, and we were considering a third agile team to handle shorter timeframe projects. Both agile teams were formed by Joe, the IT department manager and Rob, the Project Manager at the time. Joe and Rob selected team members to be a part of the teams.

The first team formed was the Distribution Outage Validation System (DOVS) team. Initially DOVS was going to be a waterfall project but very early in the project, it was determined we would implement the scrum framework. The team held a ½ day scrum boot camp, and was supported by three superb agile coaches as the team learned the scrum framework.

The second team formed was the Data Divergence (DD) team. The DD team was formed as a scrum team from the start. The team held a three day agile mindset and scrum boot camp, and was also supported by three superb agile coaches as the team learned the scrum framework.

The two teams, DOVS and DD went on their agile journey, learned more about the agile mindset and embraced the scrum framework. There were some setbacks and continuous improvement items implemented, along with some great breakthroughs in teamwork, communication and capability. The two teams and our department were headed in the right direction, continuing to embrace the agile mindset and scrum framework. Our department also embraced all people working on a project be 100% dedicated to that project, with very minimal interruptions. Our department also embraced each team to work on one project at a time, in order to keep the team focused and delivering value to the business.

Our department was also growing. Due to the large number of projects that our department had in our pipeline, the existing number of people and teams were not enough. We had two new positions that were being added to our department. We had to determine when and how to bring new people up to speed within the two agile teams.

3.1       The Decision

In October 2017, the DOVS work was beginning to wind down with an expected end date of December 29 2017. A new project was ready to begin work based on the business unit determining the next highest priority project to be completed. The new project needed skills that the current DOVS team did not have. Joe and Rob quickly realized that the DOVS team probably could have done the work, but had to consider whether the right people on the team. Joe and Rob once again began to determine how to move the people around between the DOVS and DD teams.

Then, before we did, Rob asked Joe, “What if we let the teams determine who should work on which project based on the work?” Rob explained to Joe about the agile manifesto and self-organized teams. At first thought Joe didn’t like the idea. Rob asked him to sleep on it.

The next day, after some further conversation between Rob and Joe on how the self-organization would happen, Joe agreed to let the teams self-organize as long as he had the final approval of the new teams. That right there, that decision, was a huge win for Rob, the teams, and AEP’s agile transformation. We as a company were making slow but steady gains in the agile mindset!

The main reason behind Joe’s agreement was that Rob and the teams had built up a lot of trust with Joe. The DOVS team was a proven, successful agile team of two years. The DD team had just started to see successes with early, successful deployments. Agile was working, the teams were successful, and Rob continued to encourage Joe little by little along the agile mindset journey. This was just one more step on the journey for all of us.

3.2       How the teams self-organized

Now that Joe agreed the teams could self-organize, Rob had some work to do, as he never had facilitated this type of activity before. Rob scheduled a meeting that included the DOVS team members, the DD team members, and a few other people under Joe’s department who were not currently on a project team. Rob explained beforehand what the meeting was for: to look at the existing and upcoming projects, look at all the people in the room, and determine which people should be on each team in order to best position our department to successfully deliver the existing and upcoming project work.

Rob facilitated the meeting by starting with the names of the three teams on the whiteboard: DOVS, DD a newly-proposed Roaming team. Rob then wrote next to the team names the existing projects each team was either working on or were planned to work on in the near term. Rob also wrote the existing or upcoming skills that were needed to complete the project work, e.g., AEP interfaces the projects would impact, programming languages to be used, technology stacks that would be used, etc.

Next, the people had some discussions about the projects, the technologies and the skillsets the people in the room had, their experience levels, understanding of the AEP systems etc. There was a lot of general discussion about the work and the people that would do the work.

The group then began to tell Rob where to put people on each of the three teams based on how they determined was best to get the work done. As Rob wrote down each name, discussions occurred on the pros and cons of that person on that team. One name written produced nods in agreement among the group, while some other names written sparked some discussion among the group. Names were moved around here and there, until all names of the people in the group were under one of the three teams.

Rob reviewed the output with the group and asked for final thoughts and agreement that the team was in support of the newly organized teams. The group came to an agreement. Rob asked the team to sleep on the newly formed teams before having a final agreement. Rob felt each of the group should have some time to make sure they were good with the changes and their new assignment if they were one of the people who were moving away from their current team and project.

Rob set up a second meeting with the group after a weekend to ensure the team had time to reflect on the new teams. Rob reviewed how the teams organized, and the group formally agreed with the new team organization.

The last step in the self-organization process was the biggest: now that the teams have self-organized, what would Joe say about the results? This was actually a pretty risky scenario Rob found himself in. It was a big win to have Joe agree to self-organization of the teams. What if he didn’t like the results? How would that make the group feel after we went through the process?

3.3       The Results

Rob documented the current teams and the new teams and presented to Joe for review. Joe and Rob discussed some of the reasons certain people were placed on certain teams. Joe wanted some explanation of why the group thought to place people on each of the three teams. After some discussion and breaks to give Joe time to digest the newly formed teams, Joe agreed with the results of the self-organization. A huge win!!

Note that the group came up with DIFFERENT teams than Joe would have assigned, but Joe did agree and let the teams change into the teams that they came up with.

From there, Rob and Faye worked with the teams to determine the best time to make the switch of team structures. Given the DOVS team wrapping up their current project, along with holidays and an office move, they determined that February 2018 would be the least disruptive to the teams and the work they were doing. It was during this time that Joe began the hiring process to add team members to fill in identified skillset gaps.

There were some initial pain points associated with changing people on the existing DOVS and DD teams. Operating agreements were adjusted along with reviewing project visions, how the teams estimated, how they worked with their visual boards, story card refinements, etc. Each of the teams handled the adjustments well, using retrospectives to implement continuous improvement items to refine how the team operated together.

Six months after the self-organization exercise, Faye and Rob reviewed how the process went, along with how the teams have performed. The DOVS team started their new project with their newly formed team. The DD team adjusted to their team changes as well. The Roaming team formed around March 2018 and began their team formation with an agile boot camp as well.

There is a happy ending to this story. The teams ended up being extremely successful in delivering their projects and value to the business unit. Joe was happy with the results of the self-organization and the success of the DOVS and DD teams. The teams were satisfied with the teams they were on, and were seeing success all around.

3.4       Team Change Visual

Figure 1 shows a visual representation of the two teams before self-organization, and the three teams after self-organization. The orange boxes indicate a change the group made during the self-organization process.


Figure 1. Teams before and after self-organization

3.5       Challenges Faced

No one ever had an opportunity to be empowered to make a decision like this, i.e., consider which project would be best for them and the company. It was difficult for some team members to think in this way versus years of a “just tell me which project to work on” thought process.

It was challenging for participants to take in all the information during the self-organizing meeting. Rob laid out the teams and in-flight and upcoming projects for each of the three agile teams. We could have provided some information to people prior to the meeting for them to prepare better.

There were many people that had many skills with varying experience levels. This came into consideration as all three teams discussed who would be best on each of the teams. Every person had to keep in mind everyone else’s skillsets and experience level. We could have provided that information prior to the meeting, or at least added the information on a whiteboard during the meeting.

Joe as the manager of the department wanted the ability to override the group’s decision in case he didn’t feel that the results were appropriate. He wanted that final say on the outcomes.

It took time for all three teams (2-3 months) to complete the reorganization changes into the actual teams that they had defined. This was due to the teams finishing up work in flight. It would have been better if the teams were able to change right after Joe’s approval of the new teams. There would have been a clean break from the old to new teams, and less of a lag as each team wondered when the changes would be enacted.

4.     What We Learned

Overall, team members enjoyed having a say in which team they would work on. There were people who wanted to focus on shorter, quick-hit work. Others enjoyed being able to better align so that people with needed experience and skillsets were integrated into their team. Some team members really didn’t care which team they were a part of, and those were the most difficult situations to work through.

Team members were able to voice concerns about missing skills that were needed in order to be cross-functional, and this provided an actionable guide for management to support whole-team learning. However, no allowance was made for individual professional development goals, possibly due to the time of year when the reteaming occurred.

Often organizations state that this kind of self-selection exercise would be impossible because they envision contentious talks and playground behaviors. For our teams, it really was a collaborative, respectful exercise with one goal: let’s organize ourselves in a way that makes the most sense for our company and our customers. All the discussions were positive, e.g., ‘You are really good at this – you should be on that team to help them learn that skill.’

Realigning the teams by the work to be done and skillsets possessed by the people on the team had a significant impact on team capability and performance. The teams drastically cut down the time spent on waiting for the person with the knowledge needed to be available. The teams each took huge strides in becoming more cross-functional.

There were some things that we would like to do differently next time:

Contractors were not included in the self-organizing session. The reason behind this decision of Joe and Rob was that employees should have the first choice in determining where they would go, versus a contractor taking a spot on a team that an employee should be in. This was a bad decision looking back. Joe and Rob actually limited the team on how they could self-organize based on this decision. Contractors should be included, and Joe and Rob should trust the team that contractor or employee, the team would self-organize the best way for the company.

Business unit people were not included in the self-organizing session. The reason behind this decision of Joe and Rob was that the business unit people were pre-assigned. The business basically said their people were not able to move between projects, so Joe and Rob decided not to have them in the self-organizing session. This was also a bad decision looking back. Even if the business unit people could not move, they could have had a say during the discussions as the teams were self-organized. The outcome may have been the same, but the business unit people would have been a part of the session and perhaps felt that they had been included in the decisions.

Joe and Rob should have provided the team a better understanding of the fact that each person now had a say in which project they could work on, based on positioning the teams to be successful. That’s a big change from years of being told which team to work on. Some comments during the self-organizing session were “just put me wherever”. Rob did facilitate those comments with explanations that they have a say now, but it may have been worth visiting one-on-one with each person prior to explain better they have the power to have a say on where they were working next.

Each person should have received information about the three teams, existing and upcoming project work including the general timelines and technologies used. Rob explained this in the self-organization session but there wasn’t enough time for people to take in that information and think about it before determining who should go on which team.

Rob and Faye managed the people moving between teams by discussing when the right time was, how the transition was going to happen. To move even closer to true self-organizing teams, they should have left that to be determined by the teams. The team members were more than capable of making these decisions.

5.     The Future of the department and self-organization

Now that Joe, Rob, the teams, the department has experienced a self-organization of three teams, Rob has pushed the self-organization limit even more in the department. It’s both exciting and difficult at times.

We have changed the approach with hiring contractors and employees. In the past Joe and Rob interviewed and selected new people into the department. Now, the teams interview potential candidates and go through a discussion and voting process to select new people to join the agile teams.

We moved to a new office location and let the teams have input on their new agile rooms including furniture options, lighting, projector location, whiteboard options etc. An interesting outcome here is that two teams selected different furniture configurations. Almost a year, later the teams joke about which configuration is better (or worse!). An easy response to any comment about furniture is, “Your team selected it!”

As of this writing, the department has just begun our second self-organization session as team changes have occurred and projects are ending and starting again. Time to go through all this again with what we have learned!

Joe has asked the teams to be prepared for future self-organizing sessions. We plan to continue self-organization as our team members change, existing projects end and new projects begin. There is no set timing for future self-organization; it will be determined by the amount of change happening with people and projects, and when Joe, and more importantly, the teams feel team changes are needed to successfully complete the work.

6.     Acknowledgements

Rob – I’d like to thank Faye for coming onboard to my department and helping me continue on my agile journey. Without her this this paper and this talk would not have happened. I would also like to thank the teams involved in the self-organization process. They understood this was an experiment and supported giving it a try. Finally, I would like to thank the department manager Joe. His trust in me and our team and his agreement to try this self-organization experiment was why we were able to self-organize.

Faye – I would like to thank Rob for demonstrating courage in suggesting a new way for our teams to self-organize, and for encouraging our department to try. Additionally, I want to recognize our teammates for embracing this new method of team formation, and for demonstrating a sincere interest in protecting team health, as well as doing what was best for the organization overall. I would also like to thank our Agile Services and Coaching team for their vision for lean and agile change within AEP, and for their guidance as the entire organization uncovers better ways of working.

We would like to thank our shepherd Margaret Fogel for her patience and insightful feedback as we prepared this report. Her guidance was quite helpful as we worked through the challenges of accurately portraying our teams’ experiences amid organizational changes and pressures.

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
Agile2018

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Have a comment? Join the conversation

Related Agile Experience Reports

Abstract—Manager as scrum master? You can not do that! It goes against the conventional wisdom, which assumes command and control managers cannot lead and coach as Scrum Masters. However, as an important aspect in Agile change, self-managing means a …
Abstract—Manager as scrum master? You can not do that! It goes against the conventional wisdom, which assumes command and control managers cannot lead and coach as Scrum Masters. However, as an important aspect in Agile change, self-managing means a …

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now