This article is not going to give you a "golden path" or howto towards effective software development. It is not specific to a project management-framework or team size. Rather, it aims to inspire decisions made during development.
Web development started as my hobby around age 13, in the early days of the modern web. Just messing around on my own, without any best-practices or principles. Good old PHP5, HTML table layouts and Photoshop.
Working like this was quick because I was in charge of all disciplines. Needless to say, the execution was not professional and I had a lot to learn to get to the level I am at now.
When I started studying Software Engineering, I had to accept the fact that my favourite hobby would turn into my career.
What used to be playful, turned into something disciplined. I liked this change, as it made me feel useful and gave me an insight into what my career would look like. It was however very difficult to deal with, it took me years to be able to collaborate properly, I was stubborn and I thought that my knowledge was already sufficient.
A lot has been said about Education in IT and whether it is needed or not. I think education can be useful as it creates a certain mindset within you, it gives you a framework on how to learn and communicate in a team, a framework that embraces openness and removes stubbornness, a framework that accepts your fellows as equal experts.
I've learned that for some people this skill is natural and they benefit less from education than most. I've also learned that some people will never truly grasp it.
In the end, it's all about your mindset.
We've figured out that bridging disciplines requires a certain mindset. But how do we deploy it?
A word on attitudes and feedback
You're an expert, but so is everyone on your team! The goal should lead, not you. Pollute your mindset with pride and you will fail. Feedback will improve your work. Be open to your colleagues about this and try to make time for their feedback. Make them feel welcome and understood.
Working together across different disciplines
As a designer, it might be tempting to design a complete project and then hand it on to the developers. This, however, does not work. The final product will only work if all components work together.
As humans, we tend to overestimate our abilities. The biggest skill in bridging disciplines is knowing where your expertise ends. Knowing when you need someone else that is specialized in a certain field.
You're no superhero
When working in a team you might get emotionally attached to your work. This means that you're going to have at least some trouble with delegating parts of it.
Giving away work is part of working collaborating effectively. Realize who's the expert in a certain discipline and also realize how much you can get done personally. There are limited hours in a working day and specialized colleagues might just be able to do certain work better and quicker.
Wikipedia: Impostor syndrome is a psychological pattern in which one doubts one's accomplishments and has a persistent internalized fear of being exposed as a "fraud". Despite external evidence of their competence, those experiencing this phenomenon remain convinced that they are frauds, and do not deserve all they have achieved.
This is something that I somewhat struggle with personally. I am terrible in giving myself a "grade" or accepting my work as good. I used to throw away a lot of good concepts during my early days of software development, not factoring in that I was still learning. Even writing this article, I doubt if I should publish it.
What's important to realize is that, as humans, we're constantly learning and developing. There is no absolute measure of "good" or "bad", it all depends on the context. In projects, you will be surrounded by people that are considered experts in their field, accept this fact and figure out which of your skills can help. You're good at whatever you can contribute.
...Sometimes, you just have to go for it. Mess up and learn a new skill. Or, even better. Find out that it's not your thing and do something that you enjoy more. No shame.
It can be hard to sense how good you are at something and how quick you can get it done properly. That's why it's important to accept feedback and let colleagues make estimates for their work. This, however, doesn't happen naturally. You have to plan it.
Getting together should be part of your project's planning. It is a good practice to have recurring discipline-wide appointments as so you don't lose track of each other. Discuss with your team how often would be effective. Some project management frameworks (such as agile) already take care of this.
During these appointments, members of all disciplines should review each other's work. For instance, A developer could easily get something wrong from the requirements It would be a shame if that's found out very late in the development process. Product-owners, testers, designers, developers, you name it... can inform each other of mistakes or misconceptions earlier. This reduces work in the form of bugs, redesigns and redefining requirements.
Time should also be made for deciding who is going to do what. For instance: there might be some overlap between front-end and back-end work. Let everyone make estimates for their work so that the deadlines and responsibilities are clearer, and perhaps avoid a fight or two...
Recently the company that I work at (C-quential) introduced 'themed weeks'. A chunk of the company sets up a project for a week, bringing together all disciplines to quickly get something done.
At the end of the week, more is developed in less time. All disciplines are seated together and focused on one specific goal. Working like this reduces an enormous amount of overhead, allows colleagues to get to know each other better and creates a more harmonious working environment.
I highly recommend experimenting with how you get together as a team, figure out what works and what doesn't. Tip: mix in some fun activities to convince people to work with your new idea.
“Intrinsic motivation is a vital currency for an organization’s survival and success” (Low & Robertson, 2006).
Don't forget to celebrate, remind your colleagues and yourself why you embarked on the journey and what it results to. Even if the project isn't as successful as you're hoping. You can't let your team down.
Plan some activities throughout the project, your team will be more productive when morale is up.
I hope this article provided some new information. For any questions, you can leave a comment below or reach me on my website here.