Danilo Sato

The second day of the conference was one of the busiest for me, and it started with a great keynote…

Keynote: Leveraging Diversity in Parallel: Perspective, Heuristics and Oracles – Scott Page

Scott Page, author of “Complex Adaptive Systems: an introduction to computational models of social life” and “The Difference: how the power of diversity creates better groups, firms, schools, and societies”, gave the introductory keynote on the topic of diversity. His talk was one of the most interesting of the conference to me, since he showed the “algebra of collaboration” or, in other words, what are the factors that make diversity work in a team. A few of the highlights for me were:

• The importance of bringing different perspectives to the table: his example of playing the card game “Sum to 15″ as Tic-Tac-Toe was really good.
• When it comes to problem solving, hardness is not the same as complexity: in hard problems, the solution space have lots of peaks (hard to find the global optimum); in complex problems, the solution space moves (even if an optimum is found now, the entire landscape might change due to external conditions).
• I’ve read about the Wisdom of Crowds before and saw James Surowiecki’s keynote at Agile 2008, but Scott showed the formula behind it: crowd error = average error – diversity. In other words, the amount of diversity will decrease the average error of a crowd.
• Netflix Prize: an amazing story about a three-year-long contest put up by Netflix to beat on their own algorithm that predicts how much someone is going to enjoy a movie based on their preferences. What started as a competition to come up with the best algorithm, ended up in a race to collaboration, when the teams running for the prize started combining their approaches and finding that the diversity on the combined algorithm would yield a better result than any of the solutions in isolation. You can read more about this story here.

“Diversity becomes more valuable as the problem becomes harder and harder” — Scott Page

Thawing the “Design Winter” – Michael Feathers

The second talk I attended in the morning was about how there’s not much going on in the software design space lately. Michael Faethers started off noting that our industry is very generational: a lot of the innovation on development techniques in the past, were followed by a wave of design books around the topic (Structured programming, then Structured Analysis and Design; Object-Orientation, then OO Analysis and Design; and so on). Michael said he decided to stop when he saw the book “Aspect Oriented Programming with Use Cases” :-) But with Agile techniques, the last good reference about design was Martin Fowler’s “Is Design Dead?”, from the early 2000’s. Some of Michael’s points on the topic were:

• Design happens around constraints: everytime there are decisions to be made around how to develop a given piece of software, there will be design happening.
• Architecture is design: people should acknowledge that and recognise software architecture as design.
• Look at design as the composition of “things”, not just classes.
• Design are the trade-offs and the discussions you make when taking a particular decision.

I found it an interesting take on the topic, and agree with most of his claims about software design. I personally think that, as a TDD practitioner, I spend a lot of the time doing design (coding is a design activity, not just typing). I also agree that we need to think about design in a higher level, when defining the system/application architecture: those are the decisions that will be hard to change. To me it’s about being able to combine those early-and-hard-to-make decisions with the emergent aspects that you will discover with time, as your system evolve. What you can’t expect is to get it right on the first time, but be flexible enough to incorporate your learnings into something that can evolve.

The Five Habits of Successful Lean Development – Mary Poppendieck

This was the only session I ended up attending on the topic of Lean/Kanban on this conference. Mary summarised 5 habits of successful lean teams:

• Purpose – “Why are you doing it?” In lean companies, workers have a high sense of purpose and understand how their jobs relate to the common goal/vision of the company.
• Passion – “We Care” Having individuals with intrinsic motivation will produce high quality results.
• Professionalism – “Build the right thing” customers don’t want software. If they could get the same thing without software, they would go there. But also “Build the thing right” as simple as possible – and no simpler
• Pride – Expect local decisions, and push them to the front-line workers. They are effectively engaged in delivering superior customer outcomes.
• Profit – “GM stays in business to make money. Toyota makes money to stay in business.”

As catchy as it sounds to summarise Lean into these “5 Ps” mnemonics, I found it to be just a partial view into the topic. Other strong aspects of Lean are the focus on people, and on leaders taking an active role as teachers. These were some of the things I would also expect to see in a lean organisation that I found missing on this “5 Ps” view.

Done Considered Harmful – Marcus Ahnve

This was a lightning talk by my friend Marcus, and I found it really interesting. It was provocative, by picking on a widely discussed concept in Scrum: the Definition of Done (and things like Done-Done, or Ready-Ready). Marcus’ point is that by calling it “Done”, it creates a fake state that usually translates to a hand-off to a different team, or a partial completion state that encourages local optimization. From Lean thinking we know that hand-offs are usually a big source of waste (along with the queues that are usually associated with it).

I was worried he would only present the problem in the talk, but was otherwise pleased with the approach he suggests to tackle this problem: instead of “Done”, call the state by what it represents (e.g. “Ready for deployment”, “In UAT”, “In Production”). Look at the last column in your wall from a hand-off perspective and treat it as inventory in the end-to-end value stream: you might be accumulating WIP and optimizing locally instead of improving the overall effectiveness of your value stream.

Test Automation at Enterprise Scale – Mark Streibeck

This was the technical session I most enjoyed in the conference. Mark talked about the story behind creating Google’s infrastructure to run tests in a massive scale, across teams and codebases, and to provide useful feedback and reports to their developers and teams. Some of the highlights for me were:

• Scale of the system: they run 60M tests/day, including browser tests (cross-browser and running multiple configurations). More than 1700 projects use it (they account that ~80% of all tests are run on this system). The system runs in ~5000 cores.
• Sharing their challenges: this project involved a lot of infrastructure work, which took a lot of time at the beginning of the project, to come up with a scalable architecture. Also, they had to design a UI for a system that solves a known problem in a different way. They also had a lot of work when integrating with various heterogeneous build/test systems that were already in place accross different teams.
• Rollout process: the way they planned and executed the rollout across the company: starting with a few “early innovators”, organic rolling our to a few “early adopters”, and using feedback from these early teams to “fix it” when helping the “early majority” (they even had setup a day where the entire software engineering group could fix things to make the system better.)
• Creativity when solving problems: one of the biggest problems on building and running tests was fixing dependencies issues for projects. Instead of tackling the difficult task to try and solve those issues as a system feature, they focused on improving the way that these issues are displayed on the UI. Just showing the dependencies and letting the teams see it and fix it by themselves proved to be a much simpler solution to the problem.

Conference Banquet and Keynote

The second day finished with a keynote and banquet at the Student Society building. The keynote was presented by Bjørn Alterhaug and John Pål Inderberg, and the topic was “Improvisation: Between Panic and Boredom. Perspectives on teamwork, dialogue and presence in music and other contexts”. It was a very interesting talk about improvisation in music but, most of all, it showed me how practice can lead to mastery: the dynamics between the two musicians and how they communicate to each other through music was a fine example of highly skilled individuals that can achieve incredible results in a highly collaborative environment. A great talk to an Agile audience :-)

The evening finished with an amazing banquet and more music concerts, including a “Keep of Kalessin” show – an Epic Metal norwegian band.

Tuesday was the first day of the XP2010 Conference, being held in beautiful Trondheim, Norway. I was on a morning flight from Oslo and only managed to arrive at the venue in the afternoon. It was nice to see a lot of my friends again – so far, I managed to count 8 Brazilians, which is probably the highest number in XP conferences so far :-)

Functional Programming with XP – Amanda Laucher

The first talk I attended in the afternoon was from my friend Amanda Laucher. She presented on an interesting topic, discussing how Functional Programming languages and concepts can relate to today’s Agile practices and principles. Some of the lessons that I took away from her session were:

• Functional Programming and Testing: she talked about different aspects of Functional Programming and how you can approach testing them. Things like: testing for lazyness, testing monads, minimizing side-effects, testing on strong vs. weak typed languages, testing on static vs. dynamic typed languages (and useful tools like quickcheck). Even though I don’t have a lot of professional experience in FP languages, one particular topic resonated quite strong with my experience: “you need to know FP before you TDD in FP”. On our Coding Dojo in São Paulo, we learned a similar lesson when trying to TDD algorithms: you need to have an idea of how to solve the problem before you drive your solution with TDD. If you don’t know how to solve your problem, TDD won’t give you the solution.
• How to learn a new language: I really liked Amanda’s pragmatic approach to learning new languages. I particularly liked her reference to the Functional Koans, specifically designed to teach you features of a new language by giving you failing tests that you need to understand and fix. This approach separates the learning of the language, from the learning of the testing tool, or TDD. This is a problem I found when trying to learn a new language by first looking for the testing frameworks available, before understanding the languages’ constructs and concepts.

System Metaphor revisited: The lost XP practice – Joshua Kerievsky

My second session of the day was Joshua Kerievsky’s take on the System Metaphor, an XP practice that he asked on his review of Kent Beck’s second edition of the XP book to be removed, and that has been later applied with great success on Industrial Logic’s main product.

He first talked about metaphors in general: how they link a source domain to a target domain, how they’re always partial, and how people need to have experienced the metaphor in the source in order to apply it to the target. He also briefly compared the role of a System Metaphor with the Ubiquitous Language, as described by Eric Evans on Domain-Driven Design (this is something I came across a while ago too). Finally, Joshua described the benefits of a System Metaphor, summarising them on the three I’s:

• Illumination: when the chosen metaphor is good, it will provide illumination into aspects of the system design, clarifying unfamiliar design via a familiar domain. It will help describe not only static structure, but also the runtime behaviour of the system. I particularly liked how he described two ways of understanding the Composite pattern using concepts from the music metaphor.
• Inspiration: a good metaphor will also provide inspiration for new ideas. It provides a system of names from which these ideas may flourish. You might consider ideas from the source domain and evaluate how to apply them to the target. The only thing you need to be careful is that the metaphor is partial, so stretching it to fit your situation might not always be a good idea.
• Integrity: when the source has a rich, familiar set of related parts, it will provide more integrity when applying it to your target. It will also have more integrity when the mapping between the source and the target is strong. If integrity is high, mixing other metaphors won’t weaken the overall structure.

What I found interesting on Industrial Logic’s use of the System Metaphor is that it is visible to the users of the system. If you’re taking one of their eLearning courses, you can see and interact with concepts from the music metaphor such as albums and playlists. The previous examples I’ve heard about uses of the System Metaphor were internal to the team and the business stakeholders, to improve communication. You can read more about how they discovered and applied the music metaphor here.

Conference reception – Nidaros Cathedral

The first day ended with an organ concert at the beautiful Nidaros Cathedral, followed by the conference reception with drinks and food at the Archbishops Residence and Palace Museum.

Clique aqui para ler em Português

As I’ve already mentioned here, the Agile Brazil 2010 conference is accepting session proposals to be part of our program. Already with more than 90 sessions proposed, the program committee decided to postpone the deadline for session submissions until next Sunday (7th March 2010) due to requests and to allow more time for the community to interact and help us build the program. Some new functionality was also released:

• Users are now able to add comments to the sessions. We want the community to provide feedback to help our authors to improve their sessions prior to the deadline;
• You can now vote and help us choose the conference logo. We received many proposals, and narrowed it down to 3, and we’re now asking the community to vote on the winner.

In order to participate voting or adding comments, you don’t have to fill out the full author profile, so visit our website (if you haven’t created your account yet) and participate!

[Agile Brazil 2010] Prazo de envio de sessões prorrogado e concurso do logo

Como já publiquei aqui, a Agile Brazil 2010 está aceitando propostas de sessões para fazer parte do nosso programa. Com mais de 90 sessões propostas, o comitê de programa decidiu prorrogar o prazo de submissões até o próximo domingo (7 de Março de 2010) devido a pedidos e para dar mais tempo para a comunidade interagir e nos ajudar a montar o programa da conferência. Algumas novas funcionalidades foram lançadas:

• Usuários agora podem adicionar comentários nas propostas existentes. Queremos que a comunidade nos ajude fornecendo feedback aos autores e ajudando-os a melhorar suas propostas antes do prazo final;
• Você pode agora votar e nos ajudar a escolher o logotipo da conferência. Nós recebemos diversas propostas de logotipo e escolhemos 3 para a votação final, onde a comunidade vai decidir o vencedor.

Para participar da votação ou adicionar comentários, você não precisa preencher o perfil completo de autor, então visite nosso website (se ainda não criou uma conta) e participe!

Clique aqui para ler em Português

I’m one of the organizers of the program committee for Agile Brazil 2010, and we’re very happy to announce that ThoughtWorks has agreed to sponsor the visit of Martin Fowler, our Chief Scientist, as one of our keynote speakers. Since this is Martin’s first visit to Brazil, I decided to ask him some questions that I thought would be of interest to the participants, and he has kindly agreed to participate in this mini-interview:

Q: What have been keeping you busy lately?

Martin Fowler: Overwhelmingly it’s my upcoming book on DSLs. I found writing books to be hard work, and it’s actually getting harder. By June I expect all of the content will be cast so my mind will be able to get away from it – which I’m very much looking forward to.

Q: What are your expectations about Agile Brazil 2010?

MF: I try not to have expectations about things, that way my mind can be open to the reality when I see it. I’ve been doing conferences frequently for two decades now, so it’s hard to get excited about them. I am excited about coming to Brazil. It will be my first time in South America and both I and my wife have long wanted to come down.

Q: What are you going to talk about in your keynote?

MF: I have no idea. I often don’t decide on my keynote until very close to speaking – often doing extemporaneous talks <http://martinfowler.com/bliki/ExtemporarySpeaking.html>. Recently I’ve been doing keynote talks consisting of three or so talklets, some with slides, some without. But exactly how I’ll do it is something I may only decide the night before.

Q: How do you see the Brazilian software community influencing the future of Agile?

MF: It’s hard to say, as I’m not that familiar with the Brazilian software world. I’ve been very impressed by the Brazilian ThoughtWorkers I’ve met over the years, so I know there’s great potential here. I’m generally keen to see more varied cultures contribute to the software world, I think it’s an important part of us growing as a profession.

Agile Brazil 2010 is going to be an incredible conference, and we’re inviting speakers to submit session proposals (the deadline is approaching: 28/Feb!). Don’t miss the chance to see and talk to Martin Fowler, as he’s one of the few speakers I know of that can put together a first-class keynote on the night before :-)

Don’t forget to follow @agilebrazil on Twitter for conference news, and hope to see you there!

[Agile Brazil 2010] Martin Fowler pela primeira vez no Brasil!

Como um dos organizadores do comitê de programa da Agile Brazil 2010, estamos felizes em anunciar que a ThoughtWorks aceitou patrocinar a visita de Martin Fowler, nosso Cientista-Chefe, como um dos keynotes do evento. Como esta será a primeira vez que Martin visita o Brasil, decidi fazer algumas perguntas que julguei interessantes para os participantes do evento, e ele concordou gentilmente em participar desta mini-entrevista:

P: O que tem te mantido ocupado ultimamente?

Martin Fowler: Surpreendentemente é o meu novo livro sobre DSLs. Eu acho que escrever livros é um trabalho árduo e na verdade isso tem se tornado cada vez mais difícil. Até Junho eu espero que todo o conteúdo esteja definido assim isso vai poder sair um pouco da minha cabeça – algo que estou realmente ansioso para acontecer.

P: Quais são suas expectativas para a Agile Brazil 2010?

MF: Eu tento não criar expectativas sobre essas coisas, assim minha mente pode estar aberta para a realidade quando eu a ver. Eu tenho participado de conferências frequentemente há duas décadas, então acho difícil me empolgar com elas. Mas estou empolgado em visitar o Brasil. Esta será minha primeira vez na América do Sul e tanto eu quanto minha esposa estamos ansiosos há tempos por essa visita.

P: O que você irá abordar no seu keynote?

MF: Eu não tenho idéia. Eu geralmente não decido o assunto do meu keynote até uma data muito próxima do evento – geralmente fazendo palestras extemporâneas (improvisadas) <http://martinfowler.com/bliki/ExtemporarySpeaking.html>. Recentemente eu tenho feito keynotes com em torno de três pequenas palestras, algumas com slides, outras não. Porém decidir exatamente como irei fazê-lo vai ser algo que eu possivelmente decida na noite anterior.

P: Como você vê a comunidade brasileira de software influenciando o futuro dos Métodos Ágeis?

MF: É difícil dizer, pois não estou tão familiarizado com o mundo de software brasileiro. Eu tenho me impressionado bastante com os ThoughtWorkers brasileiros que conheci ao longo dos anos, então eu sei que existe um grande potencial aqui. Em geral eu gosto de ver uma variedade maior de culturas contribuindo para o mundo do software, pois acredito que seja uma parte importante para crescermos como profissão.

A Agile Brazil 2010 vai ser uma conferência incrível, e estamos convidando palestrantes para submeterem propostas de sessão (a data limite está se aproximando: 28/Fev!). Não perca a oportunidade de ver e conhecer o Martin Fowler pessoalmente, pois ele é um dos poucos palestrantes que conheço que consegue preparar um keynote da mais alta qualidade na noite anterior :-)

Não esqueça de seguir @agilebrazil no Twitter para notícias da conferência, e espero ver vocês por lá!

I’m helping to organise the first nation-wide Agile conference in Brazil, that will take place in Porto Alegre next 22-25th June. Agile Brazil 2010 is a joint effort to bring together all the Agile communities around Brazil (industry and academy), and the conference goal is to promote communication and collaboration among its attendees aiming to disseminate the Agile culture in the whole country. Some of the confirmed international guest speakers are ThoughtWorks’ Chief Scientist Martin Fowler, Philippe Kruchten, and David Hussman.

After working the past month on building the submission system, I’m happy to announce that we’re inviting you to join as a speaker of this great event too! Tell Brazil about your experiences, present your research and share your products and learnings! You can find the deadlines and the submission guidelines at:

http://submissoes.agilebrazil.com

To find out more about the conference, please visit our website, or follow @agilebrazil on Twitter.

Agile has shown that doing prolonged analysis upfront bears little to no value to the customer. However, doing none means the project lacks the direction that it needs. The question is, how much analysis is enough before the project starts? This will be the theme of my recently accepted “Inception Workshop: Kickstarting an Agile project” that will be pair-presented with Jenny at XP2010, in Trondheim, Norway.

My journey to find the right balance between a generalist/specialist in software has led me to projects where I had to play not only the developer role, but several to varying degrees (PM, BA, QA, Architect, Coach, team lead, …) This is my attempt to share my knowledge towards those different areas, by pairing with an experienced BA and talking about Agile project initiation.

In this workshop, we will share our experience of participating in several project inceptions. Participants will work in a condensed project inception, solving a business problem and using some tools to shape the project for delivery. Our goal is also to learn from other practitioners about the tools and techniques they’re using successfully in their projects.

More details about the session can be found at the XP2010 session description:

http://xp2010.agilealliance.org/node/5380

We are very excited about this session, and we hope to see you in Norway to participate and share your experiences too!

Inspired by a post on the Lean Blog, Pat reminds us that you can’t measure everything effectively. Having written my Master’s thesis on metrics for Agile projects, I’ve learned and read about this in a lot of different places. One approach that is very known to Empirical Software Engineering researchers is the Goal-Question-Metric approach, first published by Vitor Basili et al. in the 90’s.

The GQM model suggests a hierarchical view of three levels to define which metrics to use:

• Conecptual level (goal): the motivation for measurement. Measuring things without a purpose and a thorough understanding of the problem will lead to meaningless metrics. This level imposes the hardest questions: what’s the purpose? what’s the object of measurement (your product, process, people)? what’s the motivation? who is interested in this goal? what are the quality attributes?
• Operational level (question): at this level, a set of questions are defined to try and correlate the object to the quality attributes we are interested in. These questions should help in understanding and assessing the current situation, but also in identifying ways to determine whether the goal is achieved.
• Quantitative level (metric): only then a set of metrics is associated to the questions, to try and find a quantitative way to measure and answer it. These can be objective (like code coverage), or subjetive (individual’s ranking of current code quality). Finding these metrics is not easy either.

It’s easy to try to cut corners and get into the things that are easy to measure first, specially when you can collect lots of quantitative data to work with these days. However, if you you don’t stop to think about the goals and motivations for measurement, it’s easy to forget the systemic complexity that surrounds us and look only for the easy-to-track numbers.

Lean management and problem solving is known for taking a very thorough and detailed approach in the understanding phase. To many people this is a paradigm-shift approach to management. Don’t let the numbers fool you, use them to your advantage.

It all started when I tweeted:

wish I could get hold of a chain of named_scopes without performing any query (which means it can’t be dynamically composed) #activerecord

My team has currently been performing some refactorings on our Rails app and one of our goals is to move complex find queries into more composable/meaningful/maintainable named scopes. Contrary to my expectations, when you call a named scope, Active Record performs a find(:all) query implicitly as you finish your statement:

class Shirt < ActiveRecord::Base
  named_scope :red, :conditions => {:color => 'red'}
  named_scope :clean, :conditions => {:clean => true}
end
 
>> red_proxy = Shirt.red
  Shirt Load (0.3ms)   SELECT * FROM "shirts" WHERE ("shirts"."color" = 'red')
+----+-------+-------------------------+-------------------------+-------+
| id | color | created_at              | updated_at              | clean |
+----+-------+-------------------------+-------------------------+-------+
| 5  | red   | 2009-11-16 18:36:37 UTC | 2009-11-16 18:36:37 UTC | false |
| 6  | red   | 2009-11-16 18:36:37 UTC | 2009-11-16 19:15:18 UTC | true  |
+----+-------+-------------------------+-------------------------+-------+
2 rows in set
>> red_proxy.clean
  Shirt Load (0.4ms)   SELECT * FROM "shirts" WHERE (("shirts"."clean" = 't' AND "shirts"."color" = 'red'))
+----+-------+-------------------------+-------------------------+-------+
| id | color | created_at              | updated_at              | clean |
+----+-------+-------------------------+-------------------------+-------+
| 6  | red   | 2009-11-16 18:36:37 UTC | 2009-11-16 19:15:18 UTC | true  |
+----+-------+-------------------------+-------------------------+-------+
1 row in set
>>

So, even though I can compose named scopes, I can’t defer the query to the point I define which operation to execute. I’m obviously not the first one who had this problem, but it seems like this won’t be fixed until a new solution is proposed in Rails 3.

In our particular case, we didn’t even need the proxy object, but just a hash representation of the composed query parameters. We’re using ActiveRecord::Extensions (ar-extensions) to perform some UNION queries to aggregate results, and it expects a list of hashes that represent each query. It would be nice if I could grab the hash from my named scopes without performing the query…

The documentation points to a proxy_options method that you can use to test your named scope, but it didn’t solve my problem, since it only returns the hash for the last scope in your chain:

>> Shirt.red.proxy_options
=> {:conditions=>{:color=>"red"}}
>> Shirt.red.clean.proxy_options
=> {:conditions=>{:clean=>true}}

The solution, after digging a while through the source code, was to use an internal method that’s used during the merge algorithm, called current_scoped_methods:

>> Shirt.red.clean.current_scoped_methods[:find]
=> {:conditions=>"("shirts"."clean" = 't' AND "shirts"."color" = 'red')"}

This is not a perfect solution, but saved me the trouble of performing the merge myself. I hope the Rails 3 solution addresses these issues and that this post saves me some time digging through ActiveRecord source code if I need this before then :)

I’m here having a great time in Chicago, at Agile 2009. I will write more about the sessions in later posts, but I wanted to talk about the Coding Dojo we ran at the Open Jam. Organised by my friends from the Dojo@SP (thanks Hugo, Mari, and Thiago!), we tried a projector-less format that went really well. I wrote about the Kake Format a while ago, although the name changed.

It was a lot of fun, and we were lucky to bump into Emmanuel Gaillot around in Chicago, who made it to the session as well. We solved the Kata Bowling in three different stations: one in Ruby, one in Haskell, and one in Java. The code is available on GitHub, and these are some pictures I took during the session:

If you want to try out a dynamic format, where people have more chance to participate and train different skills, and you don’t have a projector available, I urge you to try out the Kake Format on your Dojo and share your experiences!

Continuing with the series, this time I want to highlight a very dangerous anti-pattern: using velocity as a performance metric. Before getting into the examples of how it applies to velocity, I want to first explain my view on metrics. I am in favour of metrics and coming up with interesting ways of displaying data (information visualization is a very interesting topic). However, the problem lies in the way that these metrics are used. There are two main types of metrics that I like to categorise as:

• Diagnostics Metrics: these are informative measurements that the team uses to evaluate and improve it’s own process. The purpose of collecting them is to gain insight into where to improve, and to track whether the proposed improvements are taking effect. They are not associated to a particular individual or to how much value is being produced. They’re merely informative and should have a relatively short life-cycle. As soon as the process improves, another bottleneck will be identified and the team will propose new metrics to measure and improve that area.
• Performance Metrics: these are measurements of how much value your process is delivering. These are the ones you should use to track your organisation’s performance, but they should be chosen very carefully. A good approach is to “measure up”. Value should be measured at the highest level possible, so that it doesn’t fall into one team’s (or individual’s) span of control. People tend to behave according to how they’re measured and if this metric is easy to game, it will be gamed. There should also be just a few of these metrics. An example of one such metric would be a Net Promoter Score (that measures how much your custumer is willing to recommend you to a friend) or some financial metric like Net Present Value (read Software By Numbers if this interests you). As you can see, these are very much outside of a team’s control and to be able to score high on them, they should try and do a good job (instead of gaming the numbers).

Going back to velocity, a very common mistake is to use it as a performance metric instead of diagnostics. Velocity doesn’t satisfy my criteria for a good performance measure. Quite the opposite, it’s a very easy metric to game (as mentioned in my previous posts). When approached as a performance metric, it’s common to see things like:

• Comparing velocity between teams: “Why is Team A slower than Team B?” Maybe because they estimate in different scales? Maybe their iteration length is different? Maybe the team composition is different? So many factors can influence velocity that it’s only useful to compare it within the same team, and even then just to identify trends. The absolute value doesn’t mean much.
• Measuring individual velocity: as highlighted by Pat, this is a VERY DANGEROUS use of velocity, and it can actually harm your process and discourage collaboration.
• A push to always increase velocity: it’s common to have a lower velocity in the beginning of a project, and that it tends to increase after a number of iterations. Inspite of that, I’ve seen teams pushing themselves to improve it when they reach a natural limit (Who doesn’t want to go faster, right?). Velocity measures the capability of your team to deliver and, as such, tends to stabilise itself (if you have a stable process and the number is not being gamed). A Control Chart could help you visualise that. As noted by Deming, in a stable process, the way to improve is to change the process.

It’s important to remember that velocity is a by-product of your current reality (your team, your processes, your tools). You can only improve your process once it’s stable and you know it’s current capacity. Velocity is just a health-check number that will tell your team’s capability. It will not tell you about how much value is being delivered or how fast you’re going. You can deliver a lot of points and make trade-offs on quality which, no matter how you measure it, will impact your ability to go fast in the long run. As uncle Bob says:

“The way to go fast, is to go well”

So let’s stop using velocity to measure performance and look at it as a diagnostic metric to improve our software delivery process.