What’s the Tech Lead Doing Anyway ?

Some days ago when having a discussion at work about the responsibility of the tech lead in an agile team, I’ve realized that this is not a so simple subject as I thought it was. Therefore, good subject for a post : )

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.

Dev Complete? No!

Recently we’ve had a discussion in a project I was working on about the concepts behind dev complete and qa complete stories, which are normally in a lot of agile wall’s swim lanes, and how they affect the project’s flow.

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.

What is Your Goal?

One of the best things about Agile is the introduction of software development as a system. Software stopped being treated as a sequence of separated steps to be seen as people with different competences working together to achieve one goal: deliver software.

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?

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.

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!

Focus on the Right Point

This post came from a pub discussion with Liz, and actually originated from this thought I’ve been having for some time, an came back in one of my recent readings (not to say also in one of my recent projects)…

I participate in some agile mailing lists, and one question that frequently happens is what I should do about people not showing up/showing up late for the stand-ups in the morning. And normally this comes with statements like: “I’ve tried it all already: waiting, not waiting, punishing late arrivers, making them buy ice cream, etc… and nothing works”

And this situation came again to me mind while reading Ricardo Semler’s book, Voce Esta Louco! (not published in english so far, but it means You Are Crazy!), when he describes how flexible time was introduced in his company.

To give some context, Ricardo runs Semco, a brazilian company which has business units in a lot of different areas, from shipbuilding to hotel management, but is best known for the industrial democracy that its owner has been implementing since the 80’s.

This particular situation he describes occurred when Semco, in the 80’s, was going to allow production line employees to have flexible work hours, and as expected, most of the top managers were totally against the idea, since it violated a basic principle: for a production line to work, everybody has to be there at the same time.

And ricardo’s answer for that was (free translation):

It’s obvious: if the employees are not working at the same time, the production line stops. We know it, but the adults that work in the production line also know it. And why would they put their productivity and their jobs at risk? If they are not worried about how the production line is, producing or not, then we have a much bigger problem, and the sooner we know it, the better.

And that’s what happened, one day before the program started, the employees gathered and decided what time they would start to work.

But what does this have to do with daily standups? Well, the whole example was to indtroduce the same answer I always give to these questions: if your team doesn’t show up for the standups, you shouldn’t worry about why they are late, but ask yourself why they don’t care. That’s your problem.

Agile vs. Usability?

Thre’s been a recent discussion around how agile methods face usability, mainly following Jakob Nielsen’s post about how agile, if poorly executed (that’s my opinion), can be a threat to usable software.

I don’t want to say again what was already said, and I believe that agile and usability can be a good match, as long as you know what you’re doing, but what sometimes bothers me is the common thinking around agile methodologies, that usability = what the client wants. I’ll explain.

In most of the agile projects I’ve been (not to say all of them : ) ), whenever there is some issue around how to make some feature in terms of usability, like “how should be the user experience around this operation”, the common answer is: “let’s ask the client..”.

Well guess what? The client never thought about usability in his life. Of course he used computers already, but he probably doesn’t know how to better develop an application to make it more usable. And this situation gets even worst when the client is just a proxy to the real user, who will probably not even work in the application being developed.

To give a pratical example,  if you asked a bunch of people how they would like to search for web pages in the pre-Google era, how many do you think would answer a “blank page with a text field on it”?

If this ask-the-client behaviour comes from pure lazyness or some cover-your-behind strategy, that’s another discussion, but what I think most agile teams should change in the way they work is to stop pretending that the client has all the answers, and trust a little bit more in themselves to create solutions.

And my guess is that the clients would also like it, because I don’t believe they want to spend their time answering questions like “which is the best solution for this problem: a select field or radio buttons?”.

And if you really want to trust the client to tell you how to build software, do it in a real HCI fashion, observing real users using your application and getting your answers from there.

Cheers,

Francisco.

Change!

Last week I’ve attended to the Rails Summit, first rails conference to be realized in Latin America (btw, excellent event ), and one thing that attracted my attention was what Chad Fowler mentioned in his presentation (sorry Chad, if the words aren’t exactly the same):

Real experience is equal to change. For most persons, 9 years of experience mean 9 years doing things the same way, but experience should only count if you are continually improving the way you work.

This got my attention since I frequently see people trying to use agile methods as pre-made recipes, which you can apply without thinking, as in “my team uses Scrum, or XP, or FDD, etc..”.

It won’t be the first time I say this to someone, but the Agile Manifesto states:

We are uncovering better ways of developing software by doing it and helping others do it.

So nobody should be afraid of changing the way he/she creates software, or adapting the agile practices to his/her context. The best way to develop software is the one that works for you. Change!

Cheers,

Francisco