Management at your startup by working as a team

In Blog by Insalgo

Without proper management, there will be no improvements in how your company works. As long as you will just keep moving forward without any insight, you will lose time on things that could be done much faster and more efficiently. In these blog posts, we would like to share our experience with management at the IT startup. You can also read related articles about task management and communication in a team.

This part is probably the most significant. Here you will find a few words about worksharing and how software helps with keeping everything in tact. This text will be easier to understand if you are already familiar with described tools: BitbucketSourceTree. Short description of how they work we present below.

Tools

IT Teams are created by software engineers, graphic designers, project managers, testers, script writers and scrum masters all working together. Very often there is a need to share your work with someone else to move forward faster or present progress to the client. What you share and what you give access to is as important as how you do it. Old times when the whole team was using one USB HDD are long gone, and there are now tools that are much better than those:

  • Versioning tools.
  • On-line documents creator.
  • File sharing across network.

Versioning

Scenario:

HR: Do you know how to use any versioning system?

Like a nightmare, this question is so often a problem for startups starting cooperation with new devs. No experience with versioning makes everyday work very difficult – it had happened not only once that company lost some valuable data and had to recover them after someone had a problem with merging repositories. If lost lines of code and features that were finished and suddenly disappeared are normal for you, it’s the highest time to get it done and prevent those events from happening ever again.

 

If at your startup you don’t use any versioning system – just stop reading right now and hire a new CTO

It sounds like something really important, but what exactly does the versioningmean? In short you can tell that it is a way to save changes made in files with easy access to this list. You sign up your work with an event called commit. The work or fragment of work was finished, so you commit it and send to the remote repository. Then, other people could see what you have done, could integrate your work with theirs or even could say what they don’t like about your code and reject changes.

Commits are a sign described by a message. It is like you would say Look, something has changed. It could be a nice source of information. Commit messages should always be clear and descriptive about new changes that have been made. Always write your commit messages the way that let you read them at loud. It works when Project Manager asks you on another scrum meeting What have you done yesterday?. There would be no additional questions about your work.

Lack of knowledge about versioning could be a great burden for every team of developers. And this is not only a rookie’s problem. Be prepared to recruit an experienced old school developer from respected, well-known corporation to save your project, as somehow he/she is the only response to the maintenance of your codebase. Now, at the first day of his work, imagine him sitting in front of the computer at your company and opening Git tutorial, saying:

Old school developer: There was no need to use git at my previous work.

We don’t judge. Hopefully, versioning tools have a steep learning curve – anyone can learn it in a reasonable time.

Here is the quick summary why versioning matters:

  • It keeps track of changes
  • Provides you with automatic backups
  • Project will be easier to share with new teammates
  • Easier to maintain as everyone has access to code all the time
  • Simple quality control, because you can easily compare and reject elements

Before the era of decentralized versioning, there were dark times when all the files were kept on one central server. Since source code management systems like git, mercurial and bazaar have been introduced, we are not worried about the main server blowing up anymore.

Centralised and decentralised

We have decided that obvious solutions are the best ones – remote git repository on Bitbucket. Git because of the popularity (70k questions with git tag against 7k for mercurial on Stack Overflow) and Bitbucket because of its price (free or low-priced for small teams). There is also a git client called SourceTree, which works just perfect on Windows and Macs. In our opinion, everyone in the company, even non-programmers, will know how to use it.

Bitbucket screenshot

If your team is a brave one, don’t hesitate to teach your graphic designers basics of git. They will thank you later.

Tool for company documents, documentations, overviews, how-to’s and more

Let’s leave versioning with its problems behind and move to something else, like the way you should keep your specifications and release notes for your team. Why should you have your whole documentation online and available to everyone who works in your team? That is one of the questions that normally no one asks, but let’s explain it. Paper documentation has to be kept in the drawer, difficult to search through and to make an attempt to read it, everyone would have to borrow it from the team manager and keep it next to the computer. That sounds like a bad approach. Also, emailing all the documentation to everyone is quite annoying, what leaves us with one solution – choosing software to share your documentation by giving an access code. It sounds simple enough.

We have decided to use Confluence for the project overview. It has mathematic expressions, editable by everyone and no technical knowledge is needed to use them, lots of nice plugins, table of contents and search engine. We love documenting milestones, enlightening others about important algorithm implementation or adding step-by-step guides to our solutions. We value Confluence for its access levels. They give you an opportunity to share data with different groups at our team – team-sales, team-developers, team-for-just-this-one-project.

File sharing

Now, that you have a place for your documentation, your code is safe in the repository and you do not fear about losing anything, there is still one more thing to reconsider. Why not making your everyday work even easier, by cutting the time of waiting? It takes forever to analyze a big file in git. Web drives were created to solve such problems. Sharing graphics, photos, videos, are much simpler if something like a Dropbox could be used to do it.

If you have larger files, use Dropbox team account or some other team drive provider. Dropbox is very easy to set up, and access, you can just drop everything there and everyone can do it without writing any line of code. Git is under ongoing development and it is becoming a much better solution for big files too but it is still easier to use dropbox to share massive binary files. Try it for PSD’s, keeping older release data and test versions for your clients.

Just one thing to remember: do not mix up sharing files both in Confluence and Dropbox. Pick one – we would recommend Dropbox as it is projected for large files. Otherwise, it will be very confusing.

When quick drop-a-file is needed

Use Slack. Not only a communication device but also a simple and intuitive file drop. You just take your files and share with anyone you want. Your data are kept in Slack and can be downloaded any time later. It is as simple as that. Just check all the messages and remember, it is only for the small files. And it is quite easy to loose something in Slack, as its main function is communication, not being a file sharing system. Use it mostly to show something quickly and share your work with a larger group for review.

Workflow

We can describe you a simple workflow with Atlassian software. We start with JIRA and task planning, creating repositories on Bitbucket and adding them to our Sourcetree. Everyone is connected in Hipchat, so we easily go from planning to everyday development, which is fully described on Confluence. Our commits are listed in Hipchat, our tasks in Jira are connected to commits, so code review is as simple as it gets. It was like that until we have switched to Slack lately which became our main communicator, making us forget about all the others.