This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The best architectures, requirements, and designs emerge from self-organizing teams.
— Principles Behind the Agile Manifesto [Beck, 2001]
Working in multidisciplinary teams is one of the main success criteria in Scrum. It is crucial to have different elements of the project—including the user or customer—represented on one team. In reality, in my work with clients, I often see that their move to Agile consisted only of changing the management style of a team, and in most cases this applied only to the software developer team. It is no surprise, then, that I often hear a description of the situation that goes something like this: “OK, we have this software development team here, and we want to test out Scrum. Now, we are looking for a Scrum Master. Oh, yes, and we have worked with Scrum for a number of years, but it is not working. Maybe you can help?”
My initial questions to a client revolve around what is not working and whether Scrum was set up as a project (see “Our Scrum Is Special”). I then focus on one of the points listed in the Agile Manifesto, namely multidisciplinary teams. What is a multidisciplinary team? Does creating such a team mean that you have to mix Java and Android programmers? Or that people on the team should have some PHP experience if a website is involved somewhere in the project?
Actually, multidisciplinary teams are one of the core principles of Agile, as opposed to Waterfall. To understand the benefits of multidisciplinary teams, let us first take a closer look at what the Waterfall method (which does not incorporate this approach) looks like.
The first essential step in setting up a company is assembling the right group of employees. In a company following the Waterfall method, ads for jobs are written and specialists are hired to do specific jobs, like programming, marketing, sales, or editing. Each person works in his or her specialized field with maximum efficiency.
Initially, the specialists form a common team, a handful of people working together on one project. With the growth of the company, new people are hired, and each specialist will lead individual teams; the former specialists become managers and each team gets its own room, its own planning, its own resource allocation, etc.
Depending on the environment (startup vs. large, existing company), the course of a company can vary widely, but essentially, in companies that have not adopted Agile, you will usually find specialized departments each performing a task with maximum efficiency. Sounds great, doesn’t it? You have the best people working in specialized departments highly attuned to their tasks. What could go wrong?
What could go wrong is that this kind of departmentalization will most likely lead to the use of the Waterfall management method—at any given time, a department works on one phase of the product. First, it goes through design, then development, then editing, quality assurance, marketing, and finally publishing and sales, with the managers busy with tons of meetings, cross-department communication, and resource balancing. With multiple teams, it’s nearly impossible to have one team ready to start the next phase just as another team finishes. Ultimately, this leads to long release cycles—sometimes years-long.
Then, people hear about Scrum. And what do they do? They take individual teams, set up a product owner and Scrum Master for each team, set up a ticketing system, sprints, and more meetings—with the managers still busy communicating and negotiating resources between the teams. The result? Marginal effects, somewhat more disciplined development teams (mostly because of more investment into the build systems to allow more frequent releases), and a story to tell all the developers that now, with Scrum, everything will be better and will continue to improve over time.
I hate to break it to you, but this is Scrum in name only. Specialized teams cannot deliver anything but concepts or work packages. Suddenly, the users are no longer the customers—instead, the “customers” become the next team. Eventually, only one department (sales) ever faces an actual customer who will use the product.
Now, moving from the phase-based management of Waterfall to Agile, how can companies benefit from having multidisciplinary teams?
Break with the idea of departments and focus on products (or features). Put together all the people—including marketing, design, and sales—who will deliver the final project. Does that mean that the salespeople have to learn Java and the tech guys have to do sales? Well, yes, to some extent. At least they have to learn how to deliver a product together and help each other out. Ideally, this would have begun during the hiring process, recruiting people who are good in one area, and know a little bit about all the areas. If you have only specialists, have them work in pairs (two people, one computer) on features, allowing easy knowledge transfer between departments. Also, even in early development, there is a lot to do for everyone. The salesperson might not develop a new API, but he or she can help with testing, meeting with clients, preparing presentations, advocating the team’s ideas within the company, creating beta- and sales channels, setting up newsletters and landing pages—all tasks marketing and sales could start doing early on, in addition to learning how the product works from the inside.
For an established company, this is a long road. But your competitor has already started doing it and your only advantage is that you (still) have more resources than the startup next door. When will your organization improve and become truly Agile?
When it comes to multidisciplinary teams, how is your company doing? How are the teams in your company structured? Does that structure support information exchange between departments or specialization of individuals? How are HR decisions integrated into your Agile strategy?
