Danilo Sato

Dan North wrote an interesting post about the perils of estimation, questioning our approach to inceptions, release planning, and setting expectations about scope. This made me think about the implications of those factors once a project starts, and I came up with some anti-patterns on the usage of velocity to track progress. This is my first attempt at writing about them.

Before we start, it’s important to understand what velocity means. My simple definition of velocity is the total number of estimation units for the items delivered in an iteration. Estimation unit can be whatever the team chooses: ideal days, hours, pomodoros, or story points. The nature of items may vary as well: features, use cases, and user stories are common choices. Iteration is a fixed amount of time where the team will work on delivering those items. Sounds simple? Well… there’s one concept that is commonly overlooked and that’s the source of the first anti-pattern: what does delivered means?

One of the most common anti-patterns I’ve seen is not having a clear definition of done. Lean thinking tells us that nothing is really done until it’s delivering value, which in software means: code running in production and being used by real users. Although I know very few teams who can deploy code to production at the end of every iteration (some even do more than once per iteration), once a story is considered done, it could be potentially shipped, if the business decides so. There shouldn’t be a lot of extra work after that.

Another bad implication of this anti-pattern is that some teams decide to change the definition of done and count half-completed work to show progress. Some of the symptoms to help diagnose if your team is suffering from this anti-pattern are:

• The team starts tracking dev-complete stories
• “It’s done, but [we need to write the acceptance test/it's not integrated with the other system/...]“
• “It’s done, but not done-done”
  
• It takes a lot of extra work to get the story deployed to production
• After finished, the story goes into the next team’s backlog
• Hearing terms like “development team velocity” or “test team velocity”
• Counting half-points or percentages because “if we don’t count it will look like we haven’t worked”

The solution? Remember that velocity is just a number that provides information for the team to understand and improve it’s process. Forget that you’re tracking it and focus on the entire Value Stream and on what’s really value-added to get things into production. Anything else is just waste. If it’s not done, it’s not done. Accept it, move on, and don’t overcomplicate, because it will only add noise and mask what could have been important information to the team.

Last week marked the 10th edition of the XP 200x conference, held in Sardinia, Italy. Me and Francisco were there to present an extended version of our Lego Lean Game. Being selected as the first session on the first day of the program, we were expecting a small audience, but it turned out to be quite well attended by about 20-25 people.

We started the session a bit delayed, due to the lack of room organisation: I was a bit shocked when we arrived and the room was arranged as a normal “lecture room”, rather than the usual group tables (that we requested a week before). Projector and flipchart were not available, so it took us about 15 minutes to have everything ready to begin.

The slow start, however, did not got in the way of the overall workshop. We have designed the activities in a flexible way that allow us to adapt their length just-in-time so we still managed to cover everything we wanted without having to rush.

The first half of the workshop was mostly the same version we presented last year in Buenos Aires, with slight modifications based on feedback we got from participants. The second half, however, was mostly new and we included an activity to allow each team to come up with their own processes (rather than following ours). This turned out to be a great success! Each group came up with different ideas and, by watching the other teams perform, we had an interesting discussion about the different approaches and results. We now think that the original version is too condensed :-)

The feedback we received after the session was great and a lot of people asked us for the material to run the session themselves. Me and Francisco have a “game package” that we can share for those interested in running the game. Get in touch with us if you’re interested! You can find more photos of our presentation here, here, and here (thanks to Hubert for sharing his pictures!). The slides are also available:

We are very interested in your feedback. So, if you were at the conference or want to use the material to run the workshop, please let us know! Share your experiences and help us make it better!

XP 2009 is happening between 25-29th of May in Sardinia, Italy and I will be there attending and presenting some interesting workshops:

• The Lean Lego Game: Me and Francisco have been improving our workshop since we last presented it at Agiles 2008 in Argentina, and we will be presenting a long version (180 minutes) on Monday, May 25th. We have just a few “seats” available to participate on the session (20-24) and it will be occupied in a first-come-first-serve basis. If more people show up we have plans to try and not reject anyone, though.

• Test Driven Development: Performing Art: Emily Bache kindly invited me to present a Prepared Kata at her workshop and I will be pairing with Francisco for 30-40 minutes, programming in Ruby with RSpec/Cucumber. Should be fun to “perform” and watch the other pairs as well. Looking forward to that session on Wednesday afternoon!

My fellow ThoughtWorker Pat Kua will be there presenting a workshop as well. I will try to brush up my (lately lazy) writting skills and publish some conference reports. And hope to see you all there in Sardinia!

Since last December, my friend Ivan Sanchez invited me to help him organize a Coding Dojo in London, at Skills Matter. We’ve only had a few sessions so far, but it’s been great fun going to regular Dojo sessions again, since I left Brazil 1 year ago. In the last session, I did a prepared Kata in Ruby, using RSpec and Ivan did a great job of summarizing some of the lessons learned in his blog.

Our next session will be next Thursday, February 12th and you have to subscribe on the Skills Matter website if you want to attend. To join our discussions of which problems to tackle, which languages to use, join our mailing list. We’re also publishing the source code from the sessions on Github, and some of the sessions are being published as podcasts/videos on the Skills Matter website. I hope to see some of you on Thursday!

It’s been a while since I don’t post here, but today Caelum published the video of my talk (with Frankie) at Falando em Agile, last October. It is in Portuguese, so you may not understand a lot of what we’re saying, but it was fun to share our experiences with the Brazilian Agile community. Enjoy and Happy New Year!

The new version of Synthesis 0.2.1 was just released and the great news is that my experimental work with visualizations was integrated into the master branch! Just sudo gem update synthesis to grab the latest version.

Why Visualizations?

“…reducing the volume and increasing the value of test code by connecting the dots.”

As George pointed out in his first post about Synthesis, it helps you to connect the dots of your tests, to increase your confidence in the system. I like to think of it as a mock coverage tool. When you use a mock in your test, you’re explicitly stating what interaction you expect to happen. How do you really know that the actual object will behave as you expect? You probably need a unit test around it to guarantee it does what it should. Synthesis helps you connect those dots, breaking your build when a mocked expectation is not met in the “real world”.

By using it in a real project, I noticed that the textual output was getting quite verbose. While coding, I was usually only interested in the failure expectations, but when I stopped to look at the whole output, I noticed there were a lot of interesting information hidden in there. If only I could have a better representation of that information…. that’s exactly what software visualization is all about! I had to dig into Synthesis internals to understand how to hook a different report formatter, but the end result ended up being quite good:

Generating Visualizations

To generate such a visualization, first make sure you have sexp_processor installed (sudo gem install sexp_processor) you need to configure your Synthesis rake task to use the dot formatter:

Synthesis::Task.new do |t|
  t.adapter = :rspec
  t.pattern = 'spec/**/*_spec.rb'
  t.formatter = :dot
  t.formatter_out = 'synthesis.dot'
end

This will create a synthesis.dot file that can be used to generate a Graphviz image. You can download and install Graphviz for your prefered platform (there’s even a Mac OS X version), but all you need is the command line dot tool to generate your visualization. Just execute:

dot -Tpng -o synthesis.png synthesis.dot

This will create a synthesis.png image file that will show your tested expectations in green, and untested expectations in red. You can generate other output files by changing the -T option (try ps, pdf for a higher quality). There are still a lot of things to improve in the formatter and any feedback is welcome, but it proved to show some interesting information in my last project, as you can depict in the following picture (notice that the app is mainly composed of 2 subsystems that don’t share dependencies):

Tip: Running Synthesis with Rails

Recently, when trying to use Synthesis in a Rails project, I had some problems that took me a while to figure out. As always, the solution was quite small, so I thought it would be nice to share it with everyone. To run Synthesis on a Rails project, make sure you add the following lines to your Synthesis rake task:

Synthesis::Task.new do |t|
  RAILS_ENV = "test"
  Rake::Task['environment'].invoke # This may make your build slower. Use only if needed
  t.pattern = 'test/**/*_test.rb'
end

Give Synthesis a try in your project and let us know how it goes. You might be disappointed in the beginning about how many expectations you’re not testing, but even if not all of them really require a test, it is still a very valuable information to have. Let me know if you have any issues with the dot formatter as well, as I’m sure there are a lot of kinks to be sorted out. Feedback is always welcome!

The last conference I attended in October was Falando em Agile (Talking about Agile), a 2-day conference organized by Caelum. First of all I need to thank all the organizers for inviting me to speak and for putting together such a great conference.

The content was very mixed, with some people focusing on the management aspects of Agile, while others highlighting the importance of the technical side (with some in between, as well as interesting experience reports). About 200 participants showed up with great questions and experiences, which impressed me and showed how much Agile has grown in Brazil since last year.

David Anderson gave the opening keynote, which focused on his “Recipe for Success”. I find he’s a very opinionated speaker and he can get me both agreeing and disagreeing with him at the same time, which is interesting because we can always learn something. At the same time that I don’t believe in a recipe for success, I strongly agree with his points about how the focus on quality leads to fast delivery, focusing on the engineering aspects to build quality in.

The second talk was mine and Frankie’s about Agile adoption anti-patterns that we noticed in our experiences applying Agile in the “real world”. I think the presentation went really well and the feedback we got was very positive. A lot of people came to talk to us during the break to tell us they’ve identified themselves in a lot of our examples, and that they liked to see us talking about what didn’t work instead of the bright/good things we like about Agile. The slides are available here (in Portuguese).

After lunch, Adail gave a talk about Agile thinking, showing tools such as mind maps and theory of constraints trees. After that, the guys from SEA Technology presented a very interested case study of their attempts of applying Agile in a government project in Brasília. Very interesting to hear their experiences and how it’s possible to apply Agile even in the most adverse environments.

José Papo gave a talk about different types of contract and how their are suitable (or most commonly not suitable) for Agile. The closing talk of the day was given by my friend Guilherme Chapiewski about Agile Leadership. It was interesting to see that he gathered a lot of topics on the subject from different sources and his own experience, arguing about the conflicts of being a leader that provides technical versus process guidelines. I’ve been recently reading a lot about Lean, and my current thinking goes much towards a Chief Engineer role, with a strong technical background, but at the same point with a holistic view of the product and what is value from the customer’s perspective. I missed this topic from his talk, but it was overall really good.

The second day started with traffic again, so I missed Alexandre Magno’s talk about Scrum in PMI environments. Danilo Bardusco gave a great experience report of how they are adopting Scrum at Globo.com, the largest media company in Brazil. I think this kind of experience report is really important for people who are starting with Agile, because it shows how hard it is to change a company’s culture and some of the problems they might find on the way. The last talk before lunch was given by Prof. Fabio Kon and Daniel Cukier: they are both members of AgilCoop (which I’m also part of) and gave a great summary of Linda Rising’s and Mary Lynn’s book “Fearless Change”, showing patterns for introducing new ideas.

Because of the short lunch break (only 1 hour), I was late to watch Daniel Wildt’s talk about his experiences as an Agile coach at Dell. Antonio Carlos from Yahoo!, gave an interesting talk about the importance and the responsibilities of a Product Owner (which I would generalize as the customer in general). The closing keynote was from my co-worker Philip Calçado, where he shared his experience in 2 different projects where bad management decisions made an Agile adoption less successful. I particularly liked his point that “Agile is about inspecting and adapting, but you need to understand what you are doing”. Dropping practices or putting others in place without understanding why they are important may be more harmful to the team.

Overall the conference was really good and I enjoyed seeing my friends and meeting new people enthusiastic about Agile. I was really impressed with how Agile has grown in Brazil since last year. Next year’s conference is promising to be even better and I’m looking forward to participate again.

Continuing the series of conference reports, me and Frankie spend a day in Buenos Aires, Argentina to present a Lego(tm) Game we developed to teach some Lean practices and principles at Agiles 2008. The conference was held during the full week of 20-25 October, including three concurrent 2-day Certified Scrum Master trainings and Mary and Tom’s 2 day course on Lean Software Development.

Unfortunately, we were not able to stay for the whole week, but spending one day gave us a pretty good impression of how Agile is growing in Latin America. The conference had about 400 participants during these 5 days and they had to reject some of the 900 interested due to logistics constraints. As happened in the US and Europe, the major driver for Agile adoption is being Scrum and, as more people start adopting it, the more problems are uncovered about how they can improve on the “technical” engineering practices.

Mary’s opening keynote was exactly about that: how important it is to look at the engineering side of Agile to make its success sustainable. This was the same talk she gave at Agile 2008, highlighting the successes and failures (Plank Roads) of our short software engineering history. I thought it was much better than the last time I saw it, and she managed to convey her message in a much more clear way: focusing on processes/life-cycle has been fragile, while strong technical and engineering practices has shown success throughout our history.

Our workshop went really well: the number of participants and their level of knowledge on Lean matched exactly what we had in mind when we developed it. I’m not going to describe the dynamics of the session, because Frankie already did a good job in doing that. Suffice it to say that the feedback we received was great and that we already have some changes to make it even better. I’m also making the slides available here, although you would have to participate on the hands-on exercises to fully understand it.

I think the overall message of our session was to show how some of the Lean practices work in practice, but also highlight the importance of Systems Thinking and the principles behind the practices. Blindly applying a practice may give you marginal results, but to fully embrace a Lean philosophy you need to keep learning and improving. There’s not an easy recipe to success.

After a good lunch (with Argentinian steak and some Brazilian friends), we went back to the venue and didn’t have a lot of time to watch any other session, so we rushed to the airport. Next year’s conference is promissing to be even bigger, and besides wanting to stay for the whole week, I hope to see more Brazilians sharing their Agile experiences with the Latin American community.

I’ve finally settled down in London and took some time to start the conference reports from the last couple of weeks. The first one I attended in São Paulo was Rails Summit Latin America. It was very well attended (500+ participants) and organized. I should give a special thanks to Fabio Akita and Locaweb for putting such a great conference together!

The conference started a bit earlier to me, when we went out with the other “foreigner speakers” (that’s how non-Brazilians are called in the airport…) to eat Feijoada and drink Caipirinha! Lots of fun! It was really cool to hang out with George, Jay, Obie, Desi, Dr. Nic, Chris, David Chelimsky, Luis Lavena, Akita, and Tim.

The first day of the conference started with DHH’s remote Q&A session, which was OK but nothing new or exciting. The following talk was really good: Chad Fowler gave an inspiring keynote about “Being Remarkable” which was a good summary of his book, plus his skills as a presenter and a good deck of slides (and videos). Very good!

Me and George skiped lunch to rehearse and give some final touches on our presentation about REST. I thought the presentation flowed very well, and it ended up being the only technical session on the main stage during the first day, even though we didn’t show any code: our goal was to talk about REST as an architectural style, basically summing up the great work of Fielding and the good practices that people on the REST community have been talking about. We also wanted to talk about other alternatives to building services on the internet. The slides are available here (we added some notes to make it easier to follow our train of thought).

Dr. Nic gave a funny and entertaining presentation about contributing to Open Source projects and the “Path to Awesomeness”. The first day finished with Chris’ keynote, which was very similar to the one he presented at Ruby Hoedown. If you’re interested, watch it on Confreaks. After his talk, Fabio moderated the Birds of a Feather session (which was more like Lightning Talks), and I was very surprised to see a lot of people stepping up to talk in their 5 minutes slot. The topics ranged from politics to organizing a study group, with special kudos to the Phusion guys who showed a Brainf*ck interpreter in Ruby. Of course, the day couldn’t finish without a rodízio of Brazilian steak at the churrascaria.

On the second day, I experienced the great joy of São Paulo traffic and didn’t made it to watch the Phusion guys’ presentation. I’ve heard from a lot of people it was great and that they gave a great talk about scalability (as well as a lesson on how to use Keynote properly). I arrived during Charles Nutter and Thomas Enebo’s talk about JRuby. It was held remotely and I know Akita had a lot of work to get the environment working. In the end, we still experienced some latency issues but the demos worked out quite OK. After that, Jay gave an interesting talk about the “Immaturity of Testing”, which was rooted in a last-minute presentation we put together for the UK ThoughtWorks Away Day back in June with George. It was great to see how much the discussions from our internal session enhanced the overall message and how Jay managed to put it all together in a nice format. I think a lot of people learned from the pros and cons that he discussed.

After lunch, the ‘testing’ theme continued with David Chelimsky presenting a double talk on RSpec and Cucumber, the gem that’s being developed by Aslak right now and will eventually replace RSpec’s current Story Runner. I wasn’t present during the second half, because I was preparing to present next about my lessons learned about testing. The slides (in Portuguese) are also available and I received some good feedback about it from the brazilians who prefered to watch me instead of David :-)

I stayed around the Brazilian track to watch my friend Fabio Kung present on JRuby and give a real-life demo of his experiments with JMagLev. After that, we all went to watch the closing keynote, by Obie Fernandez. It was a great talk about the Hashrocket way, which was heavily based on their way of applying Agile. In the end, he managed to get standing ovation from some folks in the audience. The last day finished with a lot of champagne and free beer, closing two days of networking, fun, Ruby, and Rails.

My overall impressions from the conference were very positive. It was great to see how much the Brazilian Rails community has grown over the past year. When Fabio and I organized the first RejectConf, back in 2007, we managed to get 100 people to show up in a Saturday and that triggered a lot of other small local conferences throughout Brazil. Seing everyone together for the first time, was a great chance to do the usual networking, and to share our experiences working with Ruby and Rails. I suspect next year’s conference will be even better. See you there!

I’m back from a 2 week “conference season” in Brazil and Argentina, but before I share my experiences on those conferences, I want to talk about my first session at the São Paulo Coding Dojo since I left in February. It was very unusual and pleasant for different reasons: first of all, George had arrived in Brazil for Rails Summit Latin America and I took him to the session; second, it was held at one of the participant’s house, instead of the usual venue at the University of São Paulo (which made it possible to add a taste of fresh baked pizzas to the retrospective); third, we decided to try out a different session format called, in lack of a better name, ÜberDojo which I will try to describe in this post. Hugo has already explained how they came up with the new format in his blog.

In an ÜberDojo, the setup is different than a regular session: there are more than one laptop and no projector. The number of laptops may vary depending on the number of participants, but we were 14 and decided to have 4 pairs, so 4 laptops were available. We laid out the laptops in 2 tables and chose 2 different problems to be solved in 2 different languages. We would go with Python and Ruby, but George argued in favour of having different programming paradigms to enrich the discussions, so we ended up coding in Ruby and Haskell. The problems we chose were already familiar to most of the participants since the goal of the session was to try out the new format rather than solving a difficult problem or learning a new language: Minesweeper and Bank OCR were the chosen problems.

The dynamics of the session are similar to a Randori session, but with multiple pairs coding at the same time. We used a fixed timebox of 7 minutes to switch the pairs (when the round is over, the driver leaves the pair, the observer becomes pilot, and a new observer joins from the audience). The big difference in this format is that it’s impossible for everyone to follow the same train of thought, and there’s always more people than seats available so there’s a lot more chatting happening. When a new member joins the pair, it’s very likely that he will have almost no previous experience with the code being developed (similar to a real-life environment?), so everyone can exercise their ability to read and write readable code. In the original idea, people who were not coding were not supposed to follow what the other pairs were doing, but we ended up helping other pairs with less knowledge on the languages and/or environment. I have to admit I sometimes tried to stick around one of the pair stations because the approach to the solution and the discussions were getting interesting :-)

At the end we held our usual retrospective with food (a lot of pizza) and everyone seemed to have enjoyed the session. I particularly felt the energy and the innovation happening and was very excited with the results. We coded for more than 1:30 hours and it was very hard for me to leave the code unfinished. Although it was a lot of fun, I think for this kind of session to be successful, the participants need to be familiar with a Dojo session and its dynamics (TDD and Pair Programming in particular). Hugo was also a very good moderator, using a pairing matrix to keep track of who was pairing with who, to keep at least one experienced member on each pair, and to put different people in different pairs at each round. The code from that session is available at GitHub.

I see some benefits to trying out this type of session. Solving the same problems in different languages (and paradigms) made it possible to have a rich discussion at the end. For example: when solving the Bank OCR problem in Haskell, pattern matching made it easy to make progress on the first steps, while the Ruby version was getting stuck with a lot of nested if/else statements. Another benefit of this type of session is that you can cope with programmers in different levels of experience. In a traditional Dojo session, you always go as fast as your least experienced participant. In this session, you have different streams of development happening at the same time, so a faster pair can make more progress on their turn. Finally, I think this environment is much more similar to what you might encounter in “real-life”: you develop code for others to read and you have to understand what others were doing while you were absent.

I hope you try out this format in your Dojo and share your experiences. What other types of session are you trying out in your local Dojos? Would you have a better name for this new session format? Leave your comments!