Danilo Sato

One of the best resources about Pair Programming to date is Laurie Williams’ book “Pair Programming Illuminated“, as well as all the research she’s been conducting on the subject. At Agile 2008 I was lucky enough to meet her personally and present my experience report in the same slot as her’s. She showed us a video that was produced to teach Pair Programming to students at the North Carolina State University.

Although targeted to the University environment, the video is great and shares some important lessons about the Do’s and Don’ts of Pair Programming. If you replace references to teacher and teaching assistant (TA) with tech lead or project manager, I’m sure most of the advices will make perfect sense.

The video is really well produced and is worth watching and sharing. Please take the time to check it out and learn from someone who’s been not only doing Pair Programming, but also teaching and publishing research on the subject.

My last session report on the series will be about the second half of the double session I attended on Friday afternoon, which was much more informative and funny. Kenji showed (with live translation) a 30 minutes japanese video about how a former Toyota leader conducted a plant transformation at a Sanyo cellphone factory in Japan.

It started with the successor of Taichi Ohno walking around the production line, followed by a bunch of people, and pointing out a lot of visible waste: unfinished products, piles of partially finished packages, and part-empty boxes. It really demonstrates the Toyota’s practice of Genchi Genbutsu, or “go and see for yourself”. By showing to the plant workers the visible wastes, he even claimed not having seen so much waste in a while :-)

His first approach to transform the plant was to physically reduce the production line size. He arrived on the next day and started to rip out the conveyor belt. The plant manager ran scared to the scene to see what was going on and was asked to get a stair and remove one of the signs hanging from the ceiling that read “Packaging Area”. The idea was to make the size of the production line smaller, so that people would have less space between then. That would require less people: the ones still working would have to do the job of more than one person, and the others could be moved to another department (such as product development).

As you would expect, the changes introduced some temporary chaos into the work place. Not everyone was happy with doing more than one job and the plant manager was worried they wouldn’t make their deadlines. After a heated discussion, he decided to go back to the old layout. However, he allowed that one of the workers participated in another improvement experiment: she would have to work alone in a work cell (yatai), doing the job who was previously performed by 6 or 7 people in the old production line.

At first, the time she took to assemble the cell phone was 2 minutes slower than the production line takt time. However, as she became more proficient, she started to suggest kaizen improvements, such as: raising the table and moving the pieces around to be closer to the place where they would be needed. Within 5 days, she managed to beat the productivity of the production line. The improvement was celebrated by the company’s leaders in an internal event, and she claimed that she felt that she could still improve and become faster.

My mains lessons from watching the video and seeing a lean transformation in practice were:

• Any change introduces a temporary period of chaos, which may cause the process to be reverted before the benefits are realized. Read more about the subject searching for Virginia Satir‘s work.
• Respect for People is clearly shown in the video, as the transformation leader stands besides the worker to support her while she is learning the new skills.
• The differences between Western and Eastern cultures: even though she was unhappy at first with the fact that she would have to do the job of 6 people, she respectfully acknowledged the new job and gave her best. It’s also clear that the Japanese have a more holistic view: companies collaborate with each other to improve the country’s industry as a whole. One of the “incentives” raised by the transformation leader was that if the quality of their products didn’t improve, their jobs would move to China.

This is the end of my Agile 2008 session reports. I hope it proves to be helpful for those who couldn’t attend the conference. Feel free to contact me or leave comments if you want to take these discussions further.

Kenji Hiranabe was awarded with this year’s Gordon Pask Award and 2 of his sessions were voted for a re-run on the last day of the conference, which he decided to present together. In this post I will summarize the first half of his presentation.

New Product Development @ Toyota

Kenji presented an english version of Nobuaki Katayama’s (a former chief engineer at Toyota) talk on a Japanese Agile conference. The video from the first run of this talk is already available on InfoQ, but there are some points that I think are worth highlighting:

• Product development is a phased process: the first phase (getting the concept right) is all about creativity and insights to arrive at an overall vision of the product. For example, the vision for the Prius was not to be a hybrid engine car (this was a decision made later, at the design phase), but to be energy-efficient. According to him, this phase should take as long as necessary to get the concept right. The second design phase is milestone-driven and the chief-engineer has an overall cost buffer that he can use when making trade-off decisions during the development process. The third phase is going into the manufacturing line. This phased approach was somehow brought up again by Alan Cooper on his closing keynote (commented slides are also available online).
• Leadership characteristics: Toyota doesn’t value leaders with a dictator attitude. What really surprised me is that they also don’t seek charism in a leader’s attitude. They should be there to enable teamwork and keep a constant focus on the macro view (product vision).
• Bad news first: Toyota leaders don’t like to hear what is going well. They trust that everyone is doing their best to keep doing the good things. They are there to remove impediments and help solve the problems, so they cultivate a culture of always giving the bad news first.

Another interesting fact mentioned by Kenji is that, after his presentation, the chief engineer watched two experience reports on the adoption of XP and Agile in Japan. He said that, even though we are following different practices, we are applying the same engineering thinking. We use changeability in software to defer the chance of changing things to the last responsible moment. In manufacturing, repetition (as in iterations) is considered a failure. But we use tests to continually keep quality high, allowing for late changes to be implemented without incurring high costs.

Besides presenting the Coding Dojo experience report, one of my main interests of going to Agile 2008 was to attend some of the Lean-related sessions. In this and the next posts I will give a quick summary of the sessions I attended.

Expanding Agile: The Five Dimensions of Systems – Mary Poppendieck

Although not directly related to Lean, in this session Mary gave some insights on leadership and systems thinking that are worth talking about. By using the metaphor of Plank Roads (that provided fast improvements, but deteriorated over time, eventually overcoming its benefits), Mary questioned how sustainable is Agile?

She gave a great overview of the history of software development and the term Software Engineering. From Waterfall to Agile, going through ‘Plank Roads’ such as CMM, Spiral, and RAD, but also highlighting some lessons learned. Her main point was that the fragile aspects of our short history are mostly related to processes and what she called Project Management concepts (life-cycle, requirements, stages of testing, maturity levels, among others). On the other hand, the successes from our history are related to the Systems Engineering aspects of software (built-in quality, information hiding, continuous integration, skilled technical leaders, among others).

As she has already said, successful leadership needs two views: technical vision and marketing vision. She thinks process-related roles (such as a Scrum Master) does not guarantee a successful software. The team needs to understand the entire system, and she highlighted 5 dimensions to consider:

• Purpose: Is there a clear vision and shared understanding of success? Is there technical leadership and built-in learning cycles to verify and improve suitability for purpose?
• Structure: Do junior people have the training and oversight to assure they produce well-factored code? Does everyone on the team understand what they are producing and how it fits into the overall system?
• Integrity: Is quality built-in or inspected at the end of development? Are failures rare and investigated deeply to fix their root cause? Is such learning captured and shared in an effective manner?
• Life Span: Are those responsible for operations deeply involved during development? Is there a long-term vision of maintainability? Are rewards structured so that developing a robust system that performs well over time is the most strongly encouraged behavior?
• Results: Does the system meet its overall economic investment? How quickly is ROI realized?

I think my main lesson from this session is that we should start re-thinking our approach to operations and support. After all, they are all part of the software life span and essential to the value stream. More about Lean and Agile 2008 in my next posts…

The main reason I went to the conference was to present my experience report on Wednesday about running a Coding Dojo in São Paulo since last year with my friends: Hugo and Mariana. I just made the slides available for download, as well as the published paper. Feel free to comment and send questions and comments about our unanswered questions.

The overall feedback we got from the 30 minutes presentation was very good and we decided to do a Live Dojo at the Open Jam in the next available slot. Besides me, Hugo, and Mariana, Emmanuel and Arnaud from the Paris Dojo showed up, Ivan Sanchez from the Floripa Dojo as well, and other people joined us during the session.

We did a Randori session solving the Blocks Problem in Ruby/RSpec, switching pairs every 7 minutes. Although we didn’t finish the problem, it generated some interesting discussions about exposing the internal state vs. a representation of the state to the tests, and how valuable it is to introduce a data structure that you don’t need now but will soon need.

The problem generated some interest and, on the following day, Arnaud had scheduled a slot on the Opem Jam, and we decided to tackle the problem again, but this time in Haskell. Dan and Liz were also there and it was really cool to see the same problem from a different perspective. We discussed how some features of a functional language forces you to think in a different way (I still don’t quite understand Monads, by the way) :-)

Another interesting learning point was: In our paper, we discussed a whole topic about issues with people pairing in different environments (operating system, keyboard layout, shortcut keys, IDEs, …) at every meeting. At the Open Jam, Dan proposed that we used a local Mercurial repository to share the progress on development (pushing at each TDD step for the next pair to continue working on the problem). This allowed him to work on his Mac with a Dvorak layout, while we were using Emacs on a Linux laptop. The other benefit of this approach is that it allows people to experience how Continuous Integration works in practice, committing as often as possible, whenever it makes sense to do so. Good stuff!

It’s hard to summarize all the things that happened during last week in one post, so I decided to break it in smaller posts to keep them short and interesting. Overall, Agile 2008 was great: about 1600 participants from 39 countries (I met over 10 brazilians there! That’s much better than being the only one in 2006), the majority being first-time attendants. With more than 40 concurrent sessions at each 1:30h slot, it’s hard to give a fair summary of what happened there, that’s why I decided to talk about My Agile 2008.

Networking is always good at these conferences: I got to see some old friends and also met a bunch of interesting people: ThoughtWorkers from around the world (we were around 30 presenting/attending the conference), Kiko from Canonical (the company behind Ubuntu), the guys from the Paris Dojo, and a lot of other people that you share ideas with at the bar, the Ice Breaker, the Banquet, and all social events.

The whole conference was organized around the concept of a music festival, having different Stages (with Producers and everything). My personal favorites this year were the Open Jam (self-organizing conference) and the Muzik Masti (a room with instruments and a lot of geek/musicians jamming).

In the next posts, I will share my experiences presenting and running a Coding Dojo at the conference, as well as some of my take away lessons from the sessions, keynotes, and conversations. Stay tuned! :-)

For those of you who didn’t know, after going to XP 2007 last year and speaking with Emmanuel Gaillot, I decided to start a Coding Dojo in São Paulo, Brazil. We’ve been running weekly sessions since last July and after I moved to London, Mariana, Hugo, Fabricio, and others are making sure that the Dojo continues. It has been very fun and educational to organize and run the Dojo, so we decided to share our experiences with the community. We are proposing a 30 minutes Experience Report to be presented at Agile 2008. I wanted to submit this proposal earlier to allow more time for feedback and reviews, but the bureaucracy of moving to another country and the excitement of working with very talented people has kept me busy. But the deadline for submitting session proposals to Agile 2008 is tomorrow, and I didn’t want to lose the opportunity of attending and sharing our experiences. We would appreciate any feedback to improve our session. The link to the proposal is here. Thanks!

 

For a while I’ve been planning to write on this subject. The question of whether going broad or going deep into a subject area has always been present in my life. In this post I will scratch some of my current thoughts on the subject. Feedback and other opinions are welcome!

Some Background

My parents always told me that I couldn’t be good at everything. But they’ve always been very supportive on everything I decided to do. Being a great musician, magician, and programmer was not an easy task, but that never stopped me from trying. But then I read something funny that became a good argument for a while…  

The Specialist Paradox

An specialist is someone who knows more and more about less and less, ultimately knowing everything….. about nothing!

That even made me review my resumé to remove any reference to the word “specialist” and include the word “generalist”. :-)  

Swinging the pendulum

But I forgot that you can always change the argument to take the other extreme and come up with a “Generalist Paradox”. And then I watched Kent Beck’s keynote speech last year at XP 2007 about Ease at Work. We are always trying to be the best, but then we realize how bad we are and start thinking we are the worst. A great lesson that I took from his words is that while swinging that pendulum back and forth, we never stop to think that neither of those extremes are good. Being at ease is trying to find how to stay in the middle. In our discussion, the extremes of the pendulum would be the common view that generalists are best at defining the problem or goal and specialists are best at solving the problem or “executing the plan”:

While researching about this subject, I learned that you have similar concepts in Biology (highlights are mine):

A generalist species is able to thrive in a wide variety of environmental conditions and can make use of a variety of different resources (for example, a heterotroph with a varied diet). Specialist species can only thrive in a narrow range of environmental conditions and/or have a limited diet. Organisms do not fit neatly into either group, however. Some species are highly specialized, others less so, while some can tolerate many different environments. In other words, there is a continuum from highly specialized to broadly generalist species.

We can leverage that same idea, letting go the “Us vs. Them” argument and starting to think about generalist and specialist as complementary skills. David Armano has already suggested changing the “or” to “and”, but I would dare taking it one step further…  

It’s all about context

Specialty is contextual. Anyone in my family would consider myself a specialist in programming and software development. But they don’t have a clue that Computer Science is a broad area with so many fields. Some interest me more than others, so I could say I’m a generalist at that level. But since my interest in software development and Agile Methods is greater than other fields, one could say I’m a specialist, although I wouldn’t consider myself an expert at anything :-) I can see the XP principle of Self-Similarity applied here. I think that the above picture is just a simplification of reality. There are some dots underneath the surface that you can only connect if you specialize a little bit. And I would say that the same fractal structure would appear as you go deeper and deeper into your endless search for knowledge. Sometimes you will have to go back and look broader for a while, but that’s not wasted effort. That’s why I now see value in being both a generalist and a specialist in different contexts.

A ImproveIt está deixando o mercado de serviços e consultoria em Métodos Ágeis e XP. Estava escrevendo esta resposta como um comentário e percebi que estava ficando grande demais, então resolvi dedicar um post, afinal, meus amigos da ImproveIt merecem :-)

Mais importante que vender e disseminar os valores ágeis é mostrar que eles fazem parte da sua filosofia de vida. Com essa mudança vocês demonstram tudo aquilo que é difícil de vender em XP mas que faz muito sentido para quem usa: coragem, abraçar as mudanças, transparência na comunicação e envolvimento com a comunidade.

Até poucas semanas atrás eu não conhecia o pessoal da ImproveIt pessoalmente. Tive o prazer de conhecê-los graças aos eventos de rails em São Paulo e no Rio. Agora posso afirmar com certeza que eles têm o talento e o conhecimento necessários para que o sucesso venha rapidamente.

Tenho certeza que a mudança não é uma reação aos pontos levantados pelo Vinicius. Apesar de eu mesmo ter participado e até promovido os treinamentos de Scrum do Boris, concordo com as críticas. Tanto que, se olharem meu currículo, coloco o treinamento como curso e não certificação. Prefiro olhar pelo lado positivo da mudança. Acho que a mudança de rumos está muito mais relacionada com as possibilidades que enxergam no futuro do que com o que já fizeram no passado. E é exatamente esta atitude que eu admiro. Mudar sem medo. Coragem.

Desejo muito sucesso a todos: Vinicius, Tapa, Rafael, Felipe e Leandro (o único que não conheci pessoalmente, infelizmente). Continuem produzindo produtos de qualidade assim como fizeram com os treinamentos, palestras, consultorias, posts e podcasts sobre Métodos Ágeis e XP. Um grande abraço!

Final de feriado chegando. É hora de voltar a ativa e contar como foram os eventos da última semana. Primeiro um pouco sobre o Conexão Java.

 

 

Sexta-Feira

 

Foi a primeira vez que participei do Conexão Java e gostei bastante do evento. Além de re-encontrar amigos, as palestras que assisti foram excelentes. Na sexta-feira o Alexandre Magno falou um pouco sobre Scrum e, apesar de ter precisado sair no meio da palestra, os comentários que ouvi foram todos positivos. Na sexta acabei assistindo só essa palestra, pois fiquei o resto do dia ajudando o Carlos Villela terminar seus slides (percebam que minha participação foi importante.. he he).

 

 

Sábado

 

No sábado, o keynote do CV criticou os “arquitetos de uma nota só” que preferem usar sempre a mesma ferramenta para resolver qualquer problema. Além de argumentar sobre a importância da plataforma Java vs. da linguagem Java, os tópicos levantados deixaram a platéia preparada para as próximas apresentações.

 

 

O Philip Calçado re-apresentou a palestra de arquitetura do Just Java (dessa vez sem o Paulo) e agradou bastante o público. Apesar de eu já ter assistido a palestra, foi bom para ouvir mais um pouco sobre as “arquiteturas Java do passado”. Particularmente achei muito valioso ele ter levantado temas recentes como Domain-Driven Design e DSLs.

 

 

Depois foi minha vez. Minha estréia como palestrante foi bem recebida. As pessoas que me procuraram depois da palestra me deram um feedback positivo e alguns comentários online que li (aqui e aqui) me deixaram bastante feliz com o resultado. Espero que tenha conseguido passar minha mensagem, deixando algumas sementes para discussão sobre Métodos Ágeis, XP, Scrum e Lean. Minha apresentação já está disponível para download aqui.

 

 

Após minha palestra fomos almoçar numa churrascaria e acabei perdendo a palestra do Vinícius. A última palestra do dia foi do Fernando Meyer, core developer do JBoss, sobre ANTLR e seu uso na criação de DSLs externas. Gostei pois ele mostrou os conceitos básicos de um compilador (parsing, análise léxica, análise semântica, interpretação, geração de código, etc.) e partiu para um exemplo prático de código. Dei uma ajudinha depois da palestra com um bug (essas coisas acontecem) e os slides e o código estão disponíveis no blog do Fernando Meyer.

 

 

Espero poder participar de mais eventos como esse. Se você assistiu minha palestra, deixe algum comentário (positivos ou negativos). Feedback é sempre importante e me ajudará a melhorar para as próximas apresentações. O que você gostou e não gostou da minha palestra? Você aprendeu alguma coisa? Algumas das idéias surtiram efeito no seu dia-a-dia?