Posts Tagged ‘building teams’

Java and Tapioca


Past Saturday (2009-09-19), I was fortunate to speak at the Café com Tapioca.
This year, the event was celebrating 7 years of the CEJUG, Java User Group from Ceará. One of the most active tech groups in Brasil. Those guys did a great job organizing the event.
It was a sunny day, but instead of going to the beach, many people attended the many lectures of the day. In this post I’ll comment on each of them.
Roughly translated to English (all lectures were done in Portuguese), the lectures were:

“The path of productivity for web developers” by Bruno Pereira – Concrete Solutions.

Bruno knows what he is talking about in this presentation. The path for web development is far from clear at this moment and developers need to open their minds now, and explore different possibilities and technologies.
Firebug is definitely a divisor of waters in web development.
The format of the presentation was not very interactive, but I think it would be very hard to show code and be more interactive with so many technologies being addressed. The topic is plenty for a full day on itself just to get you started.

“How to build a JEE/JME application for the 4 corners of the world.” by Régis Melo – Sagarana.

Régis presented his company and main product to the audience. I thought it was interesting to see that the travelling salesman problem can still be sold as a product, and that ILOG has not completely dominated this market.
He also spoke about some of the challenges of exporting software he faced, some similar to what we see here at the company. Brasil’s potential for software is really underestimated.
If we were to set our minds to it, I think India would be in a bad position to compete with us. The similar timezone to the US certainly helps.

“The myth of the agile teams” by Victor Oliveira – Concrete Solutions.

My presentation, below, would perhaps be best enjoyed by managers, and I think maybe not the best presentation for the public present. The local crowd at FA7 was younger, and mostly team members.
The goal was to create knowledge that supporting teamwork needs hard work too. Organizations have to think seriously on what is necessary to nurture teams and make them better and real teams.

“10 bad habits of JSF developers” by Tarso Bessa and Rafael Pontes – Triad Works

This presentation was very technical and really for people that know, and like JSF. Of course, as Bruno’s presentation pointed out, JSF itself is kind of a disappointment. I remember when Microsoft released .NET that JSF was going to be a huge blow in favor of Java technologies for web development. That was around 9 or 8 years ago.
Many years later, the path is unclear with many independent frameworks fighting for space. (Ruby, Rails, Grails, Django, etc) What is certain is that JSF is a good productivity framework, but has a very limited space for its application. After Oracle’s purchase of Sun, JSF’s future looks gray.

“Improving your application with Lucene: get to know Solr and Hibernate Search” by Paulo Jeveaux – Giran

Jeveaux’s presentation was of one of my favorite open source tools in the market. Back in 2004 when I first worked with it I was already impressed, and the evolution with Solr and Hibernate Search only adds to the package.
If you know nothing about Lucene, it is worth your time.

“What killed RUP can kill Agile” by Rodrigo Yoshima – Aspercom

Having worked with RUP for around 7 years, I know how RUP was misinterpreted, especially during the 90’s in Brasil.
The topic presented is important, very important for any software maker that is interested in being better at it. The possible fall of the Agile movement due to it’s misuse or misinterpretation is a clear and present danger. Something I also addressed in my own presentation considering the team aspect of it.
I do think, however, that the separation between just being pragmatic or conservative does not address the change of view that happened once the Takeuchi and Nonaka’s article was in place. In my view, the “theoretical view” from a process control perspective changed the way we viewed what happened before.
Of course, 50 minutes needs a pragmatic approach:-), and the presentation had a good sweet spot.

“Desmystifying TDD in Practice” by Paulo Silveira – Caelum

Silveira’s nervous style of presenting is very engaging and was my favorite presentation. Using a simple TDD example with very simple business rules (stock market) got people eager to participate. It was certainly interactive and fun.
I love TDD ever since I used it for the very first time a couple of years ago. People who have not tried it, really tried it, don’t know what they are missing.

Building a Team (part I of endless)


One of the first tasks of someone that wants to build a good team is understanding a little bit about what makes a team successful elsewhere.

Also, while observing, there must be a conscious knowledge that a strong correlation may not mean a relationship of causality.

A small team is a factor seen in most successful teams. Teams with 9 members or less seem to be in general more successful than larger teams. The team size has a strong relationship with a good team.

The real cause for this lays in the easiness to manage the communication between the individuals. As the size increases, it is increasingly difficult to manage a good link with the other team members.

To have good communication within the team, it is very important that the members of the team know who is in the team and who is out.

This is related directly with the concept of pigs and chickens seen in Scrum. The pigs are the committed team members. They are onboard with the team. The chickens may help, but they are not in.

The pigs need to know who the pigs are, and the chickens need to know who they are. It may seem silly, but the lack of clear delimitation of these boundaries for the team will do more harm than any perceived good.

People on the team should form a real team. They should want to be on the team, and they need a common goal.

This goal is going to be the glue that will get the team moving together. Without it, the team members will show a natural tendency to follow their own paths. And if everyone just follows their own interests, there is no teamwork possible.

To achieve a common goal, there are many paths. To common goal can come from a leader, from the team itself, from an outside element, etc. What is most important is that pushing to set a common goal is a difficult job.

Setting goals demand taking responsibility. And taking responsibility can be a risky action and demands emotional involvement.

To be continued…

The Myth of the Team


The concept of teams is one that is widespread viewed as good and taught by parents and in the schools from the very early days of almost every child.

There are many reasons for this culture that have nothing to do with how much better teams work when compared to individual efforts. It is all about getting the young to learn the concept of the other, how to live with the differences, and how to deal with dysfunction and conflict.

A single person can be productive, and also, can have many problems. Putting a group of people together also mean that the possibility for problems is multiplied.

In general, teams will find a stable situation, they naturally seek equilibrium in the relationship of its members in a way they can manage to live together. This means avoiding conflict at almost all costs. People will try to find a comfort zone, even without thinking about it.

The big problem here is that the continuous generation of conflict and resolution is what makes a team more productive than individuals.

Also, conflict is dangerous because it can break the bonds that keep the teams together. Too much conflict destroys the team, too little and the team will produce nothing good.

The team dynamics reminds me of a history book by renowned Helio Jaguaribe (Um estudo critico da História). In this book, he demonstrates by looking at the many different failed and successful societies in history that one of the major factors of success is the good challenge. If the challenge is too great, society is destroyed. If the challenge is too little, society will fall into a comfort zone that stops it in time and will render it unprepared to deal with future difficulties.

The teams are a micro cosmos of society, and like societies, a team needs a good challenge and good conflict to thrive.

The goods of teamwork are not given. It is not by simply putting people together that they will be better together than they are in the sum of their individual efforts.

To find good teams, one will see that there is always a factor that “rocks the boat” when conformance rises, and something to bring a gentle breeze when people are about to kill each other.

To purposely build a successful team is even harder than “finding them in nature”. It is not a task to be underestimated.

Continued here…