Cross-functional collaboration can feel counterintuitive for some, especially if you think about building software like manufacturing. In a manufacturing mindset, teams are like workstations doing one thing and then handing off to another team. This can be remarkably efficient when the interfaces are well-defined and stable.
But that approach has risks when our work is not well-defined or predictable. Most software projects are more complex, with unknown unknowns. For these sorts of problems, agile approaches with cross-functional teams work best. And early cross-functional collaboration can have unexpected benefits.
I had an opportunity to try cross-functional work in what was normally a siloed organization. Engineering built applications, and the data team designed our data architecture separately. Typically for a project, the database architect would design the database schema and the application team would work with it. This usually worked fine, but sometimes working with a predefined schema led to a more complex application.
When I found myself the sole developer on a new application with just one database architect, we decided to try collaborating early—before the details of the data model were decided. We found that we built a better application more quickly, but not just for the reasons you might think.
We expected that early collaboration and iteration would help us discover gaps between the data model and the application requirements. By developing vertical slices of the application, we recognized some scenarios that the data model didn’t easily support, and we made those changes. This is a well-known benefit of cross-functional teams. But it also meant we could make one early decision that saved a lot of effort but was also very simple. It involved the seemingly trivial issue of naming.
The database team had a naming standard, but unfortunately, it conflicted with the defaults of the object relational mapping framework we used. While it was possible to map arbitrary object fields to arbitrary data fields, this led to more code, and more chance for error. We decided to use the naming standard that made coding easier, so we were able to avoid some of the simple errors that often hit other projects.
By working together, we found an opportunity to make a change early in the process that helped speed development. Yes, we could have worked with any naming convention the database administrator proposed, but by making a decision together we were able to weigh options with an eye toward a better deliverable.
This simple example of cross-functional work brought home for me how easy it was to collaborate and how big the win was. It also meant that I had a better understanding of the application as the developer, and the database architect had a better understanding of the impact of the schema on the application, making it easier to make reasonable choices on our own. And we felt joint ownership of the application, so there was less of a tendency to blame.
While I always knew cross-functional teams are central to agile, there were often barriers to fully embracing this practice, and I was more likely to make exceptions. An experience of how collaboration on small things led to big wins helped me to realize the true value of cross-functional teams.
Very well Written Steve.