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.
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’sIndexed 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!
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/
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!
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á!
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.
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.
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.
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!
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! 😀
— Daniel Wildt
It’s your time to engage with my writing journey. Check my project at patreon.com/dwildt and become a patreon!
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, 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.
Sometimes I see people saying that they don’t need to do anything to improve the world they live in, since they do their part, paying taxes. Some believe that government needs to take action.
I have another opinion about it, and as far as I know, lots of people have another opinion too.
In summary: What we have in place, it’s not enough. Waiting on government, will not help at all. We need action. We need to help people to take action. Let’s do it ourselves.
The thing is: people develop ways to do good to their communities, and therefore to their cities, countries and bingo, world!
So, give one example of movement to help and/or follow!
Looking at software development world, we have opensource software, a movement that creates an environment for knowledge sharing. An environment that helps people all around the world to build better software, and have access to computer software with less costs.
With these things, other people can do good to their communities. That’s good.
That’s a way to help changing someone else’s world.
But, let’s take a look at “a thing” that is universal… music!
Here’s a message: no matter who you are, no matter where you go in your life, at some point, you gonna need somebody to stand by you. Check this:
That turned out to become a movement all around the world, called playing for change.
But, how that’s relate to software world?
They did something and later on they realize that it was big and could become a movement to help people to help people. Musicians could make this happen.
So this is all about following someone and help the movement to grow. Some movement you believe and want to help.
Here I go then. Follow me.
Well, every time I do an event related to technology, where I get a lot of people together, I do some action for those who need help, with donation of food or clothing.
It’s like a “presenting for change“, where you have people doing what they love to do, presenting technology, running coding dojos, but with a social action together with it. It is a simple way to continue being who you are, and doing what you do, but getting different results from your actions.
If you are working close to a technology users group (take Java or Ruby or Agile for instance), you can do that.
If you are doing an event, you can add some kind of donation to an entity that needs help in your event schedule.
So, all my events will have an entry pass, a donation?
Well, if it is a donation, you can’t make it mandatory. But, you can ask people to bring donations! They have a choice. Give them a choice. They will bring donations, if they want to!
So, bottom line is?
Look around and you will see that a lot of people need help. Check for nongovernmental organizations that need help. You will not be able to help them all. Help some of them, check for local needs, ask for help to understand and find organizations that need more help. And help them. With the help of your community. You will find people willing to help. Go for it.
Let’s Help It!
This post was first wrote in May 17th of 2010. It was on my draft since today. Since then I was searching for a way to help this new movement to happen. And here we go again. Let’s Help It! It is an open source software deployed in a free cloud environment, where you can add organizations near you. Therefore other people looking for organizations where they live, can look at that.
It took less than a month to build the first release of the software (from Aug 8th to Aug 31st), following Engineering practices from Agile Software Development Methodologies, with free time from a team of great developers, people I respect a lot. Thanks a lot to all people who made it happen and will continue. And if you want to make it happen too, help us to improve the software! Get in touch and play with us!