Do meio da quadra!

Rising Stars Basketball
Então!

Estou faz um bom tempo longe do Basquete, quer dizer, bom, consegui voltar a praticar no último final de semana, e vamos ver o quão consistente consigo ser nisto.

O ponto é que adoro o esporte e quero ver o Brasil voltar a curtir como nos tempos de Oscar e Hortência! 🙂

Comecei a ler algumas notícias do que vem ocorrendo internacionalmente, assisti alguns vídeos e veio a vontade de escrever mais sobre o assunto, ou pelo menos dar uma opinião de forma mais regular.

Então nesta ideia criei a coluna “do meio da quadra”, onde lá no site da Rising Stars Basketball eu vou ir lançando pequenas ideias, seguindo o princípio do postcard blogging, com posts pequenos buscando a contribuição de quem quer dar sua opinião também.

Então #ficaadica de vocês que curtem o basquete, de visitarem semanalmente ou deixarem o leitor de notícias de vocês apontando para o site da Rising Stars Basketball. Ainda fica a dica de manter o Twitter atualizado nos updates de @rsbasketball e @dwildt, onde os assuntos vão repercutir também.

en: Card, Conversation, Confirmation (a.k.a 3C’s)

index cards
Index cards are a great way to keep track of new ideas for a software product. The good thing about them is because they are limited. You can’t get all information into one. And that’s a really good thing. Trust me.

Back in 2003 when I started learning eXtreme Programming, I’ve heard of a story from Ron Jeffries about 3C. And that’s something truly valuable I teach every time I have the chance to.

The 3C concept is based on writing down an idea to an index card, so we can remember about that idea later on. That’s our first “C”.

What we need next is to generate conversations. We need to validate that new idea, with people that can help on that topic. The best thing about having conversations, is to come up with examples that can validate the idea. If it’s a calculation, samples of those. This way, the card becomes “executable”. A card may have extra documentation to help on that process.
And that’s our second “C”. These conversations can help the team to identify some card attributes, like a sense of “value”, priority, risk, whatever-attributes-your-team-likes-to-use.

The third “C” is about confirmation. Having conversations with customers will help us to understand how to validate that card, to make sure that new functionality is ready to go. So that’s what you have to look for, confirmation! From your customers! They will validate and make your idea grow.

What else for index cards?


I saw Jessica Hagy’s Indexed website by a reference from my sister. You can find a book from her at Amazon if you want to.

The thing is: an index card can do a lot to you. Even help you to keep a great conversation flow with your customers. Try it!

en: The Lean Startup Experience

I saw an infographic asking if we are getting into another “dot com” bubble. That infographic was built by Udemy, great job. I agree with that, and I believe we have better tools and techniques today to help companies to play in startup mode.

One of the things we surely need to focus on is the concept “Lean Startup“. Lots of ways to describe can be found. My way, as an eXtreme Programming and Agile practitioner is to think about a real way to help companies to leverage products to a real experience. With real software engineering + marketing and customer development practices.

But… delivering fast is not enough. Actually it never was! We need to understand who is caring about what is delivered. We need to measure not only progress with real software, but measure how are our clients enjoying the experience during the process. So yes, we have to speak to final users, get feedback, understand what are they looking for. They know the next killer feature of your product. True.

So playing with startups and lean startups is about building experiments and testing ideas and learning from those experiences. Really about learning.

Having that in place, we can grow ideas. I like that term. It’s not about building ideas. But actually grow them.

Last week of June/2011 during Agile Brazil 2011 I’ve done a workshop called “From vision to production”, where I was focused on talking to people about techniques teams using Agile Methodologies like Lean and eXtreme Programming to deliver products and features can use. How do you know if those features are the top ones?

During the practice, I’ve challenged teams to understand about how to build something that can be used to test the idea. Not tested by some xUnit framework, but tested by the market. If possible not even using a real software but using simple tools like a survey, interviews and paper prototyping.

Simple and small experiments that can help a team to learn faster. And prepare it to the next experiment. One of them may result in a software. One of them may result in many new users. One of them may take the company to a next level.

The whole thing is not about getting rich or getting money in a easy way. You know why?

One of those experiments may shutdown your idea, and “help you” to move to some other venture. But, how long would that take? One week? A Month? One whole year?

The thing is about failing as fast as possible, so you can pivot, so you can change direction, plan again, and try again.

Getting to the end…

This post was about sharing things I’m playing a lot.
I’m helping a product to grow for seven months now, since its official launch.
It’s not easy. But it can be fun.

And the “experiences” I will share here, will be related also to other ideas I will help to grow.

Failure is expected. Always. But I’m not about winning all the time (although it’s very good).
I’m about learning.
And you should be too. 🙂

So, to finish “The Lean Startup Experience” post, we should think about a song…

Hey Yo (The pivot song :-))
Hey Yo, where you goin’ with that idea in your head?
Hey Yo, I said, where you goin’ with that idea in your head?
I’m goin’ down to shut my old one baby
I caught her metrics and they are poor man
I’m goin’ down to start a new one baby
I’ll start messin’ round again

* Any relation with The Jimi Hendrix Experience… is that I’m a left handed guitar player too. Just that. \o/

en: How to disable pop-up notification for Skype on Mac OS X

So, I’m a Mac OS user for almost an year now, and to increase my productivity I always disable notifications whenever I can.

For Skype, I used to turn-off the app when running my pomodoros (in my case songdoros), cause I don’t want to receive notifications from it. But, sometimes people call me using Skype and Skype-in calls my mobile. So, I want to know people are calling me and delay the response for later. I don’t want to be disturbed.

Are you a Mac OS user? Want to disable those pop-ups in Skype?
So there you go!

Go to System Preferences, check category “Other” and there you have Growl. Click on it, and you will see a list of applications that are using Growl. Select Skype and then click Configure >> Notifications. Now you can set preferences for events related to Skype.

Example, disable Contact Signed In or Contact Signed Out and get your focus back!

pt: Agile Brazil 2011 – Aí vou eu!

Eu vou no Agile Brazil 2011, e vou participar de algumas atividades durante o evento. Vamos por dia!

Dia: 27 de junho de 2011
Treinamento de Test Driven Development com outras figuras da comunidade ágil do Brasil. Na edição de 2010 oferecemos um treinamento de eXtreme Programming. Neste ano vamos focar na prática de Test Driven Development, trabalhando com práticas relacionadas ao TDD. TDD é para a vida inteira!

Dia: 28 de junho de 2011
Estarei assistindo o treinamento de Lean, do meu amigo Christopher G. Thompson, do Lean Institute Brasil. Estarei lá para participar de boas discussões!

Dia: 29 de junho
Inicio no primeiro dia de evento com o workshop Da visão a produção – Criando produtos e lançando ao mercado. A ideia é dar dicas de como estruturar a criação de um produto e preparar o seu lançamento. A partir de ideias elaboradas de exemplos de produtos os participantes serão desafiados a trabalhar questões como roadmap, pitch de venda, lançamento estilo hollywood, e formas de como criar um produto que pode ser lançado aos poucos e realmente testar e buscar mercado. É colocar as práticas ágeis e conceitos de lean startups na prática e poder levar isto para a vida real. Serão 110 minutos de prática! Aparece lá!

Dia: 30 de junho
Lightning Talk “Jogue basquete e desenvolva times multifuncionais“. O objetivo é falar a respeito dos ensinamentos do basquete e como as equipes podem crescer com isto.

Lightning Talk “Ramones ou Jazz? Ou os dois? Buscando produtividade com músicas” em par com o Helio Medeiros (@helmedeiros). Objetivo da palestra? Gerar concentração, buscar motivação, acreditar que uma música pode ajudar a buscar resultados. Tudo isto usando a pomodoro technique em um ritmo alterado, através das músicas e do “songdoro”, que mistura pomodoro technique com o conceito das powersongs.

Lightning Talk “Desenvolvimento Orientado a Testes — Está na hora de aplicar no seu trabalho!“. Em uma entrevista de emprego, o candidato se diz praticante de Test Driven Development. Pratica em casa nos projetos pessoais, na faculdade, nos coding dojos que participa nas comunidades que faz parte, mas não pratica no trabalho. Lá não dá. E como fica? Descubra abordagens para fazer o assunto acontecer no trabalho também.

Fora isto, espero poder participar e puxar alguns Coding Dojos e parear com algumas pessoas! Os projetos podem ser o @catarse_, o @letshelpit ou algum outro projeto que apareça até lá… e pior que vai aparecer mesmo. Faço atualizações por aqui… 🙂

Acompanhe as últimas novidades do evento pelo twitter @agilebrazil ou siga a tag #AgileBR para obter mais informações e comentar sobre o evento.

A Trevisan Tecnologia, empresa que atuo como CTO, é uma das apoiadoras do evento. Poder contribuir com a evolução e o ensino do assunto no mercado brasileiro deve ser tarefa de todos. Seja ensinando práticas enquanto ensina uma nova linguagem de programação, seja criando uma nova empresa com os princípios do Lean Startup e por aí vai.

Se a sua empresa também tem interesse em apoiar com patrocínio, veja mais informações no próprio site do Agile Brazil.

Oração, com uma pequena adaptação… :-)

A sensação do momento é ouvir A Banda Mais Bonita da Cidade, e a infinidade de clones dos vídeos deles. Depois de um papo que rolou na empresa eu comecei a pensar em uma versão para a música.

Então eu fiquei pensando em como mostrar alguns conceitos de Métodos Ágeis usando a brincadeira da música. Então aí vai. Pensei nos desafios que meu “timão” de trabalho passa no dia a dia. Apesar da equipe que me inspirei trabalhar com fluxo contínuo nos dias de hoje, em um modelo incremental de desenvolvimento e não mais com desenvolvimento iterativo e incremental, a minha brincadeira estava rimando com iteração, então vale uma licença poética. 🙂

Produção

Meu timão, só mais uma iteração
Pra deploy em produção
Aceitação não é tão simples quanto pensa
Nela cabe o que não cabe na cabeça
Do testador
TDD pra vida inteira
É design sem besteira
Pareando nós dois
E review do meu timão, só mais uma iteração
… e assim vai. 🙂

Bom, para ver a música original:

Curiosidade: O primeiro CD da Banda Mais Bonita da Cidade foi financiado de forma colaborativa (CrowdFunding) através do Catarse! Siga a Banda pelo Twitter.

Atualização: Se você quiser ver esta minha “versão” sendo tocada, veja este vídeo que fiz para o Agile Brazil 2011.

Spike Solutions – Why the world would be better if development teams use this as a default

When teams want to build new features in a software, what do they do?

Well, some teams I know, they plan. They build a big plan. BIG means at least 50 pages of non-structured text and diagrams that don’t say nothing about the real problem. And they do meetings!
After two months, they have a document baseline. And now, they can start design phase.

That’s no good!

We are living a time where delivery is not even important. Delivering new and valued features is a must.
We need to move faster. We need to understand risks.

We need to find as soon as possible if we are moving in a wrong direction.

So… we can choose the way we move!

There’s a technique / practice in eXtreme Programming called Spike Solution.

Spike solutions are used to understand a problem. They are used to help teams in estimation. You do spikes to know if something is huge, or if it’s a problem easy to solve.

Bottom line: You do spike solutions to learn faster about something.

So, if you are planning to do a new feature for your software, you have to do spikes. Together with spiking, do drawings to understand connections, to figure out more about user needs, do paper prototyping! Also minimize risks and understand non functional requirements.

How much time do you have for a spike? I would say no more than 4 cycles of pomodoros, or songdoros if you like the technique. By a cycle I mean four 25min focus +5min resting cycle and an extra 30min cycle after that. If we transform that in time, that’s no more than 10 hours of research. That’s actually 8 hours based on pomodoros + 2 hours resting giving space to your brain to mix current learning with what you already know.

Give it a try and help your team to find results faster. Don’t forget to document your findings and transform your spike at least in knowledge. At best in the beginning of a new feature! Enjoy!

en: That’s it. SSDC is the name — Scramble Software Developer Certification classes! Here I go!

You know what? I’m tired about teaching agile and helping teams in engineering practices, learning organization culture creation, lean start-up development mode, and other “pretty agile practices”. Those are everywhere now. Something is needed to change the market!

So… time to rock the market and get true advantage!

I’m preparing a new set of courses that will rock the development area, hopefully all around the world. I want to travel for a while. And create some new terms too!! You know you can’t get attention using same old terms, so I will provide terms that will confuse the market.

You know what happens after that? Full classes!

SSDC (Scramble Software Developer Certification) classes will give you and your team a set of excuses to help on any project failure. But that’s not enough. I want to provide a set of practices that will rock your project! Really about turning it to a raw rock… 🙂

Anyway… let’s continue!
Here we go.
Stay with me! Check the SSDC practices! And sign-up!

1) Coding Marathon. That’s the practice to completely take care of YOUR knowledge. Why would someone want to share knowledge and help others to increase technical skills? Why pairing? You don’t want to waste money right!? In Coding Marathon you code alone, just you and a piece of code equivalent to a 42Km distance.

2) Oh behave Code. No more clean code! Yeah! You are free to release and unleash those techniques you really want to use. Why keep clean variables, methods and readability, when you can use Oh Behave Code to give the creeps to every developer working close to you. Make people fear you. And your code.

3) Scramble Driven Development. Any code you touch, you scramble. Obfuscation techniques to help you to really get ownership of a piece of code, or even a full project. Keep your job safe with this technique!

4) Infinite Integration. Here’s how you can create those automated tests your team keep asking you to create with a great technique to avoid you fixing the build when it breaks. Create tests to increase build time to at least 10 hours. That’s a great time to achieve. When the build breaks, you will be sleeping at home, and the job to fix the build will be with a team in another continent! It’s a really time saver!

5) 12 hour steak technique! Forget healthy tomatoes! Use the technique to help you to concentrate on your solitaire games and your twitter reading. And of course, use the technique to get you enough time to work, but with no pressure! If you feel pressure, just call another steak! In The social network movie they say developers are wired (like in “He’s wired in“). In this technique people say “He’s cooking“.

5) Not in my job description! We will teach how can you use labor law to your benefit! Do you have multifunctional teams? Multidisciplinary teams? Self organizing teams? That’s your practice! We will teach you to use labor laws in the right way and avoid you as a developer to ever test a piece of code. Leave all the job to those paid to test software! Forget about business analysis, performance tests, design processes. Just do your code. Special techniques to the Brazilian market! 🙂

6) Last man standing pace. Specially for those who want to become managers. Make your team work motivated… NOT! Create competitions to see who is able to work more in a team. It’s not about competition, it’s about creating a division on wanna be developers and brave developers. If a developer can’t work 48 hours in a row, that’s NOT a brave developer. And remember, after 16 hours coding, they will be able to maximize results of other SSDC practices! As a manager, make promises you will never turn into reality. If your team ask about, just tell them to fill those work assignment forms you never read, and tell they should really think about working a little bit more, cause the company management team is not seeing any work being done. Leave the room. Don’t say anything else, but don’t forget to look back and “nod your head” with a big no, together with a “tsch tsch tsch“. Make fear your friend. And your team’s enemy.

7) DPLDW – Dilbert-like Punch Line Driven Work. This is the greatest practice available in the course. You can become Wally or the Pointy-haired Boss (PHB). As a developer, learn how to avoid someone asking about your job status. Escape and be free. Always. Confuse the person asking you, make them get your tasks assigned to them. As a manager, learn how to manage without Managing. Guarantee yourself a great life, where you will never need to make difficult decisions again, and will never need to help your team. Just keep doing the minimal and get the premium. That promotion you want is much closer now!

And that’s it. I’m thinking about something like 666 hours of training to really get developers and managers to understand the attitude, strategy and culture behind SSDC.

Well, if you are interested in this course, please let me know. First class starts today, April 1st of 2011! 😀

pt: Tresler volta a ser foco? Sim!

Em 2010 voltei a ler muito e não apenas livros técnicos, comecei a ler mais música, a tocar mais, a ler mais poesia e tudo mais. Com isto um outro projeto vai ir tomando maior proporção, que é o Tresler, que foi um e-zine que mantive com uns amigos de abril de 2001 a abril de 2002. E depois nunca mais.

Em 2008 resolvi fazer o Tresler virar um blog, apenas para “garantir” o domínio, e o blog vem ganhando posts ocasionais, nada formal, nada sério.

Em 2011 a ideia é fazer algo casual, republicando algumas coisas da época do Tresler e ajudando galera que está começando a escrever a aparecer também. Deixo um post de lá falando sobre como a coisa começou e o link do site para quem se interessar.

Ah, não ficarei fazendo cross-posting ou avisos por este blog. Se ficar interessado no Tresler, aproveita o feed RSS de lá.

pt: Foco para 2011: Pingos de Agilidade

Em 2011, você vai ter um canal de idéias rápidas sobre assuntos relacionados a Agilidade.

Está sem tempo para ler posts gigantes sobre algum determinado assunto? Pede no Pingos de Agilidade que a gente faz pequenos posts para tratar do assunto que você quiser discutir, seja relacionado com cultura, práticas de pares, equipes e/ou organização. E sobre a metodologia que você quiser falar: eXtreme Programming, Lean, Scrum, Feature Driven Development, e por aí vai.

#ficaadica: http://pingosdeagilidade.com.br.