10 team building tips

1) Good Morning

When you enter in the office, before sitting on your desk, smile and say good morning to the team. Yes, E V E R Y day.

2) Listen when someone is talking to you.

When a team member is talking to you, look him in the eyes and show interest in what he is saying.

3) Give space, build trust

Let team member fail sometimes and repair from their failures.
You may be always right, but who cares?! Other people need to learn to fail and take responsibilities.

4) Connect

Go and take a coffee with each person in the team separately.

5) Congratulate

When someone does something good, tell her/him!

6) Keep your personal problems out of work.

 

Don't shout at people because your last evening was bad.

7) Do pair programming

Great way to share knowledge and build solid work relationships.

8)  Feedback

Do code reviews without sounding the king of the programming universe. Explain in a calm and friendly tone whatever you want to say.

9) Have lunch together

If possible go regularly to lunch with as many team members as possible.

10) See you tomorrow

When you leave in the evening, if you are not the last person in the team left, say goodbye.

Tridimensional developers

Working in the industry for a while, I noticed different behaviors between developers.

These differences are mostly related to their personalities, their team spirit and finally their entrepreneurship skills.

I identified 3 types or better 3 dimensions in which I can fit all the people I work and worked with.
Before starting and describing these dimensions, I just want to point out couple of important things.

1. This has nothing to do with how good you are with the code or design or testing. You can be the best kickass-bruce-lee-coder, but still entering in the mono-dimensional category.
2. This has also nothing to do with your level of seniority, I saw Juniors that can perfectly fit in the tridimensional category and team leaders falling in the mono-dimensional one. 
3. This is perfectly applicable to ANY workplace and ANY type of job and ANY industry.
4. It is just my point of view in a boring Friday afternoon.

So lets start :)

Mono-Dimensional Developer

You work daily at your stories/tasks

You participate to meetings about process and technologies

You communicate with other team members about status
updates, risks and issues encountered

You create and/or maintain software applications 

You keep updated yourself about emerging technologies and trends

Bidimensional Developer 

You cover the Mono-dimensional points

You help team members without being asked directly

You share with your team what you learned using slides/blogs/etc.

You actively participate to process and technology meetings, asking questions and/or proposing solutions.

Tridimensional Developer

You cover the Bidimensional points

You create, propose and promote new processes and technologies

You take team building actions when needed without being asked directly

You actively participate to meetings other than process and technology

You create blogs/wikis/etc in order to facilitate communication without being asked directly

You see opportunities everywhere and you act on them.

So which developer are you?

Happy customer cocktail recipe

Ingredients 

Recipe 

1 - Take a bit of Kanaban, Scrum retrospectives, XP practices and mix well.

2 - Setup your board. ( You will need an electronic board, so choose between  JIRA agile , Versionone , Leankit , etc. Remember, it's not about how big it is, but how you use it ).

3 - Setup Jenkins. You will need to build the following pipelines : 

The following to run after every commit.

Continuous build job : this is triggered every time there is a commit. It runs unit and acceptance tests against trunk.

Sonar job : If the above passed, then  it's time to check the quality of the code committed. You can use sonar and the sonar plugin for Jenkins.

The following to run every night, each depends on the success of the previous.

Continuous build job : yes again, no point in running the following if this fails.

Release job : this creates a production release (maven release or whatever is your company policy about releases) out of your trunk(svn)/master(git) branch.

Deploy to dev job : This job automatically deploys to dev environments.

Dev System tests job : This will trigger your integration tests against dev environments.

Deploy to perf job : This job automatically deploys to performance environments.

Performance tests job : This run your JMeter tests against perf using the permormance jenkins plugin.

4 - Each business story will need to follow this process :

Pair : If the story is not trivial, do pair programming. It will speedup development and it will reduce dramatically the number of bugs.

Distill the story :  Sit with your pair, QA and the Product Owner and write down all the acceptance criteria. Ask questions here and try to cover all possible scenario.  

ATDD : Write acceptance tests first. It will not compile at first because you do not have any implementation, so write the interfaces that you need in order to make the project to compile. Run the test, it will still fail. 

TDD : Now write the test for the most external part of your code. (implement leaves first). Run the test. Implement the code to make the test pass. Test more. Implement more. Continue until the story is fully tested and implemented.

ATDD : Re run your existing acceptance tests. They should pass now.

Review : Submit the code for review. Once the code has been reviewed you can commit.

Sonar : wait for Sonar to tell you how good you and your pair are.

5 - After the Jenkins nightly pipeline is successful completed, the QA team can pick up the Release and they can deploy to their QA environment. QA will run manual, automate and exploratory tests and if bugs have been found, developers need to act immediately. 

6 - When QAs do not find bugs, the release can be deployed into UAT where the Product owners can verify and accept the stories.

7 - Once POs are happy, Ops team can deploy to Preprod in order to test the deployment scripts and the deployment instructions.

8 - Ops can deploy the release in production.

  

Happy customers can celebrate now.

 

Why you should not work extra hours

There are pros and cons in working extra hours or over time regularly, here is an attempt to list them all. Some are well known, some are taken from my experience, if you know other reasons just comment and I'll include them in the list.

CONS:

You are going to introduce bugs 

Human concentration does not last for long time, and it decreases drastically if your brain doesn't rest properly.
We are already introducing bugs when we are extremely focused and well rested in the morning, so it's easy to imagine the disaster that can happen at 10PM.
8 hours of mental work a day is more than enough for your brain.




Your changes cannot be promptly reviewed 

Code reviews is an extremely powerful tool that is widely used by team in order to control code quality. It works perfectly when reviews are done immediately and you can talk face to face with your team members. It works well when it's done using tools like Gerrit, Reviewboard and so on. It works bad if every morning there are tons of lines of code to review because of nightly or extra hours commits.






Stories team estimation goes wild

One of the most painful part of any agile team is the stories estimation (less in Kanban, more in Scrum). It is painful, stressful, long and it is tiring for all the participants. Estimations are based on stories complexity and time. The time is the 8 hours per 5 days a week. Now, all this estimation gets distorted and so useless when team members regularly work extra hours. Team will get frustrated.


You can create tension between team members

One thing I noticed in teams where some members work over time, is the presence of hostilities and tension. Why is that? People that follow regular work hours can be worried about their career being compromised because they do not stay longer in the office. People who work late can see the others as non involved/interested enough on the job. Solution? simple, stick on regular hours.




You create wrong expectations

Everyone knows, you give a hand and they want your arm. You work regularly over time and your manager will start soon to expect and to count on you to stay late.






You lose a great part of your life

Yep.

PROS:

When do you think a daily stand up is too crowded?

Recently, looking at the daily stand-ups in my company, it makes me smile a bit.

I think too many = chaos and dispersion. 
Proper and efficient stand-ups should be 4 pigs and occasionally 2 or 3 chickens. 

This is my opinion, what is yours?

Review Check box

One good and necessary practice when developing software is the code review.

Code review it's an excellent process to reduce bugs in the code and to raise up the quality of the software you are working on.

Basically, it means that before committing your changes to the repository, you ask to another developer to look at your code and see if everything looks fine.

But what is everything?

Well, this can vary between companies standards, but the following can be a good starting point:

OVERALL DESIGN (Is the current design the best design (i.e. is it scalable, maintainable, Are the algorithms following the best practise in order to have the best performances? etc.)
FUNCTIONALITY (Does the code do what is supposed to do? Are we covering all the possible cases?)
CODE READABILITY (Is the code EASY to understand? etc.)
UNIT TEST    (Are the tests covering all possible scenarios? Are the tests reusable? If the developed code does not have 100% code coverage, why not?)
ACCEPTANCE CRITERIA     (What are the Acceptance Criteria, and if the criteria haven't been expressed as an automated test, why not?)
ERROR HANDLING (Do we really need checked exceptions? etc.)
WARNING    (Are the eclipse/intellij warnings acceptable?)
LOG       (Is the log useful in order to find issue? Is the log communicating what is necessary? Etc.)

Print this list and stick it in each developer desk. It will help during the review process.

Fluent mirror methods

How important is the readability of the code you write?

I think very important, probably one of the key to success in delivering good working and maintainable software.

This article is about a simple technique to help you and the people working on your code to fast understand what's happening.

I called this technique fluent mirror methods, and usually I wrap all these kind of methods in a single class called Dictionary. 

A fluent mirror method is a simple static method returning the same object passed. For example:

public static <T> T executing(T type) {
                return type;
        }

You can use these methods as follows:

import static org.grep4j.core.Grep4j.grep; 

import static org.grep4j.core.fluent.Dictionary.on;
import static org.grep4j.core.fluent.Dictionary.executing;
import static org.grep4j.core.fluent.Dictionary.expression;
import static org.grep4j.core.fluent.Dictionary.with;
...

assertThat(executing(grep(with(expression("Marco")), on(profile))).totalLines(), is(1));