Danilo Sato

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.

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.

I attended this session on Friday morning. This time the subject was another Lean tool: kanban. Corey Ladas showed 3 different project scenarios and presented different approaches to implement a kanban system.

He started by talking about some important Lean concepts like one-piece flow, work-in-process (WIP), cycle time, and their relationship using a Cumulative Flow Diagram (or finger chart). He showed how a constraint in the system can cause disruptions to flow and cause more harm than benefit to downstream processes by building more and more inventory (WIP). He then went on to explain the benefits of using a kanban system to limit the amount of WIP in the different scenarios.

The first scenario was a traditional waterfall-style process. He used a value stream map to identify the amount of value-producing time in each phase of the process, and used that to calculate an initial buffer size for each kanban lane. Instead of trying to explain the whole idea here, I suggest you to read Corey’s series of 4 posts on the subject.

The second scenario was a transition from a Scrum process into using a structured kanban instead of a traditional story/task board. Again, the approach is explained in more detail in a post about what he called Scrum-ban.

The third scenario would be an improvement over an existing kanban process, but due the number of questions throughout the presentation (which generated some quite interesting discussions) he didn’t have enough time to go into more detail.

My overall impression of the session was that he did a good job explaining kanban as a tool, and the reasoning behind it to limit WIP and control the flow of your process. The discussions and questions were also very interesting, which demonstrated the audience was interested in the subject. The thing that I didn’t like so much was his argument in favor of having specialists in the team, and how to move into using kanban without too much change along the way. I think one of the fundamental Lean principles is kaizen, or continuous improvement, and it encourages the team to constantly search for better alternatives. Change is part of the process and should be seen as a Good Thing. And I have already shared some of my impressions about Generalist vs. Specialists, so I’m a bit biased :-)

An important thing to keep in mind is that kanban is just one of the tools in our Lean toolkit. I particularly like Kenji Hiranabe’s InfoQ article on the subject, where he explains kanban in a more broad context, acting as a balancing tool between reducing WIP and one-piece flow, as well as a way to visualize kaizen. Lean is full of contradictions, and you must understand the underlying principles to be able to apply (and change) the practices to a particular situation. Using kanban per-se shouldn’t be a goal for any agile team, but it is very important to understand how it works and the reasoning behind it. If you haven’t looked into kanban yet, you should definitely check out the references in this post.

In this session, Joshua Kerievsky (the founder of Industrial Logic and author of “Refactoring to Patterns”) shared his experiences about stepping away from using estimations and moving into what he called ‘Micro-releases’. What got me interested is that, although he claimed not to be following the recent kanban/iteration-less techniques, he arrived in something relatively similar through his own experiences.

He started talking about the usual confusion of using different units to estimate stories (using points and people converting it into time-units when estimating, using ideal hours and people interpreting it as real hours, and so on). This confusion is also reflected in the way people interpret the team’s velocity. Instead of using it as a measure of the team’s capacity, it’s easy to make it a performance measure. Improving velocity becomes a synonym to improving productivity, and we still don’t know how to measure productivity in software.

Another usual problem that he raised is “What to do with hang-over stories between iterations?”. Are they considered waste? Should they be counted in the team’s velocity? Why is it a hang-over? Is it because it’s close to be completed or is it actually much bigger than the team expected?

His proposed practice of ‘micro-releases’ is based on a high state of collaboration with the customer: there is a small, prioritized list of what should be done next and the team picks up a small and coherent set of stories and ‘guess’ the next micro-release date based on gut feel. He reports that slipping the end date of a micro-release is not such a big deal, because the next one is always close. In this model, the length of a micro-release varies, but usually between 1-6 days (with some outliers like 15, as I recall from his slides, but it’s not too different than that). Because of that, there’s not a stable measure of velocity and using it becomes useless. Feeding the input list with the next stories is done in a just-in-time fashion, and the value produced by the software is realized earlier, as soon as the micro-release is finished.

It’s important to note that he still values the heartbeat of iterations to gather feedback (like a customer showcase or a team’s retrospective). But he simply detaches the release life-cycle from the iterations. This opinion was reinforced by Ron Jeffries in the audience, when he said they were releasing to production twice per iteration in one of his projects. What an interesting point of view: we usually tend to see a ‘release’ as the result of a set of ‘iterations’, but he is reporting smaller ‘release’ cycles than ‘iterations’. Hmm…

But there are some important caveats that should be in place in order for these techniques to work:

• High collaboration with the customer
• Ability to break-down stories into small-but-still-valuable chunks: He reckons it’s very important to know how to break down requirements into “stories of the right size”. If they are too big, there’s no way for the team to guesstimate when they will be finished. He thinks this practice is one of the most important to any Agile project (using micro-releases or not).
• Easy to deploy: There’s no point in having a new release after 2 days if it takes 3 days to deploy it to production.
• Bargaining stories: Alongside breaking stories into small chunks, teaching the customer to bargain for features and avoid what he calls “Feature Fat” (building more that’s actually needed, or gold-plating requirements) is very important (again, this is something you can use regardless of the micro-releases approach).

Since the experiences started with Idustrial Logic’s internal product development, some people argued they are only capable of using that because they have enough experience with XP and Agile, but Joshua claimed he is introducing these ideas with success in their new client projects.

This seems like a common theme in the agile space lately, and you can follow up on the discussions on InfoQ, the XP mailing list, or here. :-)

I’ve found out recently that there’s an interesting timeless statement in the Agile Manifesto that we usually forget: “We are uncovering better ways of developing software…”. We should be open to alternatives and to discuss new ideas!

Continuing my series of posts about Agile 2008, I will summarize the session presented by Rod Coffin and Don McGreal about Pull Systems.

We played a simple game to demonstrate the concept of a pull system. The goal of the system was to produce “Mr. Potato Paper Heads” of different variations: squared/triangle eyes with squared/triangle mouths (4 variations in total). The “production line” was divided in 4 phases:

1. Cut the FACE
2. Assemble the EYES
3. Assemble the MOUTH
4. Launch to MARKET

In a first round, we simulated a push system: the first person was responsible for cutting the face and drawing a specification of what should be built, by choosing the type of eyes and mouth. The next phases were responsible for cutting and glueing the eyes and mouth, respectively. The last phase would take the finished product and stick it to the wall, representing a launch to the market. We knew the market would consume 10 faces, but didn’t know how many of each type, so we had to guess.

At the end of the first round, the presenters showed what the market actually requested, counting revenues and wastes for each team. They then explained the concept of a pull system, that starts with the customer order and drives the upstream processes of the production line based on that.

In order to implement a pull system, we needed some buffers along the way (the mouth assembler would need at least one face of each different variation of eyes in order to build and deliver anything the customer ordered). As soon as an eye-only face was consumed, it triggered a signal to the eye-assembler to build another of that kind, to replace the buffer, creating another trigger to the upstream face-cutter (triggers are represented in red on the following picture, while green represents something being delivered).

I think this was a very interesting and instructive session. It’s much easier to understand concepts in practice, by playing a game, instead of reading it in a book - or a blog ;-).

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…

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?

Acabei de ler um post do Uncle Bob que tem tudo a ver com meu último post. Um trecho interessante que ele diz é:

Acceptance tests should be written at the start of each iteration. QA and Business analysts should take the stories chosen during the planning meeting, and turn them into automated acceptance tests written in FitNesse, or Selenium or some other appropriate automation tool.




The first few acceptance tests should arrive within a day of the planning meeting. More should arrive each day thereafter. They should all be complete by the midpoint of the iteration…

Numa tradução livre:

Testes de aceitação devem ser escritos no início de cada iteração. QA e os analistas de negócio devem pegar as histórias escolhidas na reunião de planejamento e torná-las em testes de aceitação automatizados escritos no FitNesse, Selenium ou outra ferramenta de automação apropriada.




Os primeiros testes devem chegar no dia seguinte ao planejamento. Mais testes devem aparecer nos próximos dias. Eles devem estar completos até a metade da iteração…

Apesar de já concordar com o conteúdo, ele me fez repensar algumas coisas. Como já disse anteriormente, testadores e responsáveis por QA ficam de boca aberta quando digo que o departamento deles não deve existir. Incluo minha irmã nesse grupo, que trabalha no controle de qualidade de um indústria química :-)

O que o Uncle Bob me fez pensar foi que os testes devem aparecer conforme são necessários. É a filosofia Just-in-Time da Toyota aplicada aos testes. Se você escreve os testes (de unidade ou de aceitação) pouco antes de serem necessários você:

• Evita desperdício escrevendo documentos de casos de teste ou pensando nos cenários mais elaborados do mundo. Seu foco está na pergunta: “Como sei se esta história está terminada?”.
• Evita a formação de um estoque de código sem teste (sistema pull e não push).
• Usa o teste para pensar no design do que está construindo.
• Cria um script automatizado que serve como documentação e ajudará os desenvolvedores que precisarão mexer no seu código futuramente (Benefício Mútuo).

Acho que a partir de agora vou mudar meu discurso. Ao invés de dizer que o departamento de qualidade deve ser extinguido, vou dizer que QA deve ser Lean, Just-in-Time. Acho que essa vai ser uma abordagem mais inclusiva e vai gerar menos confronto. O que você acha?