{"id":22247,"date":"2016-08-24T08:22:22","date_gmt":"2016-08-24T15:22:22","guid":{"rendered":"https:\/\/www.jamasoftware.com\/?p=22247"},"modified":"2023-01-12T16:54:59","modified_gmt":"2023-01-13T00:54:59","slug":"self-selecting-agile-teams","status":"publish","type":"post","link":"https:\/\/www.jamasoftware.com\/legacy\/blog\/2016\/08\/24\/self-selecting-agile-teams\/","title":{"rendered":"Self-Selecting Agile Teams"},"content":{"rendered":"

As Jama grew, our Engineering department began to change overnight. Teams were outputting consistent velocities, we had upped our abilities technically on how we measured areas such as performance and quality, we began 8-week planning cycles, we doubled our Engineering team and we had a strong roadmap to follow but for some reason it didn\u2019t feel right. Identifying what that was exactly is where the challenges began. Why was it that we\u2019ve come so far as an Engineering team but didn\u2019t feel we had reached the Agile utopia we were seeking?<\/span><\/p>\n

So What Were the Issues?<\/span><\/h3>\n

First and foremost, we called ourselves an Engineering Team, which meant that we were all in this together and operating as the collective whole, however when you really observed what was going on you saw static individual teams focused on only their projects. This became clear one day when I was in a meeting with Product and was told that the \u201ctop priority project\u201d needed protection to get it out the door. I put it in quotes because at that time I thought there were multiple priority projects but no clear communication on which one was higher than the other. I then decided to test this with my team. In 1:1\u2019s I asked a sampling of my team members, not on that project, what they thought was the top priority.\u00a0The way in\u00a0which\u00a0I received the answers told me we had an issue. Half of the people I asked didn\u2019t know and thought that what they were working on was a priority project, the other half answered correctly but with a very guarded response, as if they were going to be judged if they got it wrong. I then asked one key question to some of them, \u201cDo you feel empowered to help that priority project if it needs it\u201d. The answer was \u201cno\u201d. Not because they didn\u2019t want to do the right thing, but because of the pressure they felt to get back to the project they left and get it on track again. The teams felt they were being measured on hitting certain sprint goals even if the business made the decision for them to do something different that affected it. We needed to get to a model that allowed teams the flexibility to protect our priorities without a feeling of guilt for those ones they left.<\/span><\/p>\n

Teams\u00a0believed that with more measurement came scrutiny. I started hearing comments that teams felt the business cared about velocity numbers more than the value being delivered from them and because of this they were more focused on how to make their burndowns look good, rather than taking chances and shifting during a sprint if that affected how the burndown presented itself. Hearing this cut to the core of my being because I wanted teams to take chances, innovate and change the sprint if it no longer made sense. Why continue to build in a direction when you know it\u2019s the wrong path? Also, I know that there is always a story to tell behind burndowns regardless of how they look. I\u2019ve had plenty of teams show me poor burndowns, but then the explanation as to why, is\u00a0where I find the\u00a0true value of a burndown, because the team iterated and learned something about the project that forced a shift. This is what we needed to reward the continual learning and change to reach the overarching goal as we drove to the end of the project, not every burndown\u2019s success.<\/span><\/p>\n

Another issue was around Engineering Priorities. Some examples include items such as infrastructure improvements, removal of tech debt, automating certain processes or refactoring problematic areas of the code that slow us down. We tried our best to recognize these issues within our team and tell teams to budget a certain amount of time out of their sprints to take this on. This \u201cpeanut butter\u201d approach seemed like the right way to go but it was very apparent progress on those items was slow, or abandoned all together, because it was too hard to balance those priorities with the project work teams needed to get done. More often than not, a team would begin their sprints, find new work because of discovery and this additional work would overrun the time we allocated for the Engineering Priorities. Now in this model we make projects out of them and Engineering gets a budget to form a team and take these on every cycle. This brings more focus instead of the context switching within a sprint from project work to something that may not be related.<\/span><\/p>\n

Cross-pollination of technologies, team processes, best practices and overall learning about the application was low. We had our Agile ceremonies and other meetings to talk about these in a cross-functional setting, but in the end teams would go back and continue to practice what they always had done. As a smaller engineering team I had newer employees tell me they didn\u2019t even know their peers that well on other projects. This just seemed strange given we\u2019re all within a small vicinity of each other. So why not give teams a chance to change up their team composition based off of people they wanted to learn from, processes they wanted to try or technologies they wanted to learn?<\/span><\/p>\n

\"Self-Selecting<\/span><\/p>\n

I Wasn\u2019t Alone<\/span><\/h3>\n

After feeling this way for some time and hearing more and more feedback on how teams felt I began to wonder if it was just me or did others see it. I needed to see if Product felt this way, so I reached out to Derwyn Harris, one of our co-founders that\u2019s in the Product team. Over lunch we discussed what we saw happening with the teams, challenged ourselves on what we thought we wanted out of the teams and talked about teams self-organizing around projects they could make the most impact on. The conversation was all laid on the foundation of empowerment and autonomy with the goal of increasing quality and decreasing lead time. In the end we walked away with a common goal and understanding of what we saw and what we wanted to change.<\/span><\/p>\n

But wait, there\u2019s more! Cristian Fuentes, one of our Engineering Managers, was also thinking of a way to further protect our team\u2019s priorities to get work out the door, and Shane Patrick, our Sr. QA Manager, was building momentum around a centralized QA Team to help offload regression cycles from the other teams to protect project work. All of our ideas, thoughts and observations were coming to a head, which made it very clear that there was time for change at Jama.<\/span><\/p>\n

\u201cWE\u201d Weren\u2019t Alone<\/span><\/h3>\n

There was also validation in the industry of others trying models like this and having success. Two of the major players were Spotify <\/a>and Valve<\/a>, each doing something a little different but again built on the goal of empowering their engineers to make choices. Using these as case studies to gain confidence in our direction was key.<\/span><\/p>\n

It Wasn\u2019t Easy<\/span><\/h3>\n

Even though we had all this momentum from a leadership perspective we needed to make sure our teams understood what we were trying to do and why, gain alignment and test our theories. Derwyn created a Circle of Influence diagram to help us identify key stakeholders in the process and their overall support for it. A lot of conversations began with team members to get their feedback, and concerns, that helped us refine our approach. All of this happened over the course of a couple of months, because we knew we needed to make sure this was the right thing to do for Jama and our teams. A successful rollout required patience, listening and a build-up to buy-in.<\/span><\/p>\n

Let\u2019s Do This!<\/span><\/h3>\n

Now that you have some of the backstory let\u2019s roll into how the teams formed around our priority projects. As of right now, we have an 8-week planning cycle that we plan for. Within those 8 weeks we run sprint lengths of 2 weeks. The goal of this planning cycle is not to load up all the sprints, because we all know that\u2019s impossible and so much changes early on that rearranges your later sprints anyway, the goal is to provide enough clarity so the teams can have solid direction and know the release goals their striving for.<\/span><\/p>\n

First we need to know our priorities. Product utilizes a process to help calculate this called Weighted Shortest Job First<\/a>. This method combines a number of different criteria to help us evaluate a project\u2019s importance. We use this method not only on roadmap features, but also on our Engineering priorities. It’s not an exact science but it gets us close.<\/span><\/p>\n

Once those Product and Engineering priorities have been identified we provide one list for the teams to look at. This helps to bring clarity on the priorities and highlights ones we need to protected so we can get them out the door. Protection comes in different forms but simply put, if there is something a priority project needs, or if there is something that could potentially interrupt that project, teams around them are empowered to figure out creative ways to absorb those risks and keep them on track.<\/span><\/p>\n

For us to get a good idea for the size of the projects they must also have an estimated duration in sprints and potential roles needed on the project to make it successful. For example, Project Unicorn could take up to 2 sprints to accomplish and it needs 3 Engineers and 2 QA Engineers on it to make it successful. This helps to recognize if a project is staffed appropriately and also exposes potential future scenarios for teams to roll off onto other projects.<\/span><\/p>\n

Team members then get three votes after the Product Managers, or potentially a Technical Leader of the project, have had a chance to pitch their ideas to the teams. We are now doing this in a Science Fair format before the 8-week planning day. Once they have heard all they need to about the projects, they get to place their #1, #2 and #3 votes on the ones they are the most interested in, or feel they can provide the most value to the business. Once this is done the results tell us a variety of different stories:<\/span><\/p>\n