What is agile development? Wikipedia defines it as “… an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).” When looking at this definition, the word that stands out to me is “evolve.” In order to be agile, you have to be open to evolving as a team to be most effective and streamline in your work. Evolution requires experimentation, and that is what we are doing at Trulia.
At Trulia, we have three main verticals that deliver features for our users, and if you take a look at each of the teams they are all using the foundation of an agile framework and ceremonies in the same way (standups, sprint plannings, retros, etc.). However, two of the three verticals differ in how they ingest these requests and these differences are intentional and planned as a way for us, as an engineering organization, to experiment with what might work best for our teams long-term. Our 3rd team is working in a classic agile way, sticking with the main ceremonies. Ideally, in the end, we would like to find a process that works efficiently, that all of our teams can adopt.
Last spring a few of us attended a LeSS (Large Scale Scrum) training and learned about how that framework helps organizations with scaling agile for larger teams. Our Growth and Engagement team at Trulia took some of the learnings from that training and applied them to the structure they already had in place. This was done creating one view of the work to be done (backlog) by the whole vertical, broken down into shippable increments, and owned by one product owner.
A designated team, comprised of engineering leads and product managers, meets regularly at an SOS (scrum of scrums) meeting to check in and reprioritize the backlog constantly as an effect of the findings they discover while implementing other tasks. The ability to learn from our experience and shift quickly helps to ensure the team is hitting its objectives and delivering on top priorities and features to our users before moving on to secondary tasks. We want to make sure that every team in this vertical is taking on the most impactful work, so rather than anyone pulling in a lesser priority item, we encourage team members to jump in and help another team with something that makes a bigger impact on the business.
The Growth and Engagement vertical also does a backlog refinement, which has gone through a few iterations already to get to where it is now. It started as a team-specific refinement of stories to be broken down, but others showed interest, so they opened this up to the whole vertical. The team sends out an invite with the stories they will be looking at ahead of time, and the engineers interested in helping to break down those stories show up (completely optional) to discuss each challenge. The product owners present the stories, and then everyone breaks up into teams to tackle them, then comes back together for the final 15 minutes to recap to the larger group. These stories range from technical tasks that can be broken down into steps, prioritized in the refinement meeting and made ready for the engineers’ next sprint, to design research that allows the design team to start formulating a direction for new features. In the end, we benefit from gathering input from multiple people across the vertical with different perspectives.
Another one of our verticals, the Local team, which works on Trulia Neighborhoods and other local features, has experimented with the process extensively to find their sweet spot. About a year ago we attempted to set up as cross-functional teams, decoupling manager reporting structures from the actual delivery teams. However, this proved challenging since the main project the vertical was working on was a waterfall. We learned that product demands and the way projects are tackled heavily dictate team structure and the hybrid model we tried didn’t work out as well as we hoped.
After this very large project (launch of Trulia Neighborhoods) was completed by the vertical, we have once again restructured the teams to be more feature-based and are approaching the backlog to see how the teams can focus their work on OKRs and company goals in a more iterative and agile way.
A lot of headway has been made in regards to agility and prioritization, allowing the teams to be driven towards more focused goals and delivering incremental value to the organization. In the future, we aim to give the teams more autonomy and empower them to see how the work they do impacts company goals. We are finding that some of these changes have been successful and others not, but we are taking our time to identify and document the lasting effects of these experiments before we come to any major conclusions and decide to implement something across the Trulia engineering organization.
