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.


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)

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.