My values

I have a pretty strong set of values. Values that I built over the years. I try, as much as I can, to use them as a guide in all decisions that I make. This is pretty easy when the decision does not have big consequences. It’s a win-win situation. It’s pretty hard though when the decision that I believe it’s right has big consequences. One could argue that in some situations it’s wiser to close an eye for your values and go to the more “sensible” option. I don’t buy that. I stand for what I believe. I prefer to be honest with myself (and with others) than doing something I might regret later.

It’s easier said than done. I have my skeletons of decisions that I regret or decisions I should have known better. The important thing for me is to be stupidly honest with myself. Honest about my achievements, about my wins but particularly about my mistakes and my losses (which are many). That’s the only way I know where I can sleep soundly at night and still improve as a person.

Many companies have their values published on their website. For some of them, this is quite important and a drive to do their business. So I thought I should do the same for me. Not only to other people to get to know me better, but also to keep me honest. To keep me accountable for the decisions I take on a daily basis.

So if you want to work with me as an employer/in an open source project/in a mentorship program you might find that a good read of what you will encounter. Now, without further ado, these are my values:

Tell the hard truth

This might sound obvious, but it’s not. I believe honesty is tremendously important in any kind of relationship. This is not only about honesty like “Don’t steal stuff”. This is about being honest even when the truth hurts. Be honest to say the hard things that people don’t want to say.

For example, I was on a project once where despite our best efforts we’re not achieving good results. People didn’t want to acknowledge that the project was failing. Failure is a word most people don’t like. But I said it. People didn’t like to hear that but doing that triggered a conversation that helped our team to go to a better place. Truth hurts, lies hurt even more.

Respect everyone

It does not matter to me if you are the cleaner that comes once in a week to clean the office or the CEO of a big corporation. I will respect you nevertheless and I demand the same. If respect it’s not in place in a conversation, I leave. No exceptions. No good will come from a relationship where mutual respect is not present. At the end of the day, we’re all people with our own set of problems to take care of. And neither you or I have the time or desire to waste with disrespect.

For example, when I was overseas I used to work in an office where the cleaners were treated like invisible people. People only interacted with them to request something but never talked to them as people. I used to greet them every day, even though they couldn’t understand much English they tried to make an effort to have a conversation with me. They are humans and deserve respect like any other. As a result of that, I received feedback from my peers telling me how they felt ashamed to not do the same and they started greeting them too.

Lead by example

I believe leadership is not a title, it’s a skill. For me, leadership only works if it’s by example. You cannot ask other people to be honest if you are not. You cannot ask people to treat others with respect if you do not. I also think leadership is a big responsibility and a leader needs to be held accountable by her team. I worked with many leaders through my career, the ones I respected most were the ones who cared about me and my team. The ones who were transparent and trusted their team to solve the customer problems while they were focused on fix the team problems.

For example, I was coaching a brand new Scrum Master in a big bank, the project was late in its schedule and the business was disappointed. In a private conversation, the Scrum Master told me he would force the developers to work over the next few weekend to get that done. I asked him to don’t do that. Instead, I said, let’s bring them together, show the problem to them and see what’s the solution they would come up with. I also said that I was confident they would come up to the same conclusion as he did and we should be prepared to help them to meet the deadline. We got everyone together and, unsurprisingly, the development team said they would need to work over the weekend. The Scrum Master was alleviated and let them know that for each day they would work on weekends, they would be able to take a day off between Christmas and New Year’s Eve. The product owner also managed to reduce the scope for the MVP making the developers life easier and still delivering business value to the client. A win-win situation. The team morale was higher after the meeting than before and we managed to deliver on time after all.

Challenge all the things!

I am a challenger. I believe continuous improvement is only achieved by constant challenges. Challenge ourselves, challenge our processes, challenge our assumptions. I particularly like to challenge processes or assumptions that have been around for years unchanged. Things move very quickly and if a process is stuck in time it’s very likely an old habit rather than a useful process. I believe it’s a healthy process where the outcome usually is pretty good.

For example, one process I usually challenge is retrospectives. In most places, they are always the same and lose value over time. In some places, there is no retrospective at all. I like to think I am a reasonable retrospective facilitator since I learned with the best facilitator Paulo Caroli! I facilitated a retrospective for a client once, where the discussion that happened was so good they actually were very thankful I jumped in and facilitated. Same team, same meeting, but with a different facilitator can indeed bring value!

Zero tolerance for bullies

That should sound obvious, but unfortunately, it’s not. It’s 2017 and it should be clear by now that bullies (or the famous brilliant jerks) are counter productive. They hurt the team performance overall, they centralise power and they make good people leave the organisation. Nevertheless, they are still out there. I don’t work with bullies. Period. No excuse, no exception. It does not matter if he (it’s usually a he) is the new Linus Torvalds or the most important person in the organisation. I refuse to have my mental health and others to be affected by it. There are many and many and many stories about how those people impact an organisation and drive the culture.

For example, I joined a company where I found out the most senior person on the team was a bully. A bully with capital B. He was consistently bullying people over the 10 years working there and also across multiple open projects where he never contributed with code – only opened issues. I, obviously, didn’t know before the first day. I talked to the HR which they said they knew about that, but he was untouchable. I talked to my manager and he said to me to be like Dalai Lama and work around him (I’m serious he actually mentioned Dalai Lama!). He also said that everybody in the team did that and even he himself was afraid to talk to the bully because he never knew what his mood would like.

No bullshit

I like conversations that go directly to the point. When I talk to my kids I respect their intelligence and I am always straight to the point. They are 8 and 11 years old as of today. I respect their intelligence and don’t keep going over and over to explain something. I always go to the point, make myself clear and ask them if they understood me. When they don’t I explain in another way until I am sure they understood me. Although they are young, they appreciated that. I do that with kids, of course, I do with adults as well. That does not mean I need to be rude. I can be nice and direct to the point. I expect others to do the same with me. Particularly about sensitive topics. A no bullshit policy means everyone is clear what it’s being talked about and there is no room to “interpret” something. In general, people appreciate that I am direct to the point. And more than once, they reached out to me precisely they know I won’t bullshit them. Some other people don’t like that so much.

For example, I was working for a company that was trying to get a big contract with a very big client. My manager was quite hopeful that would the first of many other contracts. As part of work with this big company, they asked us some questions regarding security and my manager asked to me answer those. It was an extensive spreadsheet where I went from item to item answering them. Then I reviewed it with another person in my team, we changed a bit and sent to my manager. My manager was reviewing our answers and started to get anxious about. He asked me to look at those questions with more “positive eyes”. I then said in a sensitive topic as security is, I don’t have “positive eyes” only “technical eyes”. It was my duty to report what I saw and not what it should look like. But he was free to change the answers and send the spreadsheet in his name instead of mine, which he did.

No rock stars

I don’t believe in rock stars if your company is looking for one, that’s definitely not me. In fact, I never met one. I met dozens of awesome developers though. People strong technically and great team players. They weren’t rock stars. In fact, most of the time, they were in the background.  Mentoring team members, helping with infrastructure, removing blockers and etc. Their value was in improving the team itself and not going to the front stage and solving all problems. A team of software developers is not a rock’n roll band where the singer is the most important person. A team of software developers should have much more collaboration between members than a competition about how’s the protagonist. A rock star or a ninja are terrible analogies for good team players. And I definitely don’t want to work with those.

For example, one of the most awesome developers I ever met, used to do pair programming a lot. He knew he could leverage new team members easily that way, but he also knew he could learn with other people too. He also organised brown bag sessions and encourage people to share their knowledge. He was very patient to break down a technical problem and explain it to whoever wanted to hear. He always listened to other people’s ideas and took them seriously even though the idea itself wasn’t very good. He never took the front stage and tried to show how awesome he was. He was in the background, making sure everyone got the support they needed to do a great job. Not a ninja, not a rock start, but a great developer!

Diversity for the win!

Although this is implicit on the values above, I believe this is so important that needs to be mentioned. Tech has a problem with diversity. Look at any tech company and most developers are white, male from an English speaking country. So boring. I love diversity to talk to people with different backgrounds, different culture and having different experiences. I also noticed if a team is diverse, chances that are no rock stars or brilliant jerks on it. Collaboration is also improved too. In 2017 and beyond we need to improve on that. And more we need to encourage more minority groups to join us and create a safe environment for them.

For example, at ThoughtWorks Brasil I used to mentor some female junior developers. Besides the regular mentorship program, I also called out when they were interrupted in meetings so people can actually hear their voice. When I was facilitating meetings, I specifically asked their opinion so their voice can be heard. It’s very well known the women have a harder to time to speak of in meetings and are much more interrupted than men. Just to make sure that’s not a problem with women, it’s a problem with men. Men create this problem and we need to fix it.

That’s all folks

If you got down here I really appreciated. I like to challenge these values a lot and they are constantly changing. So I might update this in a few months.

 

Agile Transformation – A new hope

Hello people,

I just have been assigned to a very interesting project. It is about to do an Agile Transformation in a big client of ours. This is cool, right? But it is also very complex and sometimes confusing. So I´ll write about what we are doing in that project and explaining which approach we are using and why. So before start to explain something, I´ll give you a bit of context.

Context:

It is a big client. They have more than 15000 employees around Brazil, more than 2 million clients and are growing pretty on the last few years. To keep that amazing numbers, they need to improve their business agility and time to market. Nowadays they have a heavily document oriented process using a waterfall approach. Also, they have outsourced all software development to external providers and have a pretty troubled relationship with them. It takes two years on average to build and release a software. On the end of this long and complicated process, usually, they have a buggy software, that´s late on the market and costing a lot more than it should.

They asked us to change this painful process to a collaborative, iterative and agile approach. So after accept the work, the question is: How to start? The answer is below 🙂

Creating a team

That´s a really important part. We are talking about an Agile Transformation, this is a change on the organization itself. The team must be diverse, cross-functional and with different skills. In our case, we were able to build this team. We have 8 people. 4 ThoughtWorkers and 4 people from the client. This is an interesting mix, since the ThoughtWorkers keep pushing to change faster and the client people keep warning us to go slower, otherwise people will get scary and defensive if we push too hard. So we, as a team, keep discussing if we are going too fast or too slow. This is very important to keep us going on the right pace.

Defining goals

After having a team, we need to define our goals. An agile transformation is not a real goal, isn´t? It is very subjective, everyone who listens the term “Agile Transformation” thinks in something different. We had to align what that means. Also, this project is about an organization change, which means we have lots of stakeholders. So we needed to define who are our direct stakeholders, the goals for our team and the steps to get there.

To come up with all that definitions, we did what we call “Inception”. This is an workshop we do that takes around 4-5 days that defines goals, stakeholders, features and tasks. You can get more information about this workshop here. After 4 days we came up with a vision statement for our team, a list of goals, a list of important personas (including stakeholders) and a list of tasks required to achieve that transformation. Those tasks were classified by risk, effort and business value, but not yet prioritized.

Engaging stakeholders

So now we have a team, a clear vision, well defined goals and a lot of tasks to start to work with. But yet, we were missing an import part of this: our stakeholders. Even though, an organizational change impacts everyone, usually there is a small group of people who defines if your project is successful or not. These people need to have visibility in what the team is doing and what is coming next. Also, they need to participate and engage on the team’s work. However, often these people are very busy and don’t have time to do that. So it very difficult to engage them on a project daily basis. We solved that by presenting what we have defined so far. Also, we explained that we didn’t have a chance to get their opinions, so we went ahead and defined our next steps, based on the tasks we came up with. We have talked to them about all of this,  but they didn´t give us any input on prioritization. So they got curious and bit annoyed to see that we already had prioritized everything. So they wanted to understand more about what we were doing, so they quickly found room for us on their agendas. It was a hard move, but it was essential to make them engaged with our project. They understood our message. If they don´t follow our pace, we will go ahead anyway.

Developing a product

When you work in a project for a client, you have a specific mindset. The client is your boss. They will pay for your work. They will make the important decisions. They will choose what is the most important thing to do or what should be changed. Basically, the work from an agile team in this scenario is help the client to decide how the solution should be and how are the steps to get there. Once the client takes all that decisions, we just get stuff done. Of course, it is not as easy as it sounds, but this is the basic idea. In this scenario the client has the power and also the responsibility.

When you are developing a product, however, this mindset doesn’t work anymore. You don’t have a single client anymore, you don’t have a boss. You have multiple clients and all of them want different features. Even though, you have a Product Owner to make the “client” role, the team together decides what needs to be done. In this scenario the responsibility in the team is much bigger when comparing with a common project. It is not as simple as create a story and then push to production.

In a product each new feature is more analyzed and discussed than in a common project. A particular feature can be implemented in different ways and the discussion about how implement it takes time. First thing to notice is: the feature should be detailed and has a very common understanding among the team. Even if the team wants to split the feature in different parts, everyone need to have a good understanding about the feature in a high level perspective. Otherwise, we can have a hard time later to change the code, the model to meet the requirements. A product is not something so easy to change as a common project.

I was reading an article about customer discovery and I just realized that I know very little about this. Develop a product is a new world for me. So I’ll start to read this book “The Entrepreneur’s Guide to Customer Development: A cheat sheet to The Four Steps to the Epiphany”. And then read the famous “The Four Steps to the Epiphany”. So I can have a better understand about this new world. It looks pretty exciting. If someone has any suggestion of good books about this, please let me know.

Understanding the story life cycle

In the past few days, I’m playing the QA role inside my team, since we have only 1 QA and lots of stories Dev Complete. It is interesting to notice when wearing the QA hat, you have other view about a story. It is not about which part of the code I should change or how should I do my tests, now it is about functionality, bugs, scenarios and so on.

It is interesting to find bugs in stories who were played by very senior developers . It makes you remember that everyone make mistakes. It is also important to see the whole story life cycle. What happens if you find a bug? Is it related to that particular story or is it something else? It should create a new card for that? If yes, how much information we should put on that? What is the priority for this bug? Should we talk with the BAs about that? Is it worth to write an automated test to make sure that bug doesn’t happen anymore?

It is very interesting how a simple thing like that, change your role for some time, make you think in a different way. If there is one thing that I noticed is that all the senior people who I have been working with, have a big picture about a story. Usually, junior people are just concerned about make stuff done and don’t think how the story can impact the whole system. Work as a QA helped me to improve this vision.

I’m looking forward to pair with a BA as well. Forget about the technical things for a moment and think only about the feature. Focus in what the user needs, how break a particular feature in different stories and keep them valuable for the client. Understand how get the requirements and “translate” that for working software and then prioritize the stories. I’m pretty sure that doing this next step, it will help me to understand even better a story life cycle.

What should we test?

This is always a good question. But to properly answer it, we need to make some assumptions:

  • Tests don’t give us a guarantee that our systems will work. It helps, but it is not a guarantee.
  • If the tests take too long to run, no one will run the tests
  • Good coverage is not synonymous for good tests.
  • Tests are good when they are meaningful, when they are test something important. Otherwise, they are useless.

Having said that, what we should test? If we write thousands of integration and/or functional tests, we would test a lot of features, but our build would take too much time to run. It would be easy to developers forget about those tests. So it is not a good approach. We could create thousands of unit tests, the build would be quick and we would have a very fast feedback. It is a good approach, however, it wouldn’t test the classes working together, so  it is still not the best approach.

In my opinion, the best approach is the test pyramid.

We still would have lots of unit tests. They are good for testing classes and allow you to use TDD as a tool for Emergent Design. They are not suffiicent though.

We could also create some integration tests to test our classes together (e.g. add tests in the Service Layer). However, we should only add tests that are really necessary since they would take too long to run. The goal would be to test critical features or only happy-path scenarios.

After that, we should have the end-to-end tests (in the picture above called UI tests). In these tests, we want to test a feature like the user would. This DOESN’T mean testing javascript. For that, we have frameworks like Jasmine.  We could add only few of those end-to-end tests. Only to test a whole feature that we cannot tests on our integration tests.

In summary, there are some approaches to test our software. But the most important thing is that our tests should be meaningful and should have value. It should test what is important. The test pyramid approach is a good guide to make us test the right thing at the right level.

Generation Y and Agile

I think everyone heard about Generation Y (if you don’t click on the link). After watch this video and think about the characteristics that our generation have and also how we work, I realized that Agile Manifesto is a consequence of our new mindset.

I’ll do a relation between Generation Y characteristics and what we have in the Agile Methodologies:

Tech-Savvy: This is easy. We are very connected to the technology. We always want to use the newest language, the newest IDE, the newest gadget and we use all of this in daily basis. We use this work with remote teams, to pair remotely, to manager a server in the cloud.

Family-Centric: One of the Agile Manifesto Principles summarize this:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Individuals have their own needs, their own motivation, their own life. Respects this is essencial to make a individual motivated.

Achievement-Oriented: We are moved to achievements. If we don’t see results as soon as possible make us feel boring and unmotivated. That’s why we have iterations or workflows to deliver faster and continuously. Also there is the culture of fail fast and learn faster.

Team-Oriented: This one is very important. We don’t like hierarchy that much. We prefer to work as team in a collaboration way and having voice to question everything. Another Agile Principle about his:

Business people and developers must work
together daily throughout the project.

Attention-Craving: We like feedback, we like to know if what we are doing is right. We like to discuss, we like to give opinions. We do this with our client and with our team as well. Give feedback is a important step to make your team successfully (if is not the most important one). There is another good Agile principle about that:

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

In summary, Agile is just a consequence of what our generation thinks. We are more dynamic, ambitious, impatient and more incisive than the others generations. This made us to think how to work in a different way and then Agile comes. Which makes me think that the companies that don’t use Agile are late 🙂

Why change is good

Last week, I was talking to a friend of mine and he told me that I’ve changed a lot since I moved from Santos (my hometown) to Porto Alegre. I was wondering about this. Since I moved from Santos, I was able to meet other people, meet other places and live different situations. Which made me grow in every aspect of my life. Once I was in Porto Alegre I started to work in Thoughtworks. Thoughtworks’s environment encourage its employees to work in  a particular way. We like diversity, initiative and people who like to express their own opinion. This was a big change to me. I never had the freedom to suggest improvements or even complain about what I believed was wrong. At ThoughtWorks, people will let you know directly when you’ve done something wrong. It is a private and direct feedback to you. It is a though experience. They will tell this and explain why. Because of this I had to think and act of differently from what I was used to. I had to leave my comfort zone and start to learn how to handle those different situations.

I had a lot of different experiences since I joined TW. Here are some of them: I had to explain to a colleague from China how get a cab and go to a shopping mall. I had to explain to Americans why Brazil has so many taxes. I ate real Indian food made by Indians. I went to a country where no one knows how the way of the life in Brazil is and where I came from. I had to teach Portuguese to a German girl. I had to work with passionate people and try to solve a tough problem. I had to be honest with myself and my team and call out what is wrong no matter how difficult it was. I had to understand that I still have to learn a lot of things and I have to keep studying and learning forever.

When you work in a dynamic environment that challenges you, you have to learn how to be in a position that you are not used to.  This makes you grow and improve. This makes you start to question the status quo.

In summary, my friend was right. I really have changed. I am sure that today I have new ideas, new principles and I have improved as a human being.