Team Synergy

Because Synergy is not understood broadly, I am going to give a general definition which I got from the internet and fits for the current scope of this article:  "The interaction of two or more agents or forces, so that their combined effect is greater than the sum of their individual effects."

Most of the amazing stuff I have seen that go beyond the normal productivity and breaking the ice of continuous issues (which makes some developers become in a state of inertia) is when I see a team whether it is in synergy or not. You already know you are in one and it does not require more than a week to see and get deliverable out of it. However, that requires some prerequisites (which I will discuss at the end).

To prove that, I am going to give an example of my own personal experience.

My last classes in my university 4 years ago had a lot to do with creating business applications that resemble a lot practically in my current jobs I had. Its those classes where "you practice on what you have learned".

3 Day Synergy

One of my business class assignments was to create a clone of a social site like Facebook (I am not kidding). I was too busy with other class assignments, so I did not have enough time to find any team to join yet. I literally picked a random one (yes, a random one) to join. And the due date was in 3 days. You can imagine how our whole team mentality picture was for this project: "We will just 'pass' it or get an average score out of it". Did we had any close connection in those last 3 days when we did our project? Yes, kind of. But long term wise? None at all. In the end, our project was the only one that met all the requirements that fit close to the original assignment. To tell you the truth, the project was open ended, where each team could deviate their project goals as much as they wanted to. In any case, here is the wrap up of what we did in 3 days

Day One: On Day one, we didn't start at morning, but around evening. 

A fair introduction was done while we all sit on the table. I focused on php and mysql to build the basic structure of facebook (creating schemas, deploying the basics of the site). Nobody was expecting much about the "facebook thing". We were just joking about recycling another facebook clone and use it. Why re-invent the wheel, right?

Day Two: All team focused on their things. 

One of them was very good at documenting and creating manuals. He would observe every moment and understand how our system works. He already had a high end job doing system analyst tasks like writing perfect manuals for outsource teams and so on. The final deliverable of his manual for our project was something I have never seen even on myself or any manual deliverable I have seen on the jobs I had so far (which is kind of a shame).

One of them was very good at web development, especially in layouts. He recycled some of his layout he used in another project and in some sense integrated the behavior of my sql/php outputs that were just plain text in a layout that is similar to facebook. The layout was very organized and nice. It was easy to access and understand. I can still picture of all the layouts all teams presented, ours was the most simple and elegant.

I was encountering some issues at that day with the sql code and business logic adding friends and posting comments on others` wall post. I had to draft the design changes in pen and paper with squares and circles to clear my mind out. I don't remember exactly, but in some sense we worked a lot on that day figuring that out while they still worked on small sql/php tasks that I directed them to do. In the end, we managed to resolve all bugs. It was fully functional, it was not just a beta demo.

Day Three: Design Layout, Documentation, bug fixes

So here was the final touch of the cake.

The person who documented stuff made the manual out of keen observation and testing the program at the end. Many people think that asking questions and getting answers is the way to document. But something I learned from that time is that our senses with our eyes and our own actions can tell us more how a thing behaves beyond the answers of people say that can just be most of the time bullshit.

The person who helped integrate the web layout was the star player on that day. He did most of the tasks at that time. Integrating the layout with my plain text and asking me specific questions about specific part of the data, the home page, the profile page, and so on.

At the same time, I found bugs on edge cases and fixed them while doing more extensive testing on the business logic behavior.

At late night we did our final deployment of the project and printed out the manual on the next morning. Most of these tasks on day 3 were done with the help of my team. Without them, I don't think the final deliverable would have been any close to that.

Presentation Day:

We saw a lot of projects presented in class. None followed the exact requirements of our teacher original assignment. Most focused on extra features, such as security, or other stuff they were at expertise of. A lot of basic features were excluded or had small issues. They were all interesting nonetheless. Being almost last to present, probably everybody was intrigued when we demo our project within our presentation. Our teacher even commented to all of class, suggesting that only our team was the closest on building the facebook website based on original assignment.

And on presentation day, last day of our class, we as a team, had to drift apart. They offered me beers, but I declined, not my favorite beverage folks. We were all speechless and we don't know what we did in the last 3 days, even me. How were we able to create a facebook page in 3 days flawlessly as a deliverable?

These are the things now that I can see being very important

1. You need to have the skills and the right skills with the correct environment:

I knew php and mysql pretty well before I took this class because I already developed a complicated online ordering form on my summer work that took calculation whether the item is on stock or not in a "flash sale" style for a small volume of end users. At the same time, I learned a lot of other stuff through that class (deployment environment, etc.). Now, my long term memory is out of sync with php/mysql, but at that time, I knew it well and I knew how to use it like it was my daily job.

Moving on, the other two I worked with had the right skills. One with web layout stuff and the other for documenting stuff in a manual. They had experience of it as I had mentioned before. I was not so good at that stuff (especially web layouts) as much as they did. It is different knowing it and practicing it and completely different full time working at it everyday.

If all of three of us knew how to do sql and php, our web layout would not have been like it was in the final deliverable and our final manual would have been flimsy with grammatical errors.

So if you don't have a skill, you have to prepare it before hand. But don't learn any skill. Think what skill you will need in the future that others won't have. Also, learning other skills that are not your main forte will help you collaborate with other users with different skills more easily.

There was another component in our team that was kind of important. Nobody enforced what the others had to do in their own specialty. It seems if two people know SQL, there would be a lot of clash on what is best practices. However, since for each of their own due our skills were different, we accepted on what others did as the best practices, even if that practice may had a small marginal error. These clashes though are required for projects that need to be maintained for the long term as that will bring new techniques for being more productive. However, with our time being limited and given that it was a new feature, this situation was the most potent for us as it did not require our skills to be the most perfect at that time.

In other words, it seems that we have to read the situation sometimes and think whether we have to or not to clash. If the project is becoming complicated and it needs to be re-factored, then clashing is of essence. However, if something is urgent and we need to push it, then having faith on our skills and of others skills is of essence (however, what is urgent, it is usually "abused")

In one of my articles, I said skills are not the only important element to be successful. That is kindly true. Because Important fact #2 and important fact #3 require you to 1. Understand philosophical foundations 2. Embracing and giving creativity 3. In order to establish creativity, you must first change the existing habits and culture of the environment even if the outcome is emotional painful or negative.

2. The requirements need to be pre-defined and frozen and be as simple as possible with not a lot of features

This is quite important. Compared to class assignments which are pre-defined and no changes are done afterwards, you will rarely see that in a real job situation. However, idealistically, an effort to such method is of essence. If there is a need for a new requirement, it can be pushed on a different milestone instead of the current milestone.

The other important factor is to be simple. Do not add a lot of features as 1. you may not need them as you may change your mind later on 2. More features will make harder for unit testing and for the developers to feel they are reaching closer on completing the goal. When you have a problem to solve, you have these types of feeling: What design I have to choose to solve the problem (the most stressful part and the most time consuming) and implementing the design (the most exciting part but the one that doesn't last long to linger that feeling out of it). So when you add a lot of features to the project, it makes the joy of developing less fun. On the other hand, it should not be adding small features at a time to the point you have to talk more than developing. The features to add should be of balance that can be done in a week, not a month, but not in just a day. If users ask for a big project within a milestone, reply back to user that it is impossible and make a consensus for that milestone to be broken into multiple milestones where at the end of each milestone the user looks if the project is on the right track or not.

3.  The direction and attitude and the external factors of the environment matters a lot

Environment applies a lot. My previous job did not had the right direction and correct attitude when I was working there. Most importantly, using external factors to influence the internal factors of our own desires on what is best practices is a total shame for any company to do. I understand they are not aware of it and are overwhelmed and influenced by the chain of events through other forces that keeps the company stable and profitable. However, that direction is like replacing the ideas of an architect creating a bridge by some user who is less competent on those same foundations. That in result creates an unstable software.

No wonder a lot of talented developers leave when a small company is merged with another company, as they know the environment will not be fruitful for synergy, even if no member within that team has not left out of that company yet.

There may be some productive environments and toxic environments within the same company. So when we define "environment", we do not generalize the whole picture of one company, as each company has a lot of niche environments. For example, two productive environments can be replaced or merged by toxic ones, and so on.

Attitude also matters a lot too. An attitude that cares more about the internal factors instead of the external factors is of essence. However, hypocrisy is not tolerated. When I mean "care about internal factors" in essence means to always keep in mind or behind background on achieving best practices, while pushing and implementing "as much as you know now what is best practice". There is no perfect foundations in real life, after all, as I have said,  "eternal truth" is not a "complete answer key" but a direction going to infinity like in mathematics. Foundations build and grow while implementing and you will never understand the foundations enough by words as much as trying those foundations and putting them in your own context.

Conclusion

So who can be the next Synergy team? Anybody can. Sometimes it doesn't last for long. But its a priceless experience. Like the example above, it only lasted 3 days.