About TC

I've been working with ThoughtWorks as a consultant since March 2011. I'm young enough to have started when "Agile" was already widely accepted and, this way, I practiced it in my whole career so far. I look for ways to improve the way my teams work and I don't like purism at all. Instead, I think we should always analyze and be critical about the possibilities ahead of us - even the ones that are given as obvious. We should change the process as much as we find necessary, and think of others' previous experiences just as a guideline to improve it a step further.

Why I think that Agile Brazil 2013 was great

Hey friends,

Last week I was in Brasília attending this year’s Agile Brazil. The event had over 1000 participants and is now the biggest conference in South America. It was great to see so many people engaged in the discussions and sharing their experiences – besides technical subjects, there were many reports from people that are introducing agile in their companies or have the mission to transform a big organization and make it agile. There were also some hands-on sessions about facilitation techniques and even some live coding. Finally, some discussions about management gave me hope that there is someone out there thinking about it and looking for improvements to current methodologies.

What I liked the most about this event was the opportunity to meet more experienced people. I realized that there are many out there trying to do the same agile transformation as I am with my clients, and they have been trying it for way longer than me. I heard some stories that made me rethink many of my assumptions about why people work the way they do. It’s refreshing.

I started my participation on Tuesday, June 25th, facilitating a retrospectives workshop with Paulo Caroli. This was a full day hands-on session, where we presented different kinds of activities and the group of participants facilitated most of them. Counting energizers, check-in activities, data gathering and futurespectives, we ran 43 activities.


It was an amazing experience for me, and I was impressed with the group participation and all the discussions and suggestions. Everyone learned with each other, and our activities were just guidelines and drivers for great conversations. This was our first time giving the workshop with this format, and I’m looking forward to use the feedback we received to improve the next runs. By the way, thanks to everyone who was there, and also to Caelum which provided us a nice room!


Now, talking about the sessions I atended.

Pat Kua started the event with a keynote about Unlocking Our Human Potential. Nice talk where he shared his previous experiences. Biggest conclusion I took is: people perform the best when they feel valuable and challenged. How to achieve this, however, is the topic for a complete different conversation.

After that I attended a talk about why is it hard to motivate people and what can we do about it. I had to leave midway through the talk because there was a very interesting one about to start: there is no agile without agile design, given by Eder Ignatowicz. Eder’s talk was by far the most entertaining I watched and probably the one I most relate to. He talked about how agile teams usually follow the motto “go ahead and make it work”, trying their best to make it work nicely, but usually don’t take a step back to ask themselves “Are we evolving this codebase in a sustainable way?”. Very well spoken and I liked the questions asked at the end. I strongly suggest people to watch this at other event if they ever have the chance.

Then Aniche talked about code metrics. Nothing new, but I liked the way he exposed the subject, specially considering that there were many people there that wanted to learn about it and maybe implement in their companies: you can’t say that a codebase is good only based on metrics; neither can you say that it is bad. They are just indicatives that you should pay attention to. In the next day, Aniche and Hugo Corbucci had a discussion about when to mock or not mock. Very interesting conversation to watch.

Speaking of interesting conversations, the guys from Lambda3 gave a very inspiring talk about organizational democracy, followed by Fabio Pereira talking about cognitive psychology in the agile context. Again, I strongly suggest anyone to watch these if they have the chance.

After that I was in the mood to watch more non-technical talks. Claudia Melo talked about the big secret to make an agile team successful and Paulo Caroli talked about seven ways to keep lead time under control. I’m suspect to say, since I work with them, but I believe that a lot of people in the event learned very useful stuff with them :)

In the last day, there were very good experience reports from people doing agile in different contexts (here and here). Unfortunately, I couldn’t watch them all because they were at the same time slot :(

Finally, Paulo and I gave our talk about one week inceptions, a mix of experience report and the proposal of a methodology that has been working well for us. We received very good feedback and had good participation; the crowd asked good questions at the end and the follow-up conversations were very interesting. I’m looking forward to give a talk on this topic again. Also, a brazilian version of ThoughtWorks Anthology is about to come out and we are putting up a chapter there about this subject, with many more details than we could share in a 50 minutes talk.

So, yeah, going to Agile Brazil this year turned out to be a great decision for me. Learned some stuff and met some amazing people. Giving the retrospectives workshop was definitely the best part of my trip, and I hope that we get more chances to apply it again. And, surely, I look forward for the next opportunities to meet more agilists and share our experiences.

If you were in doubt this year and ended up not going, reconsider the decision and go next year. I heard some rumors that is going to be in Floripa… :)



Retrospectives: A Valuable yet Misunderstood Ritual

Hey friends,

Retrospectives are a valuable ritual to have as a team, but can be quite misleading when not properly executed. I often see teams going through what they call an agile transformation, and one of the most important rituals for them is the retrospective[1]. Only that, unfortunately, it isn’t really a retrospective – it usually feels like a collection of reports, with some blame game in-between.

I like to think of a retrospective as a continuous way of improving the way a team does work. It may sound obvious to some, since continuous and iterative improvement is the core of all this agile thing, but it’s worth reinforcing the point. Ideally, a team will have open communication and will discuss problems as soon as they arise; and also, team members will often look for improvements to make their daily life easier and to deliver better products that will make the client happier.

It all sounds great in theory, but in practice it can be difficult to do: sometimes the team is too large to communicate well enough; sometimes the team is not mature enough to talk about problems openly (this is the case where the blame game begins); and sometimes there may be just so much to do that we never stop to think about how to improve it. There are things we get used to and just accept, thinking “this is the way it is”, as much as we try to not do it. This is what retrospectives tackle most effectively, in my opinion, by keeping the team on track and pushing everyone to think and discuss improvements. Teams need to be critical about their own work, otherwise they just get stuck and become part of the process.

In Agile Retrospectives: Making Good Teams Great, Esther Derby and Diana Larsen propose the following retrospective structure:

1. Set the stage
2. Gather data
3. Generate insights
4. Decide what to do
5. Close the retrospective

As a facilitator, when setting the stage I like to talk about why are we gathering together and what’s the structure we will follow, restating the retrospective goal. I didn’t do this before, and I often found team members giving me feedback saying that it helps a lot to know what are the retrospective activities before we start. This way, people keep focus on what they are doing, rather than thinking “Is this the moment to talk about it?” or “When are we deciding on actions?”. This is also a good moment to remind everyone of the prime directive, and I cannot reinforce enough how important it is to say this out loud before running any activity (and keep the message visible on a board so that the team sees it during the retrospective):

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.[2]

It’s is also a good moment to invite everyone to talk. It may sound silly, but people will feel more comfortable to speak in the retrospective after they are invited to talk the first time. There’s one exercise I particularly like, which is to ask the team to describe the previous iteration (or period of time since the last retrospective) with one word. This fulfills the purpose of having everyone talking, without occupying much time but still giving valuable data about how the team is feeling. Depending on what’s the outcome here, it may be worth tweaking the next exercises to help the team to surface the pain points.

Screen Shot 2013-04-23 at 10.39.36 AM

Next, there is the Gather Data stage. The goal here is to have the team sharing their views about events and facts. Naturally, each person will have a different perspective and will feel differently, even if they faced the same issues or challenges. Some facilitators try to focus only on actual events and leave the feelings aside in this stage, but I hardly think that anyone will be able to describe facts without biasing them with their own point of view[3].

I’ll talk here about two activities that I like to use and work very well together[4]. First, I run the Happiness Radar, and then I use its inputs to drive an activity that Paulo calls DAKI. In the Radar activity, each team member is invited to put one vote for each of the following areas: People, Process and Technology. The vote represents if they are happy, sad or indifferent with that area.

Screen Shot 2013-04-23 at 4.16.03 PM

As you can see in the image above, a color code is associated with each of the areas. This is used for the DAKI activity, where the participants are invited to write down practices that they think the team should Drop, Add, Keep and/or Improve. It’s interesting to see how clusters show up for each area, depending on how their “happiness score” is. Also, it surfaces quite well how the team is facing their problems: a lot of improve and adds may suggest positivity and new ideas, while a lot of post-its in Drop usually mean that there is a clear issue to handle.

Screen Shot 2013-04-23 at 4.18.03 PM

Following Esther and Diana’s structure, we would then get to the Generate Insights part of the retrospective. However, I don’t see this as a completely separate part: I personally start questioning the team while grouping the notes in the previous activity’s last few minutes. It’s natural that, while gathering data, people will look at each other notes and will speak up some thoughts. I think there is a level of control needed, so that everyone gets a fair time to think and write notes down, but I also like to watch how the team starts discussions without much interference. Nevertheless, after all notes are on the board and grouped, it’s time to talk about it.

What I’m about to say is true for the whole retrospective, but specially in this moment: all of it works much better when you have an external facilitator. It’s very common to have team members facilitating the retrospective (in my previous projects, usually the Iteration Manager), which isn’t inherently bad, but the discussions tend to be guided by their point of view – even when they are trying not to do so. Not only that, an external facilitator will often question things that the team considers obvious (or part of the process), instigating everyone to think about their practices and talk about them. I’ve seen more than once, specially in projects where people joined after they started, that some “obvious practices” where not really obvious for everyone.

A good facilitator will challenge the team and ask the right questions so that the discussion is productive, but I’m not saying that the facilitator will solve any problem. Actually, I consider a retrospective good when I leave it thinking about more practices and improvements than I did before it – not necessarily solutions. This connects to the next phase in the retrospective, where the team needs to decide what to do. Not much will happen unless the team gets to the actions.

Deciding which actions to take is a tricky exercise. I often see teams owning more actions than they can resolve in one iteration’s time, and as a result they lose belief in the retrospective. Sometimes, also, the actions end up being way bigger than they should – or even not clear enough. For instance, “decrease build time” is a fair thing to expect after a whole discussion about how that affects the team’s productivity. It is, however, a wish – not an action item by itself. How do you say it is done? If it decreases from ten minutes to nine, is that good enough? “make the build run constantly in less than seven minutes” is slightly better, but it sounds a little too abstract yet, doesn’t it? You may know what’s the end goal, but how to get there?

Screen Shot 2013-04-30 at 11.13.23 AM

When deciding what to do, the team should pick items that they can accomplish until the next retrospective. They must be specific, measurable and realistic. The team should be able to treat them as user stories – and actually, following up on their progress in stand-ups is a good way to remember that they are not just ideas. They can be cards on the wall. Coming back to the build time issue, one way to tackle it would be “Change the build scripts so that they run in parallel”. But can the team do that in time? Is there a dependency with someone from other team? If that’s the case, is it useful to narrow it down to something like “Setup a meeting with Jacob to discuss build parallelization”? That’s something for the team to decide, and the facilitator role is to instigate this discussion.

Once the team has actions and owners, it’s time to close the retrospective. Action items should have owners and must be exposed to the team visually in the next days – maybe on a flip chart, or on the story card wall if the team decides to deal with them that way. Everyone’s time must be appreciated and, of course, it’s good to take some time to check what went well and what can be improved in the retrospective itself. Hopefully, the team will have a better understand of their problems and some food for thought.

Now, coming back to the beginning: why did I say that retrospectives are misunderstood?
Because they are nothing more than a checkpoint for something that a great team does naturally every day: continuous improvement. Adopting retrospectives just because the book says so isn’t effective. Any structure or exercise is only a guideline, because in the end who makes the retrospective effective is the group of participants. This is a practice that should come from the team.

Maybe this is a good topic to cover in your next retrospective ;)

What are your thoughts?


[1] The top 2 rituals are daily stand-ups and user stories, also often misunderstood. ^

[2] http://martinfowler.com/bliki/PrimingPrimeDirective.html ^

[3] The 6 thinking hats is a very good exercise to separate facts and feelings, and also pushes the team members to think differently. However, it can be very time consuming and it is not an easy one to facilitate. ^

[4] All credits to Paulo Caroli’s activities catalog, a great reference for any retrospective facilitator: http://agileretroactivities.blogspot.com.br/ ^

Agile Coaching [Rachel Davies, Liz Sedley]

Hey friends,

As a consultant, the biggest part of my job is dealing with people. I read Agile Coaching (http://www.amazon.com/Agile-Coaching-Rachel-Davies/dp/1934356433) willing to discover techniques to get the best out of my teammates, and also to help me to introduce new ideas organically, without forcing them down on the team. With the perfect team, I’m sure everyone would be self sufficient and would try to understand the context to then try to improve it; however, in reality, most of the times people are blinded by their beliefs and need a little push to go forward.

Even though the book is very basic in many senses (most of it feels like a review of fundamental concepts that I would expect the reader to already know), there are quite useful parts where the authors share their own experiences dealing with the implementation of agile practices in non-agile teams. They present situations that I face often and it is interesting to see how they dealt with it and what was the outcome. Besides that, there are good tips that are useful for any consultant.

A very good point that is made throughout the whole book is that a coach should not solve problems for the team, at least not hands-on. As the authors say, it is hard to make the shift to giving advice rather than playing an active role in getting the work done. This is something I struggle with often, facing situations that I know I can solve, at the same time when I’m trying to push the team to solve it by themselves. It’s hard to find the balance and I believe that it comes with experience. Paulo Caroli[1] once told me “ideally, the team won’t even notice I’m here. If it comes the time when people have to seek for my help proactively, then there’s something wrong”. I believe it relates to this.

Another skill that needs attention when dealing with any team mate is the ability to listen. I noticed that it is not only important because, well, you have to pay attention to what people are saying anyway, but also because it helps to build a stronger relationship within the team. When you show you care about what your peers are saying, it’s likely they’ll start to trust you. Making people feel comfortable to talk about the problems they’re facing is fundamental so that a coach can help them. A good technique to achieve this is asking open-ended questions – “What were you trying to do?” sounds much less accusing than “Why did you do that?”.

A coach must also be able to deal with conflicts. I’ve seen many agile teams joining projects in which people have been working on for a while already, and then pointing what should be improved and how (“Oh my god, I can’t believe you guys are not pairing, not doing TDD and not following the As A … I want to … So that … format!”). Now, this is a much broader subject than just coaching, and it goes deep down on consultancy techniques. However, in their book, Rachel and Liz suggest an exercise to help surfacing these disagreements: instead of pulling “yes or no” answers from the team, look for gradients for agreement[2]. Put options on the board that go from endorse to block; help the team to distinguish a wholehearted yes! from a whatever, a I’m not so sure from a no way!. The gradient scale enables the team to see when there is lack of consensus, without reducing the situation to a simple DO or DON’T.

Something fairly obvious, but which might be worth mentioning anyway, is that a team needs reachable but challenging goals. If work is too easy, people get bored and demotivated. If it is looks impossible, people get too frightened to reach for good results. Part of a coach’s role is to help identifying a compelling goal and find manageable chunks of work so that the team continues engaged. Sometimes, the team is motivated by the product they are building[3]; sometimes, by the technology. There are numerous drivers for motivation, and a coach needs to be aware of what the team is looking for to be able to keep everyone on track.

Now, I’ve been talking about what to do as a coach, but it is also important to be self-aware and do not microcoach. No one likes to work with people who always want to know  everything that’s happening, or people who often give advices such as “don’t forget this” and “don’t forget that”. People need space to evolve. The team must have the opportunity to fail, and then learn with the mistakes. If there is always someone in the team who reminds everyone of what should be done, and is always trying to prevent possible failures, the team will end up relying on that person too much. From my own experience, I believe that people learn the most when they actually try their own ideas, analyze the results and then act on it – and that’s where a coach should act: helping people to go after their ideas, and helping them to realize what consequences they are facing and how to improve. Ideally, the coach figure in a team will disappear over time and the team will keep performing their best.

What are your thoughts?


[1] Paulo’s Agile Tips blog ^

[2] The exercise is originally from The Facilitator’s Guide to Participatory Decision-Making (http://www.amazon.com/Facilitators-Guide-Participatory-Decision-Making-Kaner/dp/0865713472/). ^

[3] I’ve seen this often happening in ThoughtWorks, where a lot of good work gets done by people working on Social Impact Projects in their free time. You can find more information here. ^

Being an effective Inception participant

Hey friends,

Recently I’ve been in two inceptions, one with a distributed team and another one with the whole team on-site. Before that, I’ve been to some meetings that people called inceptions, but I refuse to comply with people who call “looking at a spreadsheet to review previously written stories” as “inceptions”.

In all of them, a few team members were not sure about how to participate effectively and what was expected from them – so I’ll list here some thoughts that might help anyone going to an inception for the first time (and also experienced folks who are looking for ways to improve).

First of all, participating in an inception with a distributed team is a whole different experience. It’s way harder for the team to visualize the information gathered, which reduces active participation. Besides getting very boring, it’s just plain ineffective to try to run a distributed inception with the usual format, just looking for ways to make it look like it isn’t distributed at all. You need to go beyond that. I’ll write a post specifically on how to make distributed meetings more effective some other day, along with some alternatives on how to use different locations (and possibly different timezones) in your advantage.

Now, coming back to the inception topic, regardless of being on-site or remote. Prepare in advance. Read everything you can about what will be discussed and start thinking on how to solve possible problems. If you have an idea over what will be the project’s scope, talk to your coworkers about their experiences with similar projects. If possible, meet the inception participants before it starts: build relationships early on and get that team feeling as soon as you can. Start the discussions and present your ideas to everyone before the inception even starts, if you have the chance. Push the team to discuss the inception format before it starts.

There isn’t a checklist on what you need to do in order to help the team once the activities begin. However, if there was one, the first point would be:

Take notes of everything

Regardless of the activities your facilitator comes up with, there will be always information flowing and not being gathered. There is always that product owner who talks a lot and throws many ideas out in the open. There is always the architect or subject matter expert[1] who shows concerns on how that new feature will fit in the current system. There is always that stakeholder who doesn’t quite know how to explain what’s the organization longer term goal, but somehow expects you to understand. You need to take notes of all this information. It’s difficult to filter out what’s useful at the moment or not, so capture everything. Have post its, index cards and pens[2] and write it down. Don’t be afraid to ask if what you wrote down is correct, or to narrow down that information and make it specific.

The goal here is not to capture the absolute truth and document it. It’s to gather information. To be an effective inception participant, you need to understand the context and be able to discuss it. Use the breaks between sessions to go over your notes and remember what was said. Then, you should be more capable of coming back with questions. Ask everything! I believe it’s needless to say that you should question everything the whole time. Don’t accept just the -what-, but look for the -whys-. I’ve seen product owners unable to justify why they needed a tool, and instead just had in their minds how the tool should look. Surfacing the reasons for building something early on helps a lot to drive the discussions to what is really necessary.

Other very powerful use of “taking notes of everything” is to capture assumptions. In an inception, you’ll often hear “yeah we should do this assuming that <fill any crazy or unlikely possibility here>” or “this is easy because <insert thing that doesn’t exist here> is done!”. It might sound silly, but often features are designed and user stories are written based on assumptions that are not true, and won’t be any time soon. Don’t consider anything said as -true-, consider it as -assumptions-. Write in a post-it and put on the wall, and don’t be afraid of referring to it in later activities.

Now, I talked about gathering information to become a more capable team member, and also about capturing assumptions so that the team doesn’t fall in a hole of insane and unrealistic scope. There is another thing which deserves full attention:

Make the information visible

Share your notes with the team. Make them visible. Put them on the wall, white board, flip charts, or just lay them on the table in a way that everyone can see (this is the essential part where being distributed becomes a huge problem). When people see what you’re writing, they begin to understand what YOU are understanding, and the discussion goes a step further.

I can give a real example on how this helped the team in my previous inception: We had a Product Owner who talked a lot and assumed that everyone was following (which wasn’t the case, since some people didn’t have all the context behind his ideas and even not being a native English speaker was a barrier for some). People would, then, write down notes that just didn’t reflect what he was saying. He quickly understood that he needed to slow down. He then started rewriting the notes himself. This was awesome for two reasons: it helped the team to clarify their doubts without directly interrupting the conversation[3]; and it made the PO to engage and write stuff himself, making accurate notes that were referenced throughout the whole inception later. Also, when we started activities to write stories, it was already natural for him to write them down with his own words.

Also, you should be aware that much of what you write needs to be thrown away (either for being wrong and corrected in a different note, or just being redundant). I really like the exercise of going through all the notes on the wall by the end of each session, reviewing if what is there is valid and clarifying open questions[4]. If there is anything out there that is just not needed anymore, don’t be afraid of removing it[5]. Ideas evolve during an inception, and sometimes a note from the first day is not true anymore on the third. However, be aware of not losing assumptions on which the project depends, and to not lose the notes where the true intention or necessity of the stakeholders is described.

One point I didn’t mention about making things visible is the use of projectors or previously drawn diagrams. I strongly believe that, in an inception, the team should understand the problem and build the solution together – and bringing anything previously done goes against this. However, there might be existing architecture diagrams or even mockups of what the solution should look like in the future. I suggest keeping this to a minimum and, when it’s needed, just refer to it – and not make it a fundamental part of the discussion. What I’ve seen previously is key stakeholders coming to inceptions with all their ideas written in a spreadsheet and just reading them to the team. -This is not how inceptions work-. However, it’s important to not throw their ideas away. Instead, while they go over their ideas and everyone just watches, start writing stuff down and make it visual. Change the flow of the meeting. You don’t need to shut down the projector, but you can surely change the flow and engage the whole team.

Run the extra mile

Even though pieces of what I wrote here might sound like a facilitator’s job for some, I strongly believe that the whole team should actively participate and make the inception happen. I don’t like to see “roles” in inceptions[6]. Everyone should to their best to understand the “business needs”, to clarify that and to build a realistic plan that makes sense.

It’s exhausting to think about activities, make them happen, understand the needs, capture them, clarify questions, think about technology, discuss architecture, see where your project fits in the organization, who you might need to finish it, among many other things you will discuss in an inception – and most of the time, all of this points come at the same time. It’s not a one-man’s job. That’s why there’s a team. Support each other.

Of course things will change when the project starts – people will have new ideas, some dependencies won’t be fulfilled, the team might change… It happens. A successful inception is the one that minimizes the gap between “the plan” and reality.

What are your thoughts?


PS.: Make sure all your inception artifacts are well taken care of after the inception ends. All flip charts, drawings, post its and pictures should be easily accessible for the team throughout the whole project. It’s not just something to remember the good old times: it is also a matter of saving all that useful information and being able to come back to it.

[1] Even though roles such as “architect” and “SME” are not agile-ish, from my experience is unlikely that you will participate in an inception for a whole new project, in a green field world. Most of the times there will already be an existing system, and thus, there will be people who own part of the knowledge. ^

[2] Help the facilitator. Bring material to the room and share with the whole team before the meeting starts. Don’t be the only one taking notes – instead, give everyone the option and tools necessary to take notes. As the time passes, it’s likely that people will join you and will stick post its on the wall with their notes. ^

[3] Specially when working with inexperienced people, you need to be aware that sometimes they don’t even know if they should understand something or not. They might get intimidated and leave the conversations with a lot of questions unanswered. Having the habit of writing everything down naturally helps these people. ^

[4] You might want to move the open questions to a Parking Lot and discuss them in a separate session, due to time constraints. However, if there is any outstanding question or issue, follow up with the team as soon as possible – it might become a blocker for the next sessions. ^

[5] Some people are sensitive and don’t like to see what they wrote down being torn apart and thrown in the trash. Be aware of that. ^

[6] In fact, I don’t like seeing roles at all in agile teams – but this is another discussion =) ^