I mean, the handover topic is something that Im usually asked about, and I’ve never had a decent answer for it, since in my experience it has always been something like this…

Is this story ready to Qa ? Well, I think so,  it must be !

However, in the project mentioned above, at some point we had lot of bugs. Not really serious ones that would make us worry about the quality of the code we were writing, but a great number of small and annoying things that showed us we weren’t being really careful when developing a story.

Most of the stories that we “delivered” (yeah, right…) came back with a considerable number of small fixes to be done. Needless to say, we were losing a lot of time reworking things that should have been caught before finishing it, and not getting much code across the line because of it.

So we had some discussions about the problem and what we came up with was an amazing… checklist.

If we, as developers, were being sloppy when finishing the stories, why didn’t we have a list of what we had to do before considering it ready ?

As you can see above, there is nothing incredible about it,  just the fact that it made us remember what to do, something that is a lot of times easier said than done. Looking at this simple list I can make sure I always test the story against all the browsers we support, as well as verifying that the acceptance criteria were really met.

Talking about acceptance criteria, another goodness that came with it and facilitated the whole process was having mind maps describing what QA’s were going to be testing in every story.

Having this information available and easy to understand was miles ahead from the traditional “I’m going to find bugs in your story” mentality that dominates some teams. As usual, cross-role collaboration was a huge win for productivity.

Knowing what was going to be tested enabled developers to take a look at the story with different eyes, verifying if all cases were accounted for before actually handing it over. As expected, we delivered more.

But before being dictatorial and just writing my opinion, I ran a small twitter poll asking about this subject. Fortunately, most of the answers matched what I think in some level, so hopefully I will be able to cover it all here.

Before starting, a last note. I was reminded that the term tech lead might not be so used and known as I think it is, so if you don’t use this term at all, sorry : ). You can replace tech lead for architect, technical manager, master jedi, whatever you feel like…

Giving an introduction, the tech lead (TL)  term is defined here as a person who has the technical overview over a specific project. Some people disagree about the need for a tech lead at all, but that’s the topic for another post, and here we will assume that the tech lead exists and is a single person. Ok, that was the easy part.

Now the more subtle (and polemic) part comes here, so I will give my opinion on it (with the help from @dtsato and @flessa).

What a tech lead should be doing:

Have a technical overview over the whole project – As a developer doing everyday work, it is easy to lose the long term perspective about where the project is going and make decisions that will be better in the short term, but harm the project in the long way. It’s the job of the TL to keep that in the mind of the development team.

Make sure the project has a common face – Standards are important IMO, and making sure the project still makes sense as a whole, avoiding knowledge silos it’s the job of the TL. He shouldn’t have to enforce standards or ways to develop code, but facilitate the discussion within the team.

Remove technical impediments – As the most experienced person in the project, its natural that sometimes the TL will be the person in the best position to remove technical blockages that the team might have.

Bring people to a good technical level – If the team has different levels of experience, the TL should work to help people achieve a good work quality by sharing his knowledge and incentive others to do the same.

Write code. Write a lot of code – The TL is not a superior being that gives directions from the top of a mountain. Don’t know about your opinion, but if I can’t rely on the TL to sit down and pair with me when I have a problem I can’t solve, it’s no good to me.

I think that is enough for now. Now, for what the tech lead should not be doing:

Be the person responsible for the code – Being the tech lead doesn’t mean being the owner of the code, or the team’s boss. It’s everyone’s job to create high quality software, and the TL should only expose problems to the team and lead them in the right direction (emphasis on lead, not mandate).

Making all the difficult decisions alone - During a project, the team will be exposed to different technical decisions that will have to be made. Allowing the TL to take them alone just expose the team to more risk, since they won’t understand/care about what was decided. What we want to achieve is that Paulo exemplified here.

Impose his opinion – This is probably the most important point. Remember collective code ownership ? It is still very important. No matter how brilliant a TL can be, if he can’t share his knowledge/decisions and specially the responsability with the rest of the team, things will go bad.

The point here is not to discuss how to measure your goals, since this was discussed in previous posts, but what I wanted to explain is how (what I’ve realized during that discussion) I don’t like the term dev complete, and why it can affect your team.

First of all, development complete implies the idea that we don’t need any more development in one specific story, and as anyone who has been in an agile project might have noticed, this is less true than we wanted it to be.

What frequently happens is that stories which are in the dev complete lane come back to development when they don’t meet the QA criteria, and suddenly development has to be done again for something that didn’t need any more development.

And what I find most annoying is that development complete has the word complete on it, which has an underlying meaning that someone (the devs, in this case) have completed their job, and that they could feel good about it at this point.

What goes away when this assumption enters someone’s mind is the fact that the objective (for all the team, including those devs), is after the qa complete stage, when the story is actually delivered. And this situation just gives another motive to the always disturbing separation between developers and qa’s.

So if you believe in how measures affect the results of a team as I do (more info on that here, here, here, here, here, here and here), change all your dev complete stories to qa ready, or something similar, and enjoy a little bit more peace of mind.

This is not new in any sense, and it was exemplified by Deming on one of his books:

I could do a much better job (fewer mistakes) if I knew what the program is to be used for. The specifications don’t tell me what I need to know.

Despite this advance, most software development teams fail in really understanding this concept, and still normally don’t see the power of using one unique measure to manage the project, not getting the idea that the effort of the system should be only measured once, in what is its goal.

You must be asking what is the problem of having different measures to verify the sanity of the project. And that is what Peter Drucker explains in his Post-Capitalist Society book:

In knowledge work… the task is not given, it has to be determined. ‘What are the expected results from this work?’ is the key question in making knowledge workers productive. And it is a question that demands risky decisions. There is usually no right answer; there are choices instead. And results have to be clearly specified, if productivity is to be achieved.

What it means is that tasks cannot be fully specified anymore, the workers have to make decisions every time about how to proceed in certain situations, and they can just do it correctly if they have a clear vision of what is to be obtained, and what is the final goal of the work they are doing.

This concept is also illustrated in the draft version of Mary and Tom Poppendieck’s latest book (still in the draft version), when they are explaining the case of Southwest Airlines, which has as main advantage against the competition, the fact that its planes stay less time in the ground, thus generating more revenue.

Southwest maintains a systems perspective; it doesn’t let individual department measurements or increased revenue opportunities distract it from the primary objective of maintaining profitability. Southwest makes it clear to every employee – from the agent closing the gate to the baggage handler transferring luggage – what is important from an overall perspective. Everyone at Southwest knows the mantra: “Airplanes don’t make money sitting on the ground.” So everyone works together to get each plane in the air as fast as possible.

The important here is that we have one measure. One variable that everyone can rely on to make decisions during their work, and the ability to do it makes a whole difference in the overall performance of a team,  fact that often not considered in software development, where different measures distract people from the main goal.

As an example, a common situation I’ve seen in project is to track bugs within the iteration, and use it as a measure of code quality. Well, the goal of a software team is to deliver software without bugs, but it doesn’t matter at all if in the process of creating software bugs are found and solved prior to the software being released. If that is the way the team works best, so be it.

Another example is a case where a project had a problem with bugs creeping (this time, after iteration was finished and software delivered), and when discussing the fact we’ve realized that because of the pressure to deliver, we were delivering development complete, and not QA complete stories, so QA was actually done after the iteration finished, and yes, the team’s velocity was based on development complete points.

Well… if the goal you set to the team is to deliver dev complete stories, guess what you’re receiving in the end… dev complete stories!, it doesn’t matter how many times you repeat “Let’s focus on delivering quality software“. As Goldratt said, “Tell me how you measure me and I will tell you how I will behave.”

So, what is your goal?

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.

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.

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 :orders 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 %>