RioJUG: The myth of agile teams

Yesterday I attended the monthly meeting of the Rio Java User Group, here in Rio de Janeiro – Brazil. The speaker was Victor Hugo Oliveira, the IT Director of Concrete Solutions.  In his lecture “The myth of agile teams”, he talked about the enormous difficulties in working in agile teams and how to deal with the common misconceptions in order to achieve better results. What he talked about applies to any agile method and he mostly used Scrum as an example. In this post, I´m going to sum up what I learned from his talk.

He started off by quoting Ken Schwaber:

Scrum’s productivity stems from doing the right things first and doing those things very effectively

He talked about the myth of hyper-productivity that usually surrounds agile methods. Agile is being successful not because of hyper-productivity, but mainly because of the continuous and early delivery of ROI. It´s true that people usually get more motivated to work with more lightweight and effective methodogies than more heavy and rigid processes. This boost of motivation often implies an accompanying increase in productivity. But that´s not the main goal in the first place, so avoid unrealistic promises of productivity when it comes to agile methods.

He then goes on to speak about some of the myths and issues regarding teamwork:

• harmony vs. creation: harmony = success ? Not necessarily, creative teams need some conflicts.
• more people = more productivity: the project needs to have a manageable number of connections (points of communication between people), this is a quadratic function (he also mentioned the Ringelmann Effect)  Usually, it´s good trying to follow the 1-digit rule, that is, teams with up to 9 people (if the project demands larger teams, it´s necessary to break down the project into smaller cohesive subprojects). Worse comes to worst, as states Brook´s law, “adding manpower to a late software project makes it later”.
• stagnate vs. stabilize: people don´t stop evolving because they are in the same team for a long time. Actually, working in teams for a long time can significantly contribute to increase productivity because of the high team integration. Stagnation has to do with other things, like lack of challenges, for example.
• unpredictability of emergent behavior: a group of people is not the same as a team. Teams need to be looked after. Having a bunch of people with no coordination, expectations and limits is a recipe for disaster. More importantly, a true team needs to have a common goal, a glue that sticks people together. Examples of common goals may include things like project, ROI, risk, the product backlog (Scrum), and so forth. A team can only be defined as self-managed as long as it works with a common goal.
• project needs: what is necessary for a project to be successful? team capacitation! this is quite obvious, but always important to be recalled: the team members need to have the necessary skills to work in the project (ex.: architecture, development, business knowledge, tests, GUIs, etc.). That´s a reason why one of the pillars of Scrum is multi-disciplinary teams.
• size of the challenge:  no challenge leads to complacency, too big challenges lead to discouragement. Choose the right-sized challenge for your team!
• work structure and institutional support: that means a good environment, transparency in the rules, well-defined teams and tasks. Companies should give support so that people can work well together (not necessarily without any conflicts). Teams are a unit both in success and in failure.

The speaker concluded his talk by saying that a project shoud have:

• clients with well-ajusted expectations;
• managers with team support;
• prepared and available coaches;
• a conscious team;
• an aligned institution.

He again mentioned Ken Schwaber by saying that Scrum works primarily at the level of the team and Scrum can also be considered a kind of social engineering, which fosters cooperation.

Testability: How much logic belongs in the constructor?

The other day my colleague and I were pair-programming and we came across a dilemma regarding the design of a class which was responsible to load the configuration properties of our application. The class looked like the following (a little oversimplified):

class ApplicationConfig {

private Connection connection;

public ApplicationConfig(String connectionUrl, String driver) {
 try {
 Class.forName(driver);
 this.connection = DriverManager.getConnection(connectionUrl);
 } catch (ClassNotFoundException e) {
 throw new IllegalArgumentException("Problems while loading JDBC Driver.", e);
 } catch (SQLException e) {
 throw new IllegalArgumentException("Problems while creating JDBC Connection.", e);
 }
 }

public Connection getConnection() {
 return connection;
 }
 }

In order to achieve better testability by minimizing side-effects, it´s highly recommended to strive for simple constructors that do nothing other than making simple assignments to fields. As Misko Hevery comments on his Guide for Writing Testable Code, constructors should do no real work. Mark Needham, in turn, advocates the simplification of constructors by delaying calculations. He points out the idea of reducing field calculation in the constructor, only calculating those values when they´re actually needed, which generally is a while after the object has been constructed.

Following this advice, we moved the creation of the connection to the getConnection() method, which led us to the following:

class ApplicationConfig {

private String connectionUrl;

private String driver;

public ApplicationConfig(String connectionUrl, String driver) {
 this.connectionUrl = connectionUrl;
 this.driver = driver;
 }

public Connection getConnection() {
 try {
 Class.forName(driver);
 return DriverManager.getConnection(connectionUrl);
 } catch (ClassNotFoundException e) {
 throw new ConfigException("Problems while loading JDBC Driver.", e);
 } catch (SQLException e) {
 throw new ConfigException("Problems while creating JDBC Connection.", e);
 }
 }
 }

OK, now we have a simple constructor. However, the problem with this design is that we will only be able to check if the connection arguments are truly valid in the getConnection() method, which is too later after the object is constructed (you can also notice the different exceptions that are used). The previous design allowed us to signal the problem as soon as possible (fail-fast), which helps to improve bug tracking.

So the issue is whether we should favor the fail-fast rule or the testability. We opted for the latter since this configuration code is pretty much under our control, that is, the risk of passing invalid arguments to the constructor is low.

Just as an aside: we could eliminate the problem altogether by injecting the connection into the ApplicationConfig class, but the point of having the ApplicationConfig class in the first place was that it could be easily reused in other places, removing the duplication of the boilerplate code. The purpose of the class is to be a utility class to load configurations, so we found it reasonable for it to have the responsibility to instantiate a connection.

I´d appreciate comments and suggestions on how to address this issue.

“Gate pushers”

Last Saturday I took part in the Anniversary Conference of my church. Pastor Tim Bagwell talked about how we can use our faith to “push on the gates” that hinder our lives from achieving everything God has for us. I´ll try to summarize what I learned from this great message.

Jesus said: “…on this rock I will build my church, and the gates of Hades will not overcome it.”  (Matthew 16:18)

I learned five keys  to be an effective “gate pusher”: remember, rejoice, renew, focus and react.

Remember

“Praise the LORD, O my soul,
and forget not all his benefits.” (Psalm 103:2, emphasis mine)

The psalmist is reminding himself of all the blessings the Lord has already bestowed on him. Unfortunately, we, as humans, tend to remember our pains and failures and forget our blessings. We’re ready to remember the calamities of life: bad things people did or said to us, slander, misfortunes and tragedies; and we’re late to remember how good God has been to us, how He has poured out His abundant blessings upon us, be it a family, a good job, a lovely friend, a tender mother. What’s more, God gave his only Son to die for us so that we could have eternal life! That’s some blessing, isn´t it?! Therefore, let’s have a greatful heart and do like the psalmist by never forgetting all his benefits.

Rejoice

“Praise the LORD, O my soul;
all my inmost being, praise his holy name.”

“Praise the LORD, O my soul,
and forget not all his benefits.”  (Psalm 103:1,2, emphasis mine)

The second key to being a gate pusher is to rejoice. The psalmist was not only remembering all the benefits the Lord had brought to him, but he was rejoicing over them, he was praising God. We need to rejoice and offer God the sacrifice of praise, regardless of the circumstances. This is so important that the Apostle Paul stated it emphatically: ^“Rejoice in the Lord always. I will say it again: Rejoice!” (Philippians 4:4)

Renew

“…who satisfies your desires with good things
so that your youth is renewed like the eagle’s. ” (Psalm 103:5, emphasis mine)

In our Christian walk, there will be times when we will feel worn out. That´s why it is so important to be constantly renewed by God. We have already learned one of the secrets to be renewed, it´s the equation: Remember + Rejoice = Renew. Think a minute about this! When we remeber what God has already done in our lives and we rejoice and praise him for that,  we are renewed by the Holy Spirit, like the eagle, because we recall that He is able to do anything.

Focus

“Let your eyes look straight ahead,
fix your gaze directly before you.” (Proverbs 4:25)

Gate pushers look ahead. They know God has great things in store and that God´s best is yet to come. There´s no more time left to look behind, being accused by the past (my pastor always says the following: “if the enemy shows you your past, then you should show him his future.”). There’s no time to look to the left nor to the right and be distracted from the goal.

React

“Do not merely listen to the word, and so deceive yourselves. Do what it says.” (James 1:22)

“In the same way, faith by itself, if it is not accompanied by action, is dead.” (James 2:17)

There´s no point in learning all these keys, enjoying them, but not putting them into practice. We need to correspond to the Word of God, being a real practitioner.

I finish this post with a sentence the pastor said at the conference that really spoke to my heart :

“Faith is a natural reaction to a supernatural word.”

Are you willing to be a gate pusher? I am.

Book Review: My Job Went to India

I´ve just finished reading “My Job Went to India”, by Chad Fowler. The book contains 52 tips on how to be a better professional on the field of software development. I highly recommend the book for every developer who cares about his job. It´s a perfect complement for the already classical “The Pragmatic Programmer”.

The author goes over a variety of topics on how to proactively manage  a career on software development. He uses several metaphors and examples taken from his experience on offshoring in India.

 The book is split into six parts, namely: 1 – Choosing your market, 2 – Investing in your product, 3 – Executing, 4 – Marketing, 5 – Maitaining your edge, 6 – If you can´t beat´em. I´ll talk a little about three of some of the great insights from the book.

1) Supply and Demand – “Exploit market imbalances”: The author applies the well-known Supply-and-demand phenomenon to our careers. The idea is that the higher the demand for programmers that know a specific technology (say Java) the lesser will be the average price paid to these programmers. On the other hand, the demand for other non-mainstream technologies, though small, usually generates higher paid jobs since there are few skilled people able to supply that demand. Exploring these technologies may increase the chances of one getting a more well-paid job.

2) Be both a Generalist and a Specialist: This issue has generated a lot of debates and we can find several articles and blogs discussing it. The book advises us to be both generalists and specialists. “Generalists are rare, and therefore, precious”, besides that, our skills should not be attached to any specific technology platform. Nevertheless, we should strive to be specialists in the tools we use on a daily basis. The author comments that specializing in something does not mean not knowing about other things!

3) Mentorship: We all know people that are more experienced than us in our field. The advice is to find a person among those people to be our mentor. A mentor is someone who we can trust and that will provide advice on real issues that appear on our careers. The other facet of mentorship is to be a mentor. The author points out that for us to find out if we really know something, we should try to teach it to someone else. The concept of learning through teaching is a key to better understand if one really knows about whatever he claims to know. By the way, maintaining a blog on some subject is a great way to do this!

There are many other awesome pieces of advice in the book  concerning time-management, self-marketing and remarkability.

After every tip, the author usually gives some practical “homework” for the reader to act on what was just read. A great way to move from passive to active reading.  The title of the book is quite misleading, since it´s not a book with a focus on offshoring (although the author uses his offshoring experience to illustrate some points).  The publisher recognized that and came up with a new edition for the book, which is now called “The Passionate Programmer: Creating a remarkable career in Software Development.” 

A great career in Software Development (and indeed in any field) does not happen by chance.  We need to be consciously putting effort to develop and improve our skills in order to be excellent in our craft.

“Do you see a man skilled in his work?
       He will serve before kings;
       he will not serve before obscure men.” (Proverbs 22:29)