We often hear about great organization with multiple teams, where everyone can talk to everyone else and every piece of information is accessible. We can hear about pair programing, code review, CI or CD.
Yeah, all of this seems so great, but this is happening in other companies. What about my team ? How can I use all of this for our project ? And men, what the hell is a CI ?
I was employed in a startup two years ago, where each task has to be delivered immediately, and every thing was urgent. How can you put all those great tools without any time allocated to it ?
It won't be easy, it won't be cheap, but we can work this out, find solutions, and transform ANY team to achive more.
For that, I'll take a little analogy, please think about your team as a role playing game character. This character will increase its power through different level, and we starting with a level 0, before our game can begin.
Level 0 : Create your team
This first level is more like creating your character, you know, before you start your Donjon & Dragon campaign, you have to create your character and assign some skill points. This is the same with your team.
Most team I met in my life weren't really ones: this is not just several lads hanging arround and sharing a manager. Team defines themselve by interractions, and it implies to create connections between people.
Those connections will create unexpected behaviour, team member won't work for a manager, but they will for the sake of the team.
To achieve that, treat your team like a person, give it a name to refer to it.
Then, you can give it responsabilities. Your team needs to embrace the project, it needs to know exactly the goal behind each actions.
With this new person, you won't assign a task to a specific person, give it to the whole team and let all members decide who will do the actual job. If someone gives you a task, talk with the entire team before doing anything.
When you put that together, your people will start to work as a team, together, to solve global problems that makes sense. But it's not enough, you need a second person: a neutral judge
Because several peoples working together will generate conflict, you need someone or something to help them decide what to do. If you give this role to a human, that'll just be another manager... let's try something different: Give this to automation tools.
- Code quality : Use eslint and ask the team to define rules
- Code review : Use Pull request and ask the team to chose a way to review each one of them
- Documentation : Decide to write a README.md and let the team complete it
Once you put all of this in place, you have a team, a strong base to build something great !
Level 1 : Train your neutral judge
But hey ! your neutral judge is not a person... it's not a single thing either, it's just a bunch of tools !!
Yes, but we can work this out, by giving it a personality. You can call it Jarvis like Iron Man, Skynet like Terminators or HAL if you want. In the reste of this article, we will call it Timmy.
Timmy won't be define as a single thing, your team know that because it's your team that took Timmy in place.
And Timmy is not really smart, but he is rigorous and impartial. So let's ask him to do more stuff. Try to make him install your product for example.
You'll see, it's not the simplest task in the world. And when you successfully see your product run by Timmy, you know that every new team member will succeed too, because, hopefully, this new team member will be smarter that Timmy.
You can, afterwards, define testing on your product, cause you'll have a standard plateform and launch procedure to launch tests.
The goal behind all of this might be difficult to see: by default, humans evolved with an individual mindset. People in your team will try to get credit for themselves, they'll try to implement their idea even if they were proven wrong.
By giving all of the validation stuff to Timmy, team members won't be able to tell things like « it worked on my laptop », they'll colaborate to have Timmy's approbations for the work. All team members are equal with accptance criteria.
Just take a moment to think about first two levels. If you follow this, you'll have a real team, and a real process to change an idea into code and then commit that code into the product.
Normally, following this two levels will create another unexpected behaviour, but a good one : A culture !
Your team will developped their own private jokes, history and legend. They also have a mascott with Timmy.
Don't try to implement all of it in one day, it won't work. Let the team, as a person, integrate the whole thing. And most important, when adding a new rule or item to your team, get feedback, don't force them.
You have now the foundations of the greatest team you ever had. You can pass to the level 2.
Level 2 : Team automation
Try now to focus on what's important for your team. If you try to automate anything because it'll save you time, it's not the good approach.
Automation is the next level for you neutral judge. It'll help your team to make less errors. Timmy is not the smartest of your team member, but it won't make mistake, remember he is not human.
From now on, Timmy will tell you if your tests pass, or not. He will reject or approved new pull request. Timmy can update your documentation alone or send email to your customers, just ask him.
This level is quite hard, cause for everything you want to automate, you need a human of your team to take time on this automation. And sometimes, managers won't agree to let you do that.
Automation will save time to your team only once it is in place. It will be difficult to sell non-feature thing to your executives.
If you reach this level with your team, you have a pretty good place to work. A team with its own culture, some neutral testing and building platforme. Clear README files to newcommers. Now is the time to make your team a success you can talk about to other company.
Level 3 : CI/CD : Continuous Whatever
The normal workflow of developement is the following
- Step 1 : Idea
- Step 2 : Transform your idea into code
- Step 3 : Let Timmy tests that code, if it's not working, back to step 2
- Step 4 : Let Timmy integrate the code to the product (fallback to step 2)
- Step 5 : Let Timmy deploy your code
- Step 6 : Let Timmy get feedback from customers
And as you can see, Timmy will do most of the work, human team member can concentrate on important human things: Getting idea and find a way to code them.
You don't need a Jenkins or Drone or any other specific tools to make your own automation, let your team decide from their needs, let them give life to Timmy
The more Timmy is developped, the less your team as to work to get from Idea to Customer feedback. The team itself will reduce the development time. And that's the ultimate goal of every Continuous integration.
Managing a team is not an easy task, every one is different, every one has its own approach to problem solving. Getting every one to work on an idea is really hard.
That's why it shouldn't be a single person job, give this to your team and look at them taking more and more responsabilies as weeks goes by.
As your team is getting stronger, member will get closer and good thing will spontaneously shows up ! Trust your team ! They are good, they are working hard too !