Archive for the ‘Uncategorized’ Category

Straw man (part II)

2010-06-11

Straw man (part II)

I have received a link of this article by e-mail: http://agilemanagement.net/index.php/Blog/thoughts_on_how_kanban_differs_from_scrum/ and to me there are many straw man arguments in there.
I´ll do something I rarely do which is to go over the arguments almost one by one to show the fallacy in them.
1. There is a statement about the control mechanism. In Kanban it is the WIP and in Scrum it is commitment.
Straw: This is just a mix of oranges and apples. The equivalent of the WIP in Scrum is the SprintBacklog and not commitment.
While Kanban bases its cycle of feedback on the execution of batches of work (the WIP), Scrum bases on time, the time box of the Sprint.
2. Within this argument, Kanban is quoted as capable of having a scientific and objective way of improving while for Scrum it is said “let´s just accept that it works”.
Straw: This is just no argument at all. Uses authority to propose that one works because it is scientific and the other is accepted to work in a demeaning way.
3. In the same area of the article, there is misdirection on the proposed 3 questions of the daily Scrum. The questions are redirected as being “What will you do for US today?”

Straw: The 3 questions promote transparency. They are not answered simply as a commitment to others. In first place, the commitment in Scrum is to yourself, and to creating a good product for you, this is a commitment to making your own job and life fulfilling.

4. Also there, the “second commitment” is stated as leading to feedback when the commitment of the Sprint is not met.

Straw: The process of feedback happens always. The commitment of the Sprint is a way of getting people to focus and propose a healthy challenge. Meeting the commitment of the Sprint is coincidental and the main point on using empirical control. After a few Sprints, the particular solution to that particular problem is much more known, and the tendency is that the team gets the commitment right, but in the big picture, this is not the point and not how the feedback and improvement process in Scrum works.

5. It says that Scrum is a revolution while Kanban is evolution and says that Scrum fails because it changes too much.

Straw: This is probably the main line of the article, and also the easiest to answer. The problem with this argument is that if you map the process and start evolving it you still have a defined process.
And we all know that with a defined process you don’t get the benefits of using an empirical process control.

For making software, a very complex problem, evolving a process is not good enough.
In this sense, a revolution is necessary to have actual improvement. Without changing from a process (whatever process) to no process, no real improvement will be gained.

On the impact argument, it may be very painful or less painful, a more or less paced adoption, in any case, to learn how to adopt Scrum with less impact and do a “controlled revolution” people should at least study how to do it a little.

6. The statement is that if you deviate to the textbook definition you are a “Scrum-Butt” and that this discourages innovation.

Straw: This one gets half points because the Scrum-But term is demeaning (intentionally or not). It does not get points on the innovation part of the argument. The set of rules for Scrum are very, very simple. If you cannot follow this simple set of rules, it is probably because there is something wrong in the way you currently work. It is your current process that is resisting change, not Scrum that is resisting change.

If the scenario was: after using Scrum for 2 years and working out that pain, we decided to add another role such as The Cleaner, then this argument could stick. That’s not the case.

7. Kanban uses 5 seed properties to catalyze emergent behavior of process evolution.

Straw: emergent behavior (from Chaos theory) cannot be sought. If it is sought, it is not emergent. That is in the definition of the term. If Scrum promotes emergent behavior is just because when using it emergent behavior happens to appear. It is not designed to do that. It is empirical. Kanban may have the same effect but that is not planned.

Closing thoughts: If Ken Schwaber had not used the kanban board in Scrum or had used it and called it Rugby Team Board we would probably not be even talking about this.

Kanban as a philosophical way of living (from Taiichi Ohno, not kanban, the message and visibility system) is only lightly touched by people talking about Kanban in the software engineering community.

If you use Kanban as described in the article, you are in the path of using an evolving, but defined process. It may be a lot better than waterfall, but misses the point of Scrum entirely. Mind that there are many Kanban definitions for software out there.

If you use Scrumban (mostly the same as Scrum without the time box) you just end up discussing if a time box is beneficial or not. The process control should still be empirical.

Faço parte de um time, o que não posso deixar de saber sobre Scrum ?

2009-06-06

Faço parte de um time, o que não posso deixar de saber sobre Scrum ?

Se você faz parte de um time e sabe pouco sobre Scrum, não se desespere. Aqui está um pequeno conjunto de dicas para você:

1. Seu time precisa de um ScrumMaster. O ScrumMaster deve saber sobre Scrum e vai te ajudar nas suas dúvidas. Não pense que você precisa saber tudo sobre Scrum, este é o trabalho dele. Não se preocupe se você não se tornar um perito em Scrum. Não é esse o seu trabalho.

2. Aprender quais são os papéis básicos, artefatos e atividades de Scrum é muito fácil, e você deve ser capaz de entendê-los com apenas alguns minutos de leitura. Você deve saber o mínimo, o básico sobre Scrum. Esta é a parte fácil e todos do time deveriam saber de cor. Se dê um tempo para aprender na prática.

3. Compreenda que o uso adequado de Scrum requer boa comunicação. Enquanto conhecer as regras básicas de Scrum é fácil, aprender a usar Scrum de forma eficaz é difícil. Confie no seu ScrumMaster, converse com ele, converse com os outros integrantes do time. Mantenha os canais de comunicação abertos. O seu ScrumMaster será capaz de te ajudar.

4. Você tem um conjunto de talentos e um trabalho a fazer. Se alguém ou alguma coisa não estão te permitindo fazer o seu trabalho, há algo de muito errado. Converse com os outros a este respeito. Informe o ScrumMaster sobre o que está havendo. Peça ajuda. Um dos conceitos básicos de Scrum é o de deixar as pessoas que sabem como fazer um trabalho, fazê-lo.

Se você sabe sobre Scrum ou não, eis uma regra para todos:

5. Nenhum projeto pode ser bem sucedido se você não conhece sua arte, não importa o quanto você saiba sobre Scrum. Se aprofunde nos estudos sobre arquitetura, leia sobre design patterns, leia sobre UML, mergulhe no aprendizado de testes ou gestão de configuração. Aprenda sobre TDD e integração contínua. Todas estas coisas são essenciais para se fazer software. Se você está trabalhando em uma área de negócios sobre a qual você nada sabe, procure saber e aprender um pouco sobre ela.

Se você puder aprender sobre ferramentas que potencializam seu conhecimento, o faça.

Conheça o SEU negócio antes de mais nada.

Um bom programador com um processo terá uma desempenho melhor que um bom programador sem, mas tudo que um programador ruim pode fazer com um processo é relatar muito bem como as coisas vão mal.

I’m a team member, what must I absolutely know about Scrum ?

2009-06-04

I’m a team member, what must I absolutely know about Scrum ?

If you are a team member and know little about Scrum don’t despair. Here is a small set of recommendations I have for you:

1. You need a ScrumMaster in the team. The ScrumMaster should know about Scrum and will help with your doubts. Don’t think that you have to know all about Scrum, that is his job. There is no need to worry if you don’t become an expert in Scrum. That is not your job.

2. Learning the basic roles, artifacts and activities of Scrum is very easy, and some minutes reading should make you understand them. You should read about it and know the very basics. That’s the easy part and everyone should have it by heart. Give yourself time to learn from experience.

3. Understand that the proper use of Scrum requires good communication. While knowing the basic rules for Scrum is easy, learning how properly use Scrum to your advantage is difficult. Trust your ScrumMaster, talk to him, talk to the other team members. Keep communication channels open. Your ScrumMaster will be able to help you.

4. You have a set of skills and a job to do. If something or someone does not allow you to do your job, something is wrong. Talk to people about it. Let the ScrumMaster know about it. Ask for help. One of the key concepts of Scrum is letting people that know how to do the job do it.

Whether you know about Scrum or not, here is a rule to everyone:

5. No project can succeed if you don’t know your craft no matter how much Scrum you know. Dig into your architecture studies, read about design patterns, read about UML, dive into learning about tests or configuration management. Learn about TDD and continuous integration. All those things are essential to making software. If you are working in a business you know nothing about, take time to understand a little about it. If you can learn about tools that leverage your knowledge, do it.

Get to know YOUR trade first.

A good programmer with a process will outperform a good programmer without it, but all that a bad programmer can do with a process is to report very well how bad things are going.

Quality is not absolute

2009-05-25

   I have heard a lot of people talking about the execution of tasks related to quality and many absolute rules on the subject.

   I always hear about the subject on rigid terms and I don’t think people really ponder the variables related to the subject.

   First, a brief introduction on the polemic subject:

   A team wants to do a task that is related to the quality of the code, let’s say, improve the unit test coverage. On one side, people say this is part of doing the tasks, and are not open to discussion. The team should just goes ahead and do it. On the complete opposite side, there is a pressure from the customer to have the product ready within a certain time-frame and he does not care about quality.

   Similar discussions are something that can be seen on a day-to-day basis in most projects, and in my view, putting it simply like I did above is very one-dimensional and limiting.

   From the little I learned from manufacturing industry, for every material, there are different quality standards demanded by the factories from their vendors. There is a definition on what is the quality standard prior to production, and depending on the usage of the material, the standards are different.

   Suppose you are buying steel to build a popular vehicle, your iron needs to be assessed under a series of tests so you can be ensured that the car will be safe to the general population. If the iron is to be used in a formula 1, the requirements and the quality level must be much more demanding.

   The formula 1 will be running above 300Km/h under extreme g forces, and the popular car will not. It does not make sense to use the same quality on both cases.

   I once visited a rice farm in the state of Mato Grosso do Sul, here in Brasil. The rice farmed there goes into different rice brands in the supermarket, and those different brands sell with different prices and quality standards. The top brand comes from that farm, and also some not so good brands. And when you look at the rice, it came from the same farm, but they do not have the same quality.

   One of the brands go through extra processing, leaving only top quality grain in the shipping. The other does not, and is of course cheaper.

   With this, my point is that quality is not an absolute concept. Quality must be adequate to the purpose it serves!

   The company producing software must determine standards for quality that the team must maintain rationally. The team must have the freedom to maintain the agreed level of quality, but not above that. If the PO pressures you to go below the “minimum” level of quality, the ScrumMaster must defend the team so they can do their job and the technological deficit is held bellow a certain level.

   If the team wants to do a task that goes above the required level of quality, that decision IS up to the PO. It does not matter if the Team is capable of delivering NASA quality when you need to do a short lived system for a small marketing campaign.

   It is important to be mindful, there is a minimum, and everyone must try to understand what that minimum is. Lots of times, this minimum comes in the discussion of the Definition of Done, and sometimes on non-funcional requirements on the ProductBacklog.

   On the first example I gave, the team improving unit tests, if the agreed coverage is 80%, and the team has 80% but wants to spend a week getting it to 95%, it must have the involvement of the PO.

   If the level was 75%, below what was agreed upon as the minimum level of quality, then there is no discussion, it must be done or else the task itself is not Done.

   This minimum does depend on the project, and going above it, if it is not effort free, must have the agreement of the client. That’s how I see it.

Scrum Gathering Brazil 2009

2009-05-19

Last week a great event took place in São Paulo, Brasil, where a lot of Scrum enthusiasts gathered to discuss and learn more about Scrum.

I’m talking about the “Scrum Gathering Brazil 2009”. The event happened in the luxurious Grand Hyatt on the last 12th and the 13th (May-2009). It was very well organized by the Scrum Alliance folks and the local guys from Adaptworks.

From that event I had the opportunity to learn a lot about the experience others are having with the use of Scrum in Brasil and hopefully gained some insight from it.

One of the first decisions that came out of this event is that I really need to go back to writing about Scrum and get into the discussions that are going on.  My blog about Scrum is back, and I hope, here to stay. As a suggestion from my colleagues here in Concrete Solutions, the posts will be now preferably in English to better enjoy the riches of a possibly international discussion.

In this post I’ll share my overall view of the event, and maybe this will get things going.

As I’ve stated, I think the event was very well organized. Participation however, was not very heterogeneous in my opinion. Few customers attended. The event looked like a meeting about Scrum for Scrum enthusiasts in Brasil, as a mean to get them together.

The gathering had a lot of people from the academic Brasil, lots of students, people from companies that are early adopters of Scrum (such as globo.com and Petrobrás) and some service providers (such as Adaptworks and CI&T).

The presentations, in general, assumed you already knew Scrum to some extent, so, in this sense, it was in accord with the attendance. As a whole the presentations were not very rich in details, and some were really, and explicitly a starting point for discussion. My opinion is that little insight came from the presentations themselves, but a lot from discussions after them.

People seemed to be genuinely excited and willing to enter honest discussions. Everyone seemed really interested in the opinion and to learn from the others there. The discussions were not mere rhetorical confrontations. In my opinion this was the best aspect of the gathering. People seemed to be interested in improving our work condition and practices. I just hope this continues as we move forward to seeing the attendance of the actual clients.

On the next post I’ll comment specifically about the lectures I have attended and what I thought about it all.

O Tao do Scrum

2009-01-02

Este post trata de mais uma analogia buscando o entendimento da relação entre o desenvolvimento de sistemas, metodologias em geral e Scrum.

Começo este texto com citações de Bruce Lee:  http://en.wikiquote.org/wiki/Bruce_Lee

Don’t get set into one form, adapt it and build your own, and let it grow, be like water. Empty your mind, be formless, shapeless — like water. Now you put water in a cup, it becomes the cup; You put water into a bottle it becomes the bottle; You put it in a teapot it becomes the teapot. Water can flow or it can crash. Be water, my friend.”

“Do not deny the classical approach, simply as a reaction, or you will have created another pattern and trapped yourself there.” — Tao of Jeet Kune Do

Bruce Lee ficou muito famoso através de suas aparições no cinema americano em que retrata artes marciais de forma realística pela primeira vez no Ocidente. Na época as artes marcias orientais eram muito restritas no ocidente e a participação de Bruce Lee nas telonas gerou um grande furor e consequente interesse nunca antes visto pelas culturas orientais.

Além de conhecer profundamente artes marciais, Bruce estudou filosofia na Universidade de Washington. Era um perfeccionista, e parecia buscar para sua própria vida um desenvolvimento mental e um desenvolvimento físico compatível.

Através de sua filosofia fica fácil entender porque ele é considerado o “artista marcial” mais influente do século 20.

Antes da criação das artes marciais, o homem em conflito tinha que agir de forma livre nos combates corpo-a-corpo. Os instintos eram dominantes quando o treinamento não existia. As artes marciais surgiram através de estudos dos movimentos de animais e do corpo humano. Buscava-se eficiência, conhecimento do corpo e controle.

A “era” das artes marciais trazia consigo uma forma de combate e uma forma de ensino. Junto com o conhecimento obtido do corpo e de seus movimentos e capacidades veio o formalismo e as doutrinas.

Com o tempo, as diferentes artes marciais (conhecidas hoje e já extintas) passaram a se basear em formas sólidas, se tornaram sequências pré-estabelecidas de movimentos. Se tornaram quase coreografadas e viraram dogmas. Os diferentes estilos eram comparados e cada clã defendia a sua forma de agir e mover.

Quando Bruce Lee cria o Jeet Kune Do, ele propõe uma quebra nas formas fixas, ele propõe no Ocidente que se utilize nas artes marciais aquilo que funcione, que seja eficiente, e não o que seja dogmático. Ao criar o Jeet Kune Do, Bruce mistura as artes marciais que estudou tentando criar a arte marcial definitiva.

Quando caras geniais como  Ivar Jacobson Grady Booch  James Rumbaugh criaram UML e RUP de certa forma eles buscavam o mesmo que Bruce. RUP deveria ser a forma definitiva de se desenvolver sistemas.

Acontece que com Bruce a história acabou sendo diferente. Em pouco tempo Bruce levou a filosofia para os seus próprios movimentos. Bruce concluiu que qualquer arte marcial, incluindo o Jeet Kune Do, solidificava o homem e que, portanto o limitava na hora do combate. Não havia fórmulas que fossem suficientes. Era necessário conhecer o próprio corpo e mente profundamente. Era necessário adaptar os movimentos às necessidades sempre, e não o contrário.

Bruce desejava ser como a água! Adaptável a qualquer situação. De certa forma, Scrum busca isso. Scrum prega a adaptação, e auto-inspeção. Ao mesmo tempo em que não solidifica como devemos nos mover nos pede que façamos o melhor que podemos. Por isso, Scrum não é uma metodologia, e sim um framework. O que é buscado é justamente o espaço para que possamos adaptar os nossos movimentos ao combate que se apresenta na nossa frente.

Em contrapartida, a rejeição pura e simples das artes marciais não vão te levar a conhecer mais as capacidades de movimento e ação que o corpo humano proporciona. Da mesma forma, a fuga deste conhecimento pré-existente nos solidifica e impede o crescimento.

Ninguém começa a lutar de forma eficiente sem forma ou método. Para se desenvolver um alto nível de excelência as formas e métodos são necessários. Deve-se estudá-los e conhecê-los, ao mesmo tempo procurando ficar livres deles.

Assim, Scrum é o fundo libertário de quem conhece as suas práticas e métodos. Sabe usar diferentes métodos conforme as necessidades. Afinal, conhecendo a capacidade do corpo, o braço tem suas formas de movimento. As pernas não chutam em qualquer forma. A liberdade é limitada pelo que temos ao nosso dispor, pela nossa realidade.

Framework, método e música

2008-12-26

 Na produção musical, um artista busca fazer músicas que agradem ao seu público.

Alguns músicos gostam de se isolar, utilizam seu violão para testar acordes, vão anotando, revisando, enviam o material para um colega músico. Recebe sugestões de instrumentistas, altera o conteúdo, a forma, e por fim, dá se por satisfeito com sua produção. Eventualmente, esta música pode ser juntada a outras de sua produção e pode gravá-las em estúdio. Lançando assim mais um LP.

Outros músicos se reúnem com amigos, começam a improvisar, colaboram e vão anotando na mesa, em pedaços soltos de papel. Vão a bares e apresentam a públicos pequenos aqueles trabalhos inéditos. Veem a reação do público. Apresentam gravações a produtores, elaboram mais e assim fazem suas criações.

Em cada artista conhecido vemos manias, processos ou a falta deles, inspiração e produções diferentes.

Alguns artistas são aclamados pelo público, outros nem tanto. A qualidade da música que o artista apresenta ao público mostra dois componentes que se combinam em grandes sucessos.

O primeiro elemento é o talento dos músicos. Nos perguntamos: “Esta música é boa ?”. O público adora. A melodia é genial! Os versos, então…

O segundo é a produção da música. “Como foi gravada e como foi lançada ?”. Ela foi gravada com qualidade em estúdio de primeira linha. O som está de acordo com a proposta da música. A mídia de lançamento é de boa qualidade, com excelente arte gráfica. Os interpretes fizeram jus ao material.

Traduzindo esta alegoria para o mundo dos frameworks e metodologias, o músico com seu produtor seguindo certa rotina na criação estão de fato, utilizando uma metodologia. Esta metodologia pode atrapalhar o músico ou ajudá-lo na criação. Isto não determina se o músico vai conseguir fazer a música, e muito menos se a música vai ser boa.

Um framework como Scrum, determinaria apenas a necessidade de pontos de inspeção e adaptação. Isto poderia ser atingido testando músicas com platéias selecionadas, apresentando demos para determinados produtores que conhecem bem o mercado, etc. Com este feedback o artista poderia então alterar a música e evoluir o seu produto. Isto também não determina se o músico vai conseguir fazer a música, e também muito menos se a música vai ser boa.

Um framework como Scrum ajuda na medida em que o feedback ocorre mais cedo e continuamente, mas não faz a música ser boa. O que faz a música ser boa, em primeiro lugar, é o músico.

Em software, o trabalho de arquitetura é necessário. A metodologia te obrigará a trabalhar a arquitetura de uma determinada forma com determinados entregáveis. Scrum não te obriga a fazer arquitetura, arquitetura é parte do que é necessário ser feito, e portanto, fora do que um framework obriga. Em ambos os casos, alguém que seja bom arquiteto será necessário para fazer o software. Se não houver alguém bom em arquitetura para fazer o software, o software vai ficar ruim!

As metodologias nos lembram de tudo que é necessário para se fazer um software de qualidade. É preciso arquitetura, design, testes, etc. As metodologias obrigam um passo-a-passo que se propõem a garantir que tudo que é necessário para um software de qualidade vai ocorrer.

Scrum por outro lado, se traduz em práticas que vão ajudar os profissionais a fazer o que seus talentos os permitem, sem tentar amarrá-los. Ainda assim, a arquitetura precisa ser feita, o software tem que ser programado e o teste tem que ser feito.

Para fazer música são necessários bons músicos. Para fazer um bom software são necessários bons programadores. As metodologias nos lembram disso e para isso foram criadas. Nos obrigam a fazer tudo o que tem que ser feito e com isto nos amarram. E muitas vezes nos emperram, tirando o espaço para melhores músicas e criatividade.

Scrum não amarra a produção. É tarefa das pessoas lembrar que cada necessidade tem que ser endereçada com seu respectivo talento. A arquitetura pode ser simplesmente pensada, pode ser rabiscada no papel ou pode fazer parte de um documento formal. A necessidade de fazer arquitetura existe pela natureza do problema (fazer software).

Estudar metodologias é salutar e necessário aos mais jovens e inexperientes. Não para amarrá-los, mas para que eles tenham ciência do que é necessário. É o feijão com arroz de se fazer música.

E finalmente, para fazer boa música, o cara tem que ser bom! Quem se preza como músico precisa saber do seu riscado.

Não é uma pena… deve ser horrível quando isto acontece.

2008-12-16

 

Para inaugurar este blog, gostaria de fazer alguns comentários que são relacionados ao grande número de críticas a Scrum e também relacionados aos defensores que vêm Scrum como a nova bala-de-prata para fazer sistemas.

É provável que o fator mais importante relacionado ao surgimento de Scrum seja a epifania que tiveram alguns profissionais da área de TI de que eles tinham de fato um compromisso profissional ao realizar suas tarefas dia-a-dia.

Este compromisso profissional não pode ser entendido como as obrigações mundanas a que os profissionais de TI são submetidos. É um compromisso ético. É o entendimento de que está em suas mãos e possibilidades gerar mais valor do que é gerado.

Estes profissionais compreenderam, com muito trabalho e várias experiências falhas e sucedidas, que é necessário considerar conseqüências. É obrigação pensar no retorno que o seu trabalho traz. É obrigação informar claramente sobre riscos, ganhos, vantagens e desvantagens do fruto de seu trabalho. Acima de tudo, eles passaram a acreditar que independente das regras impostas pela sua indústria, ao se ter a opção de gerar mais valor e a de gerar menos valor, deve-se escolher os melhores frutos.

Um paralelo interessante pode ser traçado utilizando-se a profissão médica. O médico tem um compromisso ético com a saúde do paciente. Este compromisso tem que estar acima da imposição institucional ou da indústria. O médico deve receitar o melhor remédio, e não lhe pode ser imposto o que receitar ou como tratar o paciente.

O médico considera vários fatores ao tratar uma doença ou condição. Ele tem a obrigação de informar ao paciente dos riscos de linhas diferentes de atuação. Uma vez iniciado um tratamento, não consideramos que há como pressionar o médico a curar o paciente mais rápido.

Desta forma, o profissional da área de TI não pode seguir cegamente um processo de software, não será mero escravo das imposições do cliente ou de uma instituição sem pensar que deve agir honestamente. Daí vem a importância da transparência de Scrum. É obrigatório que as escolhas feitas sejam informadas. Os “riscos do tratamento” têm que estar claros. Se o diagnóstico é de difícil tratamento, isto tem que ser entendido pelos envolvidos no projeto. Os Stakeholders têm que saber o que se passa para ter sua influência representada de forma compatível.

Este é o pano de fundo de Scrum e dos métodos ágeis em geral. E independente das regras que surgiram após este ponto inicial, devem ser estes pontos que nos norteiam, e não as regras e práticas.

Uma analogia jurídica está na consideração do texto constitucional. A constituição fica acima das outras leis, é mais forte que estas. Em alguns casos, leis municipais ou estaduais complementam estas leis, ditam procedimentos, normatizam direitos e deveres. Em outros, estas leis são julgadas inconstitucionais, estão em conflito com algo mais básico e importante, e, portanto não podem valer.

Scrum não é uma metodologia. Scrum é a arte do possível, é um framework com regras simples de como trabalhar. Não vai te dizer como resolver problemas. O que Scrum tenta fazer é te ajudar a ter transparência, te ajudar a buscar a geração de valor.

De certa forma, é similar a grande frase da declaração de independência americana: “We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.”

É um direito inalienável “perseguir” a felicidade. Não é um direito inalienável tê-la.

Da mesma forma, devemos buscar gerar valor. Não necessariamente vamos conseguir.

A visão de que Scrum resolverá todos os seus problemas é um grande engano. Em primeiro lugar, Scrum é uma tentativa de evidenciar problemas. Resolvê-los caberá a cada um.

Outro dia li um artigo (http://alistair.cockburn.us/Why+can’t+people+deliver%3f) do Alistair Cockburn em que ele dizia que ter uma espada sem saber usá-la não o faria ganhar uma luta contra um exímio lutador de faca.

E é justamente nesta dimensão que está o centro da questão da maioria das críticas e defesas ferrenhas. Independente de suas práticas, você só vai curar doentes se souber e aplicar medicina. Só ganhará uma luta de espadas se for bom esgrimista (Samurais incluídos).

 Quando fiz o treinamento de ScrumMaster com o Ken Schwaber, tive a oportunidade de fazer várias perguntas capciosas a ele sobre situações específicas. Eram dilemas, problemas complicados que me pareciam não ser resolvidos de forma clara. Problemas que continuavam problemas.

A maior parte das respostas eram na forma de: “Pois é, que problemão que VOCÊ tem, hein ? Depois me conta como vocês fizeram.”;

E é isso aí. Sem mágica. Sem fórmulas, apenas mais obrigações e uma melhor consciência na nossa atuação.