This is the more popular article from my technical wesbite codingepiphany. Just like some other agile related articles, I have made it available on this site as well since it would be appropriate.

If you have tried or learned a bit of scrum agile methodology you would no doubt have heard of cross functional team. These are the teams consisting of multiple members with different specializations and general knowledge of the other members’ specialization. The cross functional team is of course not something that an organization can build overnight. Successful cross functional teams formation require high agile maturity, enough resources (cash and skills) and most importantly great teamwork.

To make it easy to explain what a cross functional team is supposed to be, I’m going to draw the analogy between cross functional team and an RPG party. This is because I used to like playing RPG game and hopefully there are others that can relate as well.

Multiple Masters of Skills

When you play an RPG game, be it the old school ones like Lunar Silver Star story or the newer ones like Wasteland 2, you’ll find it that your character’s party would most likely be made up of different character classes. It’s never wise to move forward with a team consisting of all malee users or magic users, in most cases your team would wiped out immediately. As an example if all your members are malee users, as soon as there are magic enemies then the team will be in trouble.

As a generalization, the team character classes that I normally use are:

1. Speed attackers (those with moderate damage with quick turn)
2. Heavy hitters (those with high damage physical attack but longer turn)
3. Attack magic (magic users with offensive specialization)
4. Healing magic (magic users with team healing specialization)
5. Merchant (to get greater discount of items)

Now, even if I have all the above, a strong party does not happen overnight. As the party progresses, each of the team members’ experience will increase. The important thing is to make sure we use the experience points to learn the specific specialization of each of the members.

I’ll use the magic user as an example. They can either learn attack magic or healing magic, the best thing to have is to get each of the magic user to specialized in each of them. High level healing magic user will be able to restore much more health. I think the worst thing to do is to get the magic users to try to level up both attach and healing, they will end up with mediocre level of both of them, resulting in hard battles.

When your RPG party is at high level and all specialized, most likely the party will be able to handle different kinds of quests and enemies. If a strong group of enemies appeared then the speed attackers and deal with individual attacks, heavy hitters do mass damages, attack magic users then either strengthens the team or deal elemental damage attacks. Let’s not forget the healing magic user too, he/she will heal the party on each turn, resulting in the other members health being restored.

Then you might say…whoa, what about the merchant? He can trade but he’s weak at attack and knows no magic. Well, you’ll be surprised how handy this extra member can be for supplying mana restoring potion during the battle or providing support attack. He can also perform handy things like applying restoration potion to a fainted (0 HP) member during the battle, so that he/she can continue the battle. We’ll talk about the merchant a bit more later.

Reality

Let’s go back reality and think about our scrum cross functional team. I’m going to use a software development team throughout this article to discuss the scrum team. The best mature web development team composition might consists of something like:

1. UI Developer
2. Backend Developer
3. Graphic Design and UX
4. Tester
5. Business Analyst / product owner
6. Scrum Master

Like our magic users in our RPG party, the developers all focuses on their own different specializations, therefore which ever projects are thrown at the team, they will be able to tackle it. In addition when the need arises, they will have the graphic and UX designer to help them with the user interactions. The tester then supports the team by ensuring all the products are high in quality during the duration of the development. The important thing is that the tester must work together with the entire team throughout the entire process, just like the healer works all the time during the battle. If they only work at the end of the cycle, then quality problems might arise, just like if the RPG party waits until the entire team reaches to 10% of HP before healing.

In order to complete the parallel, I’d like to mention the business analyst, which is a bit like the merchant in our RPG party. They do not necessarily work hands on with the development itself, but they have to work continuously with the rest of the teams as the person who make sure the products being built is going to the right way. Another thing that didn’t exist in the RPG party previously is the scrum master. He/she is the person who protects and guides the entire scrum team, in a sense, it’s a bit like Nall (the cat like friend) in Lunar. He doesn’t necessarily join the battle, but he keeps a record and gives guidance to the team. He also heals the entire team when possible if the situations were completely dire. So the scrum master is not the hero, he is more like the protector and guide of the team.

Cross Roles When Needed

We talked about specializations a lot in the previous section. While we definitely favor specialization, guess what, sometimes the situation requires cross roles, especially if the quest is of higher difficulty than the party can comfortably take. If for whatever reason all the attackers in the party fainted, we expect one or more of the party members to take the attacker roles while the original attackers are being revived.

Just because a character is specialized in merchant or magic, doesn’t mean that he/she cannot perform melee attack at all. While the merchant does not have lots of inherent attack power due to his class, it’s possible to equip him with good swords and armor, therefore he should be able to inflict some damages to the enemies. This is equally the same with the other members of the party, the magic user can use their magic staff to clobber the ogre. One thing to remember is of course, to revive the attack team. This is why the healer must not attack as well , instead he/she must focus on the highest priority task at the moment, that is reviving the 2 attackers.

Reality

Let’s go back to reality again from our RPG world. I hope the parallel to reality is quite clear, in that the scrum team members should have the ability to assume others roles when needed. To give you an example: if the the web application that you are building have somehow a lot of user interface issues due to technical difficulties and unforseen complexity, it’s possible for the backend developer to actually give the user interface developer a hand. Even if the backend developer is not highly trained in user interface development, he/she should have some knowledge of coding that he can contribute on fixing the easier defects. This is the same with the user interface designer and the business analyse, they can either help with the user interface development or helping the tester.

Like our magic user in the example above, the user interface developer must not divert from the highest priority item at the moment which is continuing the UI development and fixing the defects. While the same applies with the tester, he/she must continue with continuous testing as it is important to the UI developement progress, it wouldn’t be advisable for him/her to abandon the testing role and start helping with development.

So, don’t forget that while the team should be a mile deep in their knowledge the should have a bit of 10cm deep knowledge across the different team functions. Of course it’s not possible to do this 100% but at least we should strive to do this. As an example, a UI developer can sometime have a look at the backend code and have a go at modifying or working at lower priority tasks.

Team Formation Itself is a Quest

Remember when you start playing an RPG game where you start only with your hero? In Lunar Silver Star Story it’ll be just your hero accompanied by Nall. The perfect harmonious party did not happen straight away. One by one the party members were eventually found and joined your team, starting with Luna, the merchant and the rest of the characters along the game. Some of the characters weren’t event found until the middle of the game even, it took a lot of quests completion to get great party members.  Some doesn’t even stick with your party permanently, only on some of the quests they will join and help the team.

It also takes a lot of leveling up to get the correct skills so that each of the characters can support the team.

Reality

I’m sure by now you realize the parallel to our scrum team with the RPG party. When you start up a cross functional scrum team,  you as an advocate and starter will most likely start alone just like the hero in the RPG game. The team will not form straight away, sometimes you’ll start with different team members sharing responsibilities between different teams.

Other times you’ll have part permanent team members and the rest comes into the team as needed. If I’m to give an example it would be like database administrators. In most organization there won’t be an abundant numbers of them and not all projects require database administrators. Therefore it doesn’t make sense to embed a database administrators permanently within the scrum team so they normally join when required and left the team once their responsibilities are fulfilled.

Like I said about leveling up in RPG games, a cross functional team must always strife to improve themselves. That is by means of research, pair programming, presentations, retro and many other things. We must always keep in mind that knowledge sharing is a critical thing to remember and that each team members must always thing positively in terms of helping each others. It takes time to get to know each of the team members and it also takes time to find the correct person to join the team.

Closing

I’d like to re-iterate my point that a scrum cross functional team is like an RPG party. It doesn’t happen over night, it can take a bit of time to form, the members must be a mile deep in their specialization knowledge yet have 10 cm knowledge across other areas that the other members are specialized at so that when the need arise the team can keep moving forward.

Most importantly is to always keep having positive mindsets within the team. If you play RPG games like Lunar Silver Star, I don’t think you’ll find your party characters grumbling and blaming others all the time (ok maybe some games that I don’t know has it, but not Lunar!), instead the members are almost always ready to move forward to the next quest no matter what happen. In some of the even the enemy character becomes one of the party members. Why is the stories written this way? Because it’s always more fun when everyone is in their positive mindset even when faced with the hardest challenges.

I understand that this article is pretty nerdy or even unusual for a business management story, but I’m hoping that it make sense and that it can relate with many people seeing that RPG games are quite widespread these days.

If you have more to add, please feel free to leave some comments in the comment section. Remember, positivity and knowledge sharing is the key to successful team!