Archive for June, 2009

The Tao of Scrum (refactored)

2009-06-24

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.” – Bruce Lee

I recently saw a post by Ron Jeffries on his site talking about how people put together sets of knowledge under labels, and end up fighting to defend their labels instead of defending what works over a dogma.

This reminded me of an earlier post of mine in Portuguese: “O Tao do Scrum” where I talk about the similarities between Bruce Lee’s philosophy and Scrum.

When discussing this similarity with a friend I realized I was not as clear enough on my thoughts in my first post, and became inspired to rewrite it to make my analogies clearer. I promise to write something more earthly in the future, but, right now, let’s talk about the clouds (pun intended).

It seems that whatever activity we undertake as humans there are some natural steps of evolution we cannot avoid. At first we start acting by instinct or as many people say, we do things ad hoc. In time, we start to study and noticing patterns, we start to use these patterns to our advantage.

In the martial arts world, it would be like noticing how to throw a punch or a kick and seeing how efficient that can be.

In a second stage, different observations or knowledge is gathered into “systems” (or clouds). Over time, these clouds start to solidify and people start to follow these techniques. When you compare almost any “methodology” to doing things ad hoc, the methodologies will be on top any day of the week.

It seems to be better doing software with waterfall method (even considering all the shortcomings) than doing ad hoc.

Of course, as natural as rain, people start to compare the different methods. In the martial arts world this raises the need for dispute between schools. (My Kanban is better than your burndown; We use TDD, you don’t; and so on)

At the same time that the schools use the comparison to raise their own level of sophistication, some people start to see value in learning from more than one school. Even new “methods” arise from the contact between schools.

With the clash of “systems”, some talented people start to see that there is value in all of the methods, and just try to use what works in each one. They study a lot and try to put together the ultimate method, the perfect method with pieces from all the knowledge existing on a subject.

To me, it seems that RUP was such an attempt. Bruce Lee’s Jeet Kune Do was explicitly such an attempt.

As much as these also are valuable, and seem to be a clear evolution, the new form is also a “system”, and solidifies knowledge. In that sense, they are also limited because the challenges we face require continuous adaptation.

The last step is going back to the start with a different mind. The Tao is a full circle path. When completing a full circle, you end up realizing that the perfect solution is ad hoc. But not in the same sense as the first ad hoc where you know nothing. It is ad hoc in a state where complete self-knowledge dictates the continuous adaptation. You act with the particular purpose of the situation you are in, and every situation has an unique response.

Methods are important, but must be understood as a step. The objective is always to reach/go back to the initial state where you can be better than any method.

“Because the word ”l” does not exist.
A good fight should be like a small play…but played seriously. When the opponent expands, l contract. When he contracts, l expand. And when there is an opportunity… l do not hit…it hits all by itself (shows his fist).
Any technique, however worthy and desirable, becomes a disease when the mind is obsessed with it.“ – Bruce Lee

What does it really mean to be self-organizing and self-managed in a Scrum Team and why is that important?

2009-06-17

Strictly speaking, a self-organizing system is one where the complexity of the system increases without being guided or managed by an outside source. Usually emergent properties can be observed.
The emergent property is a pattern that arises out of simple interactions within the system.
Self-organization spawns into several different concepts for different areas of knowledge. You can talk about it in Math, Chemistry, Linguistics or in Human Society.
Scrum is inserted in a subset of the self-organization principle within the Human context. The idea of not influencing the Team and allowing it to self-organize is based on the notion that emergent properties for the Team can improve the probability of success in a project.
In Scrum, avoiding external influences creates room for creativity and synergistic behavior. At the same time, periodic feedback influences the Team in the direction of the Product Owner’s vision, and both are the basis for a more flexible response to the difficulties presented in a project.

Increased chance of success by the use of Scrum

Increased chance of success by the use of Scrum

The concept of self-management in Scrum comes directly from the social context in work related matters. Worker councils, worker co-operatives, participatory economics and many other human work situations where the presence of a boss is lessened or dismissed entirely relates strongly to the origin of the concept in Scrum.

It seems to me that the founders of the Agile movement and of Scrum were much more capable and knowledgeable than their managers in the many projects they were involved in. This frustration led to studies on many aspects of group dynamics, and many of those principles were incorporated to the basis of these frameworks.

In software, it is not uncommon that the manager knows less about building software than the team members. Almost always the manager knows less about it than the collectiveness of the group.
The Team knows how to build software, and the manager does not. So, when establishing a command and control process within these conditions, the manager will undoubtly get in the way of the success of the project.
Under this line of thought, self-management becomes an obvious choice because you allow people who know how to do the job go on and do it. There is also the bonus that you might get synergy and emergent behavior.

Scrum does not propose a strict sense of self-organization or self-management. The Team is governed by rules that serve an external purpose. They have to follow the Scrum rules, they have to generate value to the client and they have regular feedback.
The Scrum team has a manager. The ScrumMaster is a manager with authority to enforce policy. The ScrumMaster enforces the continuous feedback process and the proper use of Scrum. The ScrumMaster enforces adherent behavior to the “company’s culture” and is a constant checker of the accomplishment of the DoD.
The ScrumMaster should not impose, however, on the “software building” part of the management because he is not the one with the knowledge on how to do it.
The team is self-managed to build the software, not to do whatever they want.

Also, it must be clear that self-management in Scrum does not imply democracy, or voting, or any other particular form of collaboration within a team. The whole of the group dynamics area of studies should be explored to the advantage of the project.
In my ScrumMaster Certification, Ken Schwaber illustrated how the time ticking and the Sprint deadline were strong factors for deciding conflict, and there was no suggestion on voting or a specific form of conflict resolution. In that particular exercise, the decision was made by the one who said it first (like children calling it first).
What was emphasized was the importance of transparency and broadband communication at all times.

Anakin Skywalker: “Doing what the Jedi Council says, that’s one thing. How we go about doing it, that’s another. That’s what I’m trying to teach you, my young Padawan.” – “Star Wars: The Clone Wars” (2008)

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.