Archive for the ‘Posts in English’ Category

Back to Basics (The Scrum Team vs. The Team)


Recently I’ve taken the new Scrum self-assessment available at

I have seen many people missing some basic answers and that got me concerned about the knowledge on the basics of Scrum in general. At this moment, the average score of the assessment is at 78 with a standard deviation of 6.5.

With this in mind, and having scored on the 95 percentile myself, to me, a surprise, I decided to step back from the “Team Series” I was writing and start a series addressing some of the basic concepts, and maybe help people that are starting and eager to learn.

Also, I advise the reading of the Scrum Guide for very valueable information.

The Scrum Team is the set that has all the basic roles necessary to use Scrum in a project. The Scrum Team is composed of the Product Owner, the Scrum Master and the Team.

There is no formal management role in Scrum. The Scrum Team shares responsibilities for the project. The traditional management position has it’s responsibilities split among the Team, The PO (Product Owner) and the SM (Scrum Master).

The Team in a Scrum Team is composed of the guys that will actually build the product. This should be a heterogeneous group of people with all the skills necessary to deliver the goal of the project.

The Scrum Team should be composed of 7 people plus or minus 2. The Team in turn should be composed of 5 people plus or minus 2.

The Team is responsible for planning how to meet the goal of each Sprint, monitoring and optimizing the work to meet the Sprint goal daily, monitoring and increasing productivity, resolving its internal conflicts.

The Team works on backlog items until there are done, accordingly to what they told the Product Owner they would do.

The Team is required to participate in all of the Scrum ceremonies. They need to be in both parts of the Sprint Planning, in the Daily Scrums, in the Sprint Reviews and in the Sprint Retrospective.

Only the Team in a Scrum Team can determine how to deliver the product. They are the ones with the skills to deliver and they are responsible for the how. The Team itself is responsible for its own destiny. As they self-manage to deliver the Sprint items, they are responsible for their success or doom.

The Sprint Backlog is owned by the Team. They decide what are the tasks in it, and they update its status.

The Team communicates directly with the Product Owner and other people needed to build the product. There is no need for anyone to act as a go-between for Team members.

The Team should act with diligence and sense of urgency. As an example, whenever a change is needed on the plan for the Sprint, represented by the Sprint Backlog, the change should be done and tasks added or removed as soon as the need is identified, immediately.

The Team decides when it is appropriate to change to update the Sprint Backlog during a Sprint. The Team is the owner of the Sprint Backlog. The SM and the PO do not own the Sprint Backlog.

The Team is responsible for estimating tasks together. The PO and SM have no say in the estimations. The Poker Planning is one of the ways of getting all of the Team members to participate in the estimation process.

The Team should not develop a full plan for the whole project nor should nail down the whole architecture and infrastructure upfront. The Team should leverage Scrum’s Empirical way to its advantage.

The Team should adjust its use of engineering practices whenever needed.

The Team in a Scrum Team is very different than the teams in a command-and-control structure. In Scrum, The Team is empowered to do its job.


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.

Building a Team (part I of endless)


One of the first tasks of someone that wants to build a good team is understanding a little bit about what makes a team successful elsewhere.

Also, while observing, there must be a conscious knowledge that a strong correlation may not mean a relationship of causality.

A small team is a factor seen in most successful teams. Teams with 9 members or less seem to be in general more successful than larger teams. The team size has a strong relationship with a good team.

The real cause for this lays in the easiness to manage the communication between the individuals. As the size increases, it is increasingly difficult to manage a good link with the other team members.

To have good communication within the team, it is very important that the members of the team know who is in the team and who is out.

This is related directly with the concept of pigs and chickens seen in Scrum. The pigs are the committed team members. They are onboard with the team. The chickens may help, but they are not in.

The pigs need to know who the pigs are, and the chickens need to know who they are. It may seem silly, but the lack of clear delimitation of these boundaries for the team will do more harm than any perceived good.

People on the team should form a real team. They should want to be on the team, and they need a common goal.

This goal is going to be the glue that will get the team moving together. Without it, the team members will show a natural tendency to follow their own paths. And if everyone just follows their own interests, there is no teamwork possible.

To achieve a common goal, there are many paths. To common goal can come from a leader, from the team itself, from an outside element, etc. What is most important is that pushing to set a common goal is a difficult job.

Setting goals demand taking responsibility. And taking responsibility can be a risky action and demands emotional involvement.

To be continued…

The Myth of the Team


The concept of teams is one that is widespread viewed as good and taught by parents and in the schools from the very early days of almost every child.

There are many reasons for this culture that have nothing to do with how much better teams work when compared to individual efforts. It is all about getting the young to learn the concept of the other, how to live with the differences, and how to deal with dysfunction and conflict.

A single person can be productive, and also, can have many problems. Putting a group of people together also mean that the possibility for problems is multiplied.

In general, teams will find a stable situation, they naturally seek equilibrium in the relationship of its members in a way they can manage to live together. This means avoiding conflict at almost all costs. People will try to find a comfort zone, even without thinking about it.

The big problem here is that the continuous generation of conflict and resolution is what makes a team more productive than individuals.

Also, conflict is dangerous because it can break the bonds that keep the teams together. Too much conflict destroys the team, too little and the team will produce nothing good.

The team dynamics reminds me of a history book by renowned Helio Jaguaribe (Um estudo critico da História). In this book, he demonstrates by looking at the many different failed and successful societies in history that one of the major factors of success is the good challenge. If the challenge is too great, society is destroyed. If the challenge is too little, society will fall into a comfort zone that stops it in time and will render it unprepared to deal with future difficulties.

The teams are a micro cosmos of society, and like societies, a team needs a good challenge and good conflict to thrive.

The goods of teamwork are not given. It is not by simply putting people together that they will be better together than they are in the sum of their individual efforts.

To find good teams, one will see that there is always a factor that “rocks the boat” when conformance rises, and something to bring a gentle breeze when people are about to kill each other.

To purposely build a successful team is even harder than “finding them in nature”. It is not a task to be underestimated.

Continued here…

Bond, Scrum Bond


I have seen many times companies or professional teams that claim to be like a family. Being like a family is associated with success almost everyplace I have been to.

There are many reasons for this association. The proximity and intimacy of a family is associated with openness and good communication. The family love is related to the unity that connects people in an organization. Blood ties relate directly to self sacrifice towards a common goal, the goal of the family.

All these are perceived to have value and indeed can be a very positive influence on other organizations.

Now, considering the other aspects of a family, there are many dysfunctions to be avoided as well. Paternalism is one of those patterns. In the search for proper teams, management gets carried away and wants to become parents. Mutual proximity of peers can easily become condescendence and intimacy may become discomfort.

What is really important for companies, teams or families is not how things are organized or what is produced. What is valued should never lay in the rules (dogma).

Being a family, or doing Scrum can only be good if what you experience with it is good.

It may sound strange for some, but every time I hear from people that my company is like a family I have mixed feelings. The company does not seek that at all. I guess when a company value openness and collaboration the way we do (or try to do), the association can be inevitable. I think the main reason why Scrum fits well with us is because we value similar things in the first place.

To do Scrum is very much to be aligned with the original Agile Manifesto. To understand Scrum and to do Scrum is far from following a set of rules. In its core Scrum is pursuing some very basic values.

To do Scrum one needs to understand the people involved in projects as people and not as resources.

To do Scrum one needs to seek to generate tangible value. It’s a professional and ethical commitment with oneself.

To do Scrum one needs to communicate with others openly and value it.

To do Scrum is to adapt oneself to reality.

To do Scrum is to ask oneself many questions.

To do Scrum is to value teams with a special bond.

The Good, The Bad and The Ugly Product Owner


If you have not seem “The Good, The Bad and The Ugly” (1966), now is a good time! I think this article is valuable anyway, but will probably make more sense if you have seen it.

Angel Eyes is a ProductOwner at One Man Army Inc. He is an ambitious manager eager for a promotion and to grow in the ranks of the company.

Tuco is a ProductOwner at Texas Inc. He has some ambition, but his main concern is to save his own ass. He was brought from Mexico Acme for a good sum, and he does not want to loose his job, that’s his main goal.

Blondie also works at Texas Inc. He is ambitious but has also a good sense of commitment with the company and his colleagues.

In any project, there is an underlying conflict between the personal interests of the PO and the interests of the company in which he works. A ProductOwner will always have a personal agenda in projects.

A ScrumMaster must be watchful and try to identify what are the misalignments in the interests of the Stakeholders and the interest of the ProductOwner in order to achieve a better success rate in delivery.

As a ScrumMaster you have to be very mindful of what type of ProductOwner you get.

Angel Eyes is very ambitious and only thinks on himself. He is likely to disregards how risky some of the items in the Product Backlog are. He seeks greatness blindly. Angel Eyes will probably end up dead.

Tuco is scared for his job, and is likely to disregard how much value an item in the ProductBacklog may generate for the company if that item carries a risk. He will not take any chances and wants easy wins. Tuco will end up alive, but penniless.

Blondie is ambitious, but his commitment with the company shows up. His interests seem to be very much aligned with the company and he is more likely to be a good ProductOwner. Blondie will finish alive and with the dough.

In any case, a tool a ScrumMaster has to mitigate the potential misalignment of interests between the Stakeholders and the ProductOwners is through transparency.

If your PO does not care about risks, give focus to spread this information. If your PO is scared and misses ROI opportunities, be sure to inform all involved that there is a prize to be taken. If your PO seems aligned, insist on Transparency so he won’t loose track.

A well informed Stakeholder is likely to leverage his influence on the PO to consider risks and take advantage of opportunities.

Transparency, transparency, transparency…

The Tao of Scrum (refactored)


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?


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)

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.