Posts Tagged ‘scrum’

Straw man (part II)


Straw man (part II)

I have received a link of this article by e-mail: 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.


Java and Tapioca


Past Saturday (2009-09-19), I was fortunate to speak at the Café com Tapioca.
This year, the event was celebrating 7 years of the CEJUG, Java User Group from Ceará. One of the most active tech groups in Brasil. Those guys did a great job organizing the event.
It was a sunny day, but instead of going to the beach, many people attended the many lectures of the day. In this post I’ll comment on each of them.
Roughly translated to English (all lectures were done in Portuguese), the lectures were:

“The path of productivity for web developers” by Bruno Pereira – Concrete Solutions.

Bruno knows what he is talking about in this presentation. The path for web development is far from clear at this moment and developers need to open their minds now, and explore different possibilities and technologies.
Firebug is definitely a divisor of waters in web development.
The format of the presentation was not very interactive, but I think it would be very hard to show code and be more interactive with so many technologies being addressed. The topic is plenty for a full day on itself just to get you started.

“How to build a JEE/JME application for the 4 corners of the world.” by Régis Melo – Sagarana.

Régis presented his company and main product to the audience. I thought it was interesting to see that the travelling salesman problem can still be sold as a product, and that ILOG has not completely dominated this market.
He also spoke about some of the challenges of exporting software he faced, some similar to what we see here at the company. Brasil’s potential for software is really underestimated.
If we were to set our minds to it, I think India would be in a bad position to compete with us. The similar timezone to the US certainly helps.

“The myth of the agile teams” by Victor Oliveira – Concrete Solutions.

My presentation, below, would perhaps be best enjoyed by managers, and I think maybe not the best presentation for the public present. The local crowd at FA7 was younger, and mostly team members.
The goal was to create knowledge that supporting teamwork needs hard work too. Organizations have to think seriously on what is necessary to nurture teams and make them better and real teams.

“10 bad habits of JSF developers” by Tarso Bessa and Rafael Pontes – Triad Works

This presentation was very technical and really for people that know, and like JSF. Of course, as Bruno’s presentation pointed out, JSF itself is kind of a disappointment. I remember when Microsoft released .NET that JSF was going to be a huge blow in favor of Java technologies for web development. That was around 9 or 8 years ago.
Many years later, the path is unclear with many independent frameworks fighting for space. (Ruby, Rails, Grails, Django, etc) What is certain is that JSF is a good productivity framework, but has a very limited space for its application. After Oracle’s purchase of Sun, JSF’s future looks gray.

“Improving your application with Lucene: get to know Solr and Hibernate Search” by Paulo Jeveaux – Giran

Jeveaux’s presentation was of one of my favorite open source tools in the market. Back in 2004 when I first worked with it I was already impressed, and the evolution with Solr and Hibernate Search only adds to the package.
If you know nothing about Lucene, it is worth your time.

“What killed RUP can kill Agile” by Rodrigo Yoshima – Aspercom

Having worked with RUP for around 7 years, I know how RUP was misinterpreted, especially during the 90’s in Brasil.
The topic presented is important, very important for any software maker that is interested in being better at it. The possible fall of the Agile movement due to it’s misuse or misinterpretation is a clear and present danger. Something I also addressed in my own presentation considering the team aspect of it.
I do think, however, that the separation between just being pragmatic or conservative does not address the change of view that happened once the Takeuchi and Nonaka’s article was in place. In my view, the “theoretical view” from a process control perspective changed the way we viewed what happened before.
Of course, 50 minutes needs a pragmatic approach:-), and the presentation had a good sweet spot.

“Desmystifying TDD in Practice” by Paulo Silveira – Caelum

Silveira’s nervous style of presenting is very engaging and was my favorite presentation. Using a simple TDD example with very simple business rules (stock market) got people eager to participate. It was certainly interactive and fun.
I love TDD ever since I used it for the very first time a couple of years ago. People who have not tried it, really tried it, don’t know what they are missing.

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


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 ?


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 ?


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


   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 Lectures Part II


   It was particularly interested to see Danilo’s presentation. Having some inside information because Concrete is one of the IT suppliers of, it was with curious eyes that I saw it.

   I was particularly interested in how much detailing there would be.

   I think that Concrete was luckily to take part in some of what he was talking about. And the process of adoption in definitely was decisive for our adoption of Scrum. As soon as we heard about their adoption and started learning what it was all about, we were sure; we had to do it to!

   I particularly liked when he mentioned “Kaisen Mind”. I must confess to be a sucker for some of the Japanese way of thinking. 

   This was a strange lecture. Not because the idea isn’t seductive, using Scrum as tool for strategic decision is sexy. The reason I think it was strange is because it never looks like Scrum at a higher level in companies. Directors are usually out to get each other, there are a lot of politics going on, and the whole team looks like chickens.

   In most places, at the executive level, what really drives people are the bonuses and how these are achieved. It is very, very hard to get them to think like a team. At the end of the day, it feels like you have a backlog and a few meetings to see how things are going. Getting them to work together without a change on how you reward an executive is imho wasting time.

   Unless you are in Japan or some other special condition is found in a company, such as weak executives vs. strong CEO, it looks like Scrum can only surface by doing a deeper change.

   This change would require “team work” to be rewarded and that transparency could be a rewarded in some manner.

   I think it is a very good initiative to try (applying Scrum at the exec level). But at this point impossible to achieve as a model.

   It was a very good presentation and certainly brings to the table a lot to ponder.

   This presentation was the one I liked the most and lighted up some starts in my mind. First of all, we consider them competition, and they do many things similar to us.

   As us, to them the PO is a client (as I think it should always be). And there was a good discussion on what kinds of problems they have to deal with because of that. Also, there was talk on how to deal with the old management and how they collaborate to spread the knowledge of Scrum within the client.

   A very hot subject was the possible recertification as CMMi 5 while using Scrum and their fear that the evaluator might influence too much the result. Traditionally, to prove reaching certain criteria, the evaluator requires documents, and some of the kpi are addressed in Scrum with meetings.

   If you have the time, check out this presentation.

   This lecture was a mystery to me. Every time I talk about distributed version control, the discussion always gets down to backups and making the programmer more prone to committing the source often.

   Distributed source control gets the programmer in a mindset to synchronize with the server less often because he doesn’t have too. He only has to synchronize to get into an integration test or a specific build.

   I was wondering how did they embrace it and live with this? And the answer was: they do not. The distributed versions all reside in a central server, so the commits are all done in the server as well.

   They also demand that the stories are shorter in terms of time so the programmers have to synchronize more often.

   What I got out of this presentation is that GIT (or Mercurial) have better features to deal with merges, diff , etc, nothing more.

   I liked very much to finally meet Boris Gloger. I have heard a lot about him from the guys at since the time they started Scrum adoption there and I was curious.

   The presentation was very good, I think I know little about retrospectives and I think the presentation brought us very valuable tips. I used some of it on the very next day when we had a Retrospective here in Concrete.

   I was somewhat disappointed with one of the side discussions during the presentation. When talking about quality items on the making of the product, using refactoring as an example, he said that the team should just do it and there was no need to tell the PO about it.

   I asked him directly about transparency, and what he said was that the PO cares about “Done” and this does not concern him (or something in this line of thought). There was also a quick suggestion about telling the PO you’re working on some of the items of the Backlog.

   I understand that sometimes the team can do some tasks underneath the PO’s radar and that it can be easier than having to explain to the PO what is going on, but, imho, a lie is a lie, and even those tasks should be discussed with the PO openly.

   I think nothing should be hidden whenever possible. And if the PO, having the ability to choose, chooses wrong, it’s our job to live with it. To try to help him make better decisions and not deciding it all for him in the shadows is our role.

   I would rather tell the PO that the refactoring is necessary, why it is necessary, and let him know we are doing it.

Scrum Gathering Lectures Part I


In this post I continue my comments on the lectures I attended to at the “Scrum Gathering 2009 Brazil”.

  • Scrum e a crise mundial: Por que Scrum é a melhor opção para projetos em tempos de crise  – Rafael Sabbagh PUC Rio and Marcos Garrido – Palm I (Morning Session of the 12th)
       The presentation seemed closely related to the future dissertation of Rafael Sabbagh and Marcos Garrido, both doing their Masters in PUC Rio. The main line was that Scrum is easier to sell to clients in times of crisis, and this is a particular good time to do that.   On the good side, it was one of the few presentations with low demand on the knowledge of Scrum from the people watching. The bad, in my opinion, was that the presentation did not really define itself as being directed to clients or as being directed to the sales force. I also missed the traditional graphic with the ROI over time.


The early delivery of value by using Scrum.   

The early delivery of value by using Scrum.

   I also think that the theme itself is very relevant but kind of bold because the presenters are not from the sales department. As a personal, very personal choice, I would not dare do this without most of the slides coming from the commercial department.
   After the presentation the discussion was very good, and kept going and going, no one wanted to leave the room.

  • Keynote Address – Ken Schwaber, co-founder Scrum & President Scrum Alliance – Grand I & II (Virtual Presentation)
       It was one of the usual presentations from Ken Schwaber. Usual to him, awesome to the rest of us! The crowd went wild when in a question (pinning Ken versus the PMI presentation earlier) where Ken answered that the project was done by the ProductOwner, ScrumMaster and the Team, so, there was no place for a Project Manager. 
       Of course the ScrumMaster is a Project Manager, but it was a great stunt that few are capable of pulling out. There was lots of cheering in the audience here.
    We also did the command & control exercise following Ken’s instructions. It was done to illustrate the power of self-management, and this often gets me thinking that at the end of the day Ken is all about being ethical in the workplace. The exercise itself was kind of awkward because most of the audience had done it already. 
    Bottom line, if you get the chance to see him speaking, don’t miss it. It’s simple, not pretentious, very valuable and, to some extent entertaining.

  • Usando DoD (Definition of Done) para amadurecer a qualidade do produto  – Gustavo Coutinho, Provider, e Luciano Felix, CSP Especializa Treinamentos – Palm II
       This presentation was about the Definition of Done and it’s correlation to the technological deficit created during the execution of most projects. The approach of the presentation seemed to follow the actual thinking process the guys at Provider Sistemas went through it respect to the DoD.
       It makes it look tough, like the Definition of Done became a major item for them as can be seen on slide 31 with DoD at the center of the Scrum Activities. My view is that they like this part of Scrum best and it really works for them.
       In the presentation there is a suggestion of DoD multi-levels where there are requirements for the tasks, the Sprint and the Release. My view is that the DoD levels referring to the Sprint and the Release should be tasks, and enforced by the ScrumMaster because it relates to the company culture. Generally speaking, these are technological deficits that they think make sense grouping by each Sprint or Release. This is the case of a full integration of the software where they might do it only once in a Sprint.
       In any case, my observation does not mean any change in the actual tasks, only on how to call them because they “made up” a new taxonomy where as in my view there was no need to (If it works, that’s what matters).
       On the second part of their presentation, they introduce one group dynamics exercise designed to find out good items for the DoD for a project or as standards for a company. It’s really worth a look. Check out their presentation on the link above.

PMI at the Gathering


   The day of the 12th (May-2009) started with the opening speech of Jim Cundiff, the Managing Director of the Scrum Alliance. Nothing too big about what was said, but I see as very big that he was here. To me, this shows that the Scrum Alliance is really interested in Latin America and of course in Brasil.

   After his brief presentation, Ricardo Vargas took the floor. He is “only” the chairman of the PMI Board (2009). Again, here, the thing that had my attention was the fact that he was there! As PMI sees the growth of agile projects in the US in the IT Business, economic interest can be more clearly seen.

   It seems that in the US, (self-denominated) agile projects (in IT) are now more used than the projects with heavier or more traditional approaches.

   His presentation was more about PMI than about Scrum. It was clear that he knew very little about Scrum. He seemed to know that it was lighter, and that teams are self-managing. When talking about the PMI and the PMBok, he was trying to be clear that the guides are not rules; they are recommendations on practices that the organization thinks will work. His message was in the line of: “Use whatever works and gets results!”

   Underneath, with this strategy, the PMI is trying to make agile or empirical approaches a leg of their guides. Today, the PMI and the ScrumAlliance are certainly aligned, but on the long run, it looks as if the PMI is looking to absorb Scrum. Today, the ScrumAlliance wants the PMI stamp, and the PMI is looking at all this market that is trading management practices. The hidden message is that PMI will accept agile when the rate of change is higher. I felt the hidden message was that Scrum is good for software and programmers, but if you need an Oil Platform, or have a Billion Dollar project, call me.


Ricardo Vargas, chairman of the PMI speaks to the Scrum community.


Ricardo Vargas, chairman of the PMI speaks to the Scrum community.

   One of the more polemic topics was the self-management of Scrum Teams. Ricardo said that he has never seen a team that would be productive without someone telling them what to do. In his view, 90% of people would do nothing without being forced to. He sure made clear he was talking about his personal experience. My personal view is that his vision is probably accurate for construction work or a work where you take a black liquid out of the ground to be burned, but programmers do intellectual work and it may be different in the IT business. My view on this is certainly more naïve or romantic, but I can live with that.

   PMI is, and will continue to lead in project management guides and skills. Empirical and Agile methods will start to be a part of the PMI teachings and the PMBok, that’s for sure. Traditional project management and heavier methods will still dominate and be effective whenever the requirements are in control, and change is not as significant as it is in our industry.

   Of course, as software penetrates more and more every aspect of human life, and the pace of change increases, it is very likely that the Agile methods will expand and become dominant in the future. Time alone will tell.

This was certainly an exciting morning!

Scrum Gathering Brazil 2009


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 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.