Porto Alegre Agile Weekend 2009

For the Brazilian crowd (or anyone who wants to be part of it), between the 25th and 26th of April will take place in Porto Alegre (my home town : ) ), the 2009 Agile Weekend, which has my friend Daniel Wildt as part of the organizing team.

This will be hopefully the first of many Agile conferences happening in South Brazil, and will serve to boost even more Agile adoption in the region.

Needless to say, I really wanted to go, but London is not close enough to Brazil yet…

More!

Since the advent of the industrial age, we have had a terrific word: “more.” It really worked for everything. When our roads became crowded, we built more roads. When our cities became unsafe, we hired more police officers, ordered more police cars, and built more prisons.

This is the introduction for one of the chapters of the book I’m currently reading, Information Anxiety, which talks about how to live in a world where we don’t have time to retain all the data that is thrown at us.

What I’ve found interesting about this sentence is how it can be applied in different areas, from police officers, like stated above, to software development.

It is surprising to see how many people that work in the area believe that a software project running behind schedule can be solved with a simple measure: throw more people in the team.

It is so appealing that nobody thinks it can go wrong, and they often forget to consider some minor points, like:

• time it takes for newcomers to understand the project and its domain
• time it takes for newcomers to know the people in the project
• the decrease of communication levels brought by the addition of new nodes

and more than often, the same persons that believe in this measure forget to take a look at their team in order to really try to understand the root causes of what is happening, in a totally anti-genchi-genbutsu way of solving problems.

In a recent project I’ve participated, 4 persons were added to a 3 pairs team in order to try to increase velocity the team was delivering. Needless to say that in the first week we had a 5-pair team with 4 newcomers, and if you looked at the team room, you could see that in each pair there was one person trying to explain to the other how the system worked.

It is pretty straightforward to understand that the team was in reality less than half strong, and that in the first iteration we delivered…. guess what? Half the points.

So if you are thinking about ramping up, think again, and again, and again, and spend some time just looking at how your team works before you make any decision.

Ignorance is Bliss

Throughout our lives, we study and practice the skill we find useful for an incredible amount of time, expecting to be ready when the moment comes that we have to use them.

Despite still agreeing with the practice/study paradigm, I’m starting to notice that knowing everything is not the best solution in all the situations. This thought came to my mind again when reading a recent article in the Sport magazine, about which conditions made possible to the British cycling team to win so many medals in the last Olympic Games (if you want to know more about it, you can read it here).

What caught my attention was the description of the research and development group, responsible to discover the best technologies to be used in the cycling competition. The group actually collaborates with many people outside the cycling industry, like F1 teams, and aerospace and defense companies. When asked to explain why, the head of development answered:

We really value ignorance. So we got to ask people who really know nothing about cycling. An aerodynamicist will ask: ‘Why do you do it like that?’ We’ll look at each other and say: ‘I don’t know.’ That really opens things up

This is also described by Richard S. Wurman, in his book Information Anxiety, where he describes common problems in understanding, citing the expert opinion syndrome:

We tend to believe that the more expert opinions we get, the more informed we will be. But we tend to forget that expert opinion is by no means synonymous with objective opinion. Unfortunately, most experts come with a bias that makes obtaining truly objective information almost impossible.

And when it comes to software development, this situation can be easily seen in coaching, either externally or internally. It is not rare to see coaching being done with a biased opinion, where coaches arrive with a ready-made solution that they want to apply, despite the conditions being face by the team.

Solving problems, complicated or not, has to be done with a clear mind. We have to assume our ignorance when facing any new situation, so we can understand it better and provide the best solution.

Distributed Source Control and Set-Based Design

That distributed version control systems are the current flavour of the moment, everybody already knows, so I’m not here to talk about the N reasons why you should not use svn/cvs anymore.

But what I hadn’t notice until recently is that git (or any other DVCS) actually allow you to do one very important thing in software development: set-based design

As Mary Poppendieck pointed out:

Toyota and 3M use the same concept for product design.  They explore the entire solution space and find intersections that everyone finds acceptable, gradually adding detail and converging on a solution.  This approach is called set-based design, and contrasts sharply with point-based designs which start with a single solution that undergoes a series of optimizations.  In most cases, set-based design produces the best design in the shortest amount of time with the least amount of communication.  It’s strange that this principle, so obvious when you are scheduling meetings, seems counterintuitive in the development environment

The eureka moment came to me in my latest project (in which i’m using svn), when I was thinking about exploring an alternative path to some code that was already implemented, but I thought it could be redone in a better way. How to do it with svn?

I could enter the obscure world of svn branches and merges, where I would have to fight hard to get my code back in one piece, but that didn’t sound inviting at all, and that’s why I haven’t actually implemented the second option, waiting to be more certain about it.

The interesting thing is that since I’ve been using git for the last year, I always took it for granted, and didn’t actually realize this benefit from DVC systems.

So, if you are thinking about why change from cvs/svn to a distributed system, add this point to your list.

Does it Really Work?

Last week during TW London Last Thursday event, I had the pleasure to see this presentation from Dave Robertson and John Johnston (or at least part of it), about how Agile and User Centered design are more a match, sharing goals and values, than different approaches to software development.

If you have some time you should really watch it, it is worth the time.

The overall presentation is really good, but the reason I’m posting here is one specific point that was mentioned, which I believe really hit the spot, and that’s when they say we should rethink the word work in the “the simplest thing that could possibly work” sentence.

This point goes back to the Agile Vs Usability discussion and it is very correct IMO, because it reiterates that development teams should not deliver any code just because it was quick to develop it and the client is happy (although he shouldn’t be at all) since it didn’t cost a fortune.

And what is interesting about this subject is how agile teams don’t usually accept low quality code standards (code without tests, lots of hacks, etc..), but easily accept low usability standards, not understanding that is also their responsibility to define what a good user experience is.

What I’m NOT trying to say is that the user should be left outside from the application design. He should definitely have his opinion (and a strong one), but should also receive advice in UX standards as much as he should in code quality, making sure that he understands what he loses when is trying to save money on each particular feature.

T-Shaped People vs Generalists

I’ve been reading Mary and Tom Poppendieck’s new book on Lean Software Development, and in one of the already released chapters, it mentioned the term T-Shaped people, which I had never heard in this context, and suddenly clarified a concept I have in my head for some time.

Since Scott Ambler published the essay Generalizing Specialists, it has become a trend in software development to talk about how generalists are better than specialists for a team, which (in a misinterpretation of what Scott meant) has leaded to a common anti-pattern, where persons become generalists in a lot of stuff, without having a deeper knowledge in any any area.

This way they know a little about a lot of languages, tools  and methodologies, but when it comes to make a difference, these persons are no assets to any team, since they don’t have any deep knowledge on any subject.

This was already covered by Jay Fields in this post, and what I want to point here is how the T-shaped term makes so much difference.
According to IDEO’s Tim Brown, in the  the article is called “Strategy By Design”, here is how a T-shaped person could be described:

“We look for people who are so inquisitive about the world that they’re willing to try to do what you do. We call them “T-shaped people.” They have a principal skill that describes the vertical leg of the T — they’re mechanical engineers or industrial designers. But they are so empathetic that they can branch out into other skills, such as anthropology, and do them as well. They are able to explore insights from many different perspectives and recognize patterns of behavior that point to a universal human need. That’s what you’re after at this point — patterns that yield ideas.”

And that’s what happens in software development. Once you have a deep knowledge in some language, for example, it is easy to branch out to different ones, since you can recognize the same (technical and behavioral) patterns, which will lead you to soon become competent in that area too.

But this situation does not happen if you always stay at the novice level, without never mastering anything you do.

Rails 2.3 New Features

In the set of new features from Rails 2.3, I was quite pleased by two of them: nested attributes and nested forms.

Both allow the creation of forms containing information about more than just one model, and may solve a recurrent problem I had in past projects, which has lead to some painful headaches…

Can’t wait to try it!

More information (source):

3.1. Nested Attributes

class Book < ActiveRecord::Base
  has_one :author
  has_many :pages

  accepts_nested_attributes_for :author, :pages
end

class Customer < ActiveRecord::Base
  has_many :orders

  accepts_nested_attributes_for :orders, :allow_destroy => true
end

<% form_for @customer do |customer_form| %>
  <div>
    <%= customer_form.label :name, 'Customer Name:' %>
    <%= customer_form.text_field :name %>
  </div>

  <!-- Here we call fields_for on the customer_form
       builder instance. The block is called for each
       member of the orders collection. -->
  <% customer_form.fields_for  rders do |order_form| %>
      <p>
        <div>
          <%= order_form.label :number, 'Order Number:' %>
          <%= order_form.text_field :number %>
        </div>

  <!-- The allow_destroy option in the model
       enables deletion of child records. -->
        <% unless order_form.object.new_record? %>
          <div>
            <%= order_form.label :_delete, 'Remove:' %>
            <%= order_form.check_box :_delete %>
          </div>
        <% end %>
      </p>
    <% end %>
  <% end %>

  <%= customer_form.submit %>
<% end %>

The Forces of Destruction

This post came to my mind while reading this post in Sarah‘s blog .It is not my intention to discuss pair programming (or flying a plane) here, but one thing that got my attention was the mention that there is a culture bias towards single programming, more specifically:

…Gladwell has lead me to start believing that there is a cultural bias towards single programming. Take universities for example – you can be expelled for working collaboratively; individual results count, team work in assignments is often discouraged.

And I definitely agree with it. Actually, that is exactly what Deming says in one of his books. According to him, everyone is born with a power of intrinsic motivation, dignity, cooperation, curiosity and joy in learning, but all these characteristics are consumed by the “forces of destruction” that our present style of rewards brings with it, like grades in school, competition between people and payment for individual performance.

And if we analyze it, that is kind of the funny part (not to say sad…): We teach everyone since primary school how not to collaborate with anyone. Students cannot share their knowledge in exams, are always competing for better grades, and when these same persons start they work life, one of the most requested skills is what? working with teams…

But like this isn’t enough, the same companies that hire employees “who can work in teams” still have individual performance reviews, blame cultures, give individual bonuses and promote managers because of the good performances of his subordinates. And when cooperation is not easy, everyone still wonders why is so difficult for people to work collaboratively.

And coming back to the world of agile software development, this doesn’t stop being a reality. It is not unusual to see teams where only the most experienced people are valued, where project managers have an authority position against the rest of the team and less experienced developers don’t have a say when discussing with more experience ones (and here comes pair programming….)

So, if you really want your team to work collaboratively, think about all the times where you are measuring and rewarding them individually, and stop doing it!

The Wire Mistery Solved!

As a huge fan of  the “The Wire” series, as I always wondering how the Baltimore police  and its homicide department could be so bad. How could they have so many problems when trying to solve the crimes in the city?

Guess what, when watching one episode of the 5th season, I finally realized the source from all their problems, as the next picture shows…

They use Lotus Notes!

After that, is no wonder that the crime rate is so high….

Speaking About Agile 2008

For the portuguese speaking crowd, the video from the presentation me and Danilo did last year at Falando em Agile 2008 is now available.

If anyone is interested, the slides can be downloaded at the presentations tab of this site.