DEV Community: Andre Rubin

Radical Candor: feedback the right way

Andre Rubin — Thu, 20 Dec 2018 04:19:58 +0000

Radical Candor is a powerful concept that teaches us that, to give proper feedback, we need to care personally for the person we are giving feedback and to challenge them directly.

In this post, I’d like to share a story of Radical Candor that had a great positive impact in my workplace.

Next, I’ll be writing a follow-up post that goes in-depth about how you can successfully use it at work and in your personal life.

from https://www.radicalcandor.com

Radical Candor at work

One of the developers in my team, let’s call him John, used to have quite the toxic influence among other developers. He was the lead on his team, but was confrontational, had controversial opinions, and would elicit stakeholders to join his ‘side’, encouraging the “us vs them” mentality.

At the time, I was not specifically working in his team as a Scrum Master/team coach, but I definitely wanted… no, I needed to do something, as it was affecting all the teams. As a new Scrum Master, I was not really sure how to handle him, although I had a good relationship with all other developers in his team. The few times I had tried helping his team I was not successful, so what could I do differently now?

I have to confess that, because of his toxicity, part of me thought that it would be better if he left the company. It would make everyone’s life at the office better and definitely make mine easier. But wait a second, I’m a team coach, goddammit. How about I coach him? It’s my role to create a supporting, inspiring work environment where success is nothing but a consequence of being there. So the situation was not being helped by me just sitting there.

As I mentioned before, this was the first time I was working as a full-time Scrum Master, and therefore I had made a ton of mistakes when starting out. At that particular point, I realized I never had taken the time to get to know him, even after more than a year of joining the team. A huge fail on my side.

So scheduled a talk with him and we sat down on our first one-on-one meeting. We discussed some issues his team was having. His being new in a leadership position as well, a situation arose that caught him off guard, some things were said that were not supposed to be said, and now we were taking steps to resolve the conflict. During this talk, I was surprised by his humble attitude: his toxicity that I had felt during team meetings were not present on this one-on-one.

I pressed on.

With Radical Candor in mind, I used our internal feedback tool to leave John sincere but strong feedback. Radical Candor is a technique that my company often talks about and I’ve started using also in other areas of my life. The idea is that, if you really care for someone and their success, you should let them know where they can grow, even if it feels uncomfortable. If you don’t, you are doing that person a disservice. You are preventing them an opportunity for growth. And having had that first meeting with him and understanding him a little better, all I wanted was for him to succeed; his success meant helping his team succeed; his team’s success meant helping our whole technology team succeed. I think he understood this, by leaving a big ‘thank you’ for the feedback.

Radical Candor Follow-Up

A few weeks later we had a social lunch where we talked about travel plans, career, living in other countries, and our current jobs. We were finally getting to know each other on a deeper level.

I learned a lot about him. And I learned the reason of why I thought he was a toxic person before. At the time, the department had a leadership problem, so people got a little too comfortable. John was trying to get people out of their comfort zones. He was confrontational because he was trying to make others be better developers. I didn’t agree with his tactics, but he wanted the same as any other developer in the team: He wanted to work on cool projects, he wanted people to step up, he wanted to create an awesome team.

Some old teaching came to mind, reminding me that everyone has a story. Everyone has reasons to behave the way they behave, and until we don’t get to know them, get to know those reasons, then we shouldn’t assume we know what’s truly going on.

Fast forward to today, John and I have a great relationship at work. I don’t think his attitude is toxic anymore and he understands that my goal is to see him and his team succeed.

I’m not claiming that his change in behavior is my doing. What I’m saying is that Radical Candor helped me get to know him, which made my thoughts about him change completely, helped me understand why he was so confrontational that period of time and what he actually was trying to do. Now we are both better prepared to support our teams’ growth.

On my next post, I’ll present a framework in which you can follow to try to implement Radical Candor at your workplace or in your personal life.

The post Radical Candor: feedback the right way appeared first on Agilist Andre.

How do you see processes?

Andre Rubin — Fri, 15 Jun 2018 06:23:50 +0000

I heard an analogy recently from one of my developers that processes are like walls: you want to work on your code, but there is a wall that prevents you; once you remove the wall, you can get to work faster. However, I deeply disagree with this analogy.

As an Agile Coach and Scrum Master, I value People and Interactions over Processes and Tools. However, it is very clear to me that process and tools can aid software development. For example:

Scrum (if implemented correctly (and I agree that that's a big 'if')) can increase the speed at which the dev team delivers value to the end user;
Pair programming, although it will slow you down a little (very little), it does generate higher quality code, a shared sense of code ownership (increased Bus Factor), and a faster leveling up of devs;
Noisli: When I'm in deep-work mode, this app gets me in the flow so much faster;
Retrospectives - the ultimate tool for a team to solve their own problems, for developers to build their dream work environment!

I could keep going on and on about this.

So what are your opinions on this? Are processes a wall for you? Or are they helpful? Can we bridge the gap between devs that think processes are walls and devs that don't?

Networking and my First Agile Talk as an Agilist

Andre Rubin — Sat, 02 Jun 2018 06:43:37 +0000

On August 23rd, 2017, I gave my first agile talk at Mindvalley’s beautiful Hall of Awesomeness, organized by an incredible organization called Women Who Code, Kuala Lumpur (WWC). The event also included a talk by my fellow agilist colleague, Andreea Visanoiu, who presented a comparison about agile frameworks.

My talk was about agile teams and it was well received, in spite of a few stumbles here and there from lack of practice in giving talks in general. I had notes in one hand, a mic on the other, and was one hand short of being able to hold the clicker. I’m happy to say that I’ve gotten much better since then.

My first agile talk

Listening to Andreea with the WWC audience

Q&A session

A great turnout and a lot of fun meeting agilists and WWCers

How did my agile talk happen? Meet Women Who Code

A few weeks before my talk, I luckily stumbled upon another agile talk organized by WWC. Agilist Kimberly Brown was the presenter, and she shared her experiences helping organizations to be agile in the workplace.

In this event, I met Daphne Choong, who is one of the organizers of WWC and leads the agile track. Daphne and her fellow WWCers organize numerous events in Kuala Lumpur: 17 events in total in 2017! They organize these events in their spare time and the events are free to attend with the vision to “[create a] world where women are proportionally represented as technical leaders, executives, founders, VCs, board members, and software engineers.” But, just as their vision promotes equality, so do their events: both men and women are welcome.

As we were both passionate about agile topics, Daphne then mentioned that, if I was interested, she would put together another agile event where I would be the speaker. I could not have said no! I was more than happy to support this inspiring organization and at the same time take the opportunity to get some stage time.

So, find a Women Who Code chapter near your area and check out their next events. You will learn a lot of cool stuff and have a ton of opportunities to network with other professionals in the area.

The post Networking and my First Agile Talk as an Agilist appeared first on Agilist Andre.

What makes an agile team, agile; and a waterfall team, not?

Andre Rubin — Mon, 30 Apr 2018 20:33:16 +0000

A tale of two mindsets

How does a waterfall team approach a problem?

Meet Tim. Tim is a manager of the tech department of a waterfall software development shop. Tim and other managers in the department were worried because the DAU (daily active users) of their online application was in decline. So they gave themselves a goal: to increase this metric by 15% in 3 months.

They brainstormed ideas, discussed alternatives, discarded unpopular ones, and decided to revamp their website with the latest, flashiest javascript+elixir+phoenix combo. Tim was in charge of driving this effort.

So now, Tim needed to find an available software architect and designer in the department to start with the specs, wireframes, and designs of this new version of the product.

After these specs and designs were to be completed, they would be sent to some of the front-end developers, some backend developers, and maybe involve one DBA to review the persistence layer. When the development was done, they would throw it over the wall to some Quality Assurance experts (QAs) to test.

How long would this take?

Probably a lot more than the company could afford with an underperforming product.

Also, there is an important question that Tim and others were failing to ask: will revamping their online application solve the problem they were trying to solve? Not necessarily.

When sprinting, make sure you are running in the right direction.

This is the stereotypical development practice in a waterfall shop. With this mindset:

Decisions are made at the top and given to the dev teams for implementation;
Managers assign tasks to developers who are treated as kids that need to be reminded not to slack off, also known as command-and-control;
The goal is 100% utilization of (human) resources. If employees are not doing what they were hired for, it’s a waste;
Devs are treated as replaceable resources.

How would it be different on an agile team?

Enters Tina. Tina is an Agile Manager and she has a self-managed team. But wait, how does that work, a manager on a self-managed team? Exactly. Self-managed doesn’t necessarily mean that you don’t have managers per se, but means that managers will act as servant-leaders and as coaches. They give the team tools, freedom, and trust to solve problems. One of the principles of the Agile Manifesto is:

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

Let’s use the same problem of the example above. How would Tina interact with the team? Tina won’t tell her team to revamp the webpage. Tina will give the team the problem itself, the challenge to increase the DAU of their product by 15%, it’s up to the team to figure out what’s the best solution. We already talked about how the proposed solution might not fix the problem, so why not give the team the problem itself?

Agile teams are given problems to be solved, not solutions to be implemented.

What Agile managers won’t do is tell developers what to do. Agile teams are self-managed. They have full autonomy to decide how to solve the problem.

Tina’s team is cross-functional, which means that team members have all the skills necessary to deliver a full-fledged, full-stack solution. She has a team of experts with a few back-end and front-end developers, some designers, one DBA, and a couple of QAs working together with the support of key stakeholders.

Agile teams are cross-functional. The agile team is a team of experts.

But wait; Scrum, the most popular agile framework, doesn’t recognize different roles in the team. They are all part of the development team, who work together to deliver the product that the Product Owner (PO) requested. So which one is right? Is it a team of experts or are there no distinctions between the team members?

Well, it’s both. In an agile team, you do have a team of experts, but silos are broken down. The individuals dissolve into the team. They stop being a group of people working together and become a team where the whole is greater than the sum of the parts.

If that sounds too cliche, let’s dig deeper and look into how an agile team divides work and own its tasks:

Let’s say that the team is working on a story for a certain feature. Samantha, the back-end developer, finishes her tasks, performs all the pending code reviews, optimizes the workflow and is now ready to pick up another task. All the back-end tasks of the stories of the current sprint are already completed. However, she notices that the there is one story with many pending front-end tasks left. What should she do next? Should she work on the next back-end task that is from a story not on this Sprint?

No, she decides to sit with Peter, the front-end developer, and figure out how to complete this story together, either pair-programming with Peter or picking another front-end task to work on her own. Samantha didn’t commit with the PO that, as a back-end developer, she would complete only back-end tasks; rather, Samantha, Peter, and the others committed as a team that they would complete the stories and the features together.

The whole team owns all tasks, not individual people owns individual tasks.

To make an analogy, think of the team as a start-up and that the PO as your client. Then imagine your team might miss the deadline (and even the contract) with that client. So for your start-up to survive, it needs to focus on delivering the value to your clients, rather than the expertise of each individual member.

Agile team members slowly grow their skills on a T-shape, where they have the depth of knowledge in one area, but also the breadth of knowledge in several other areas. They are generalists and specialists at the same time.

What else is different? Well, as we’ve seen, there was no guarantee that revamping the website would be the best solution. The agile team doesn’t know what the best solution is, but it has some ideas. So it’s time to test a few of them. That’s where two components of agile shine together: ‘short-iteration loops’ and having an environment that is safe to fail.

The team can prototype a possible solution in one or two iterations, measure results, and from there decide to either discard the idea, because the solution hasn’t been proving effective, or start a new one. Because the team has complete safety to fail, they won’t be afraid of innovating; they won’t be afraid of trying something out-of-the-box, and even a bit risky, in order to achieve an outrageous positive result. If it doesn’t work, they don’t mind, because now they learned something. They are more knowledgeable about the problem at hand, and the next solution they come up with will have a better chance to succeed. Failures are celebrated as learning.

Safe to fail = innovation

Short iteration loops + Failure = Fail with short-blast radius

** ~~Failure~~ = Learning**

By iterating over the solutions and measuring results, they will arrive at a more suitable solution. Tina, the manager, doesn’t need to keep assigning tasks or reminding them to do task A or task B; she trusts them to do their jobs (they are adults, after all). Since the solution was their idea, they will take ownership of the solution and be motivated to get the job done, and done with quality. The team feels empowered.

Agile teams take ownership and pride in what they do… because they are in charge of it.

Who else is in an agile team? One of the agile principles is “Business people and developers must work together daily throughout the project.” Several agile methodologies implement this differently. Extreme Programming dictates that the client is highly available in the team, preferably co-located. Scrum has the PO who ideally will have an intimate knowledge of the product and a close relationship with customers/clients/stakeholders. Another role in Scrum is the Scrum Master. But even if not implementing Scrum, it’s always recommended that teams have an agile coach to guide the team to become truly high-performing and achieve their growth goals.

Tina knows that members of the agile team don’t need to always be 100% busy. She focuses on the baton, not the runners. Developers are not supposed to always be coding; designers, be designing; QAs, be assuring quality. They need space to think, talk, teach, learn, and grow; space to improve processes and relationships; space to learn more about the business and the industry. She focuses on the value being delivered to the user.

Agile managers and teams focus on the baton, not the runners.

An agile team will also, as frequently as they deem necessary, inspect how they are doing the work, and find ways to improve it. This “continuous improvement” is based on The Toyota Way and adopted by agile teams. So their jobs become not only doing their work but also improving the way they do their work.

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

With this mindset:

Decisions are made at the bottom, where the work is being done;
Managers are servant-leaders, giving the team the space to do their best work;
The goal is 100% value delivery. Any unfinished work (that is, work that hasn’t been delivered to the user) is a waste;
Devs are not treated as resources, but as learning individuals and as adults–respected for their skills.

Tina’s agile team will have a much better chance to solve this problem than Tim’s. They will use short iterations to test their ideas and get feedback from users. They will take ownership of the solution because they are motivated by the autonomy that they experience by solving a real business problem.

Agility, in the end, is not about all these highlighted topics in this article. Agility is a mindset, a new paradigm of doing work. Just following a set of steps won’t make you agile, but having the right mindset will make you understand why certain steps should be taken and others not.

If teams can’t adapt to business, market, and technology changes, and also deliver value in small increments, they will lag behind. Nowadays, agility is not even an edge; in order to stay relevant, it’s a necessity.

The Three Levels of Maturity for Software Developers

Andre Rubin — Wed, 28 Mar 2018 09:44:11 +0000

Before becoming an agile coach, I was in software development for about ten years. Before that, I did a bachelor’s and a master’s degree in computer science. Programming books and tutorials out there suggest that writing code is easy. Writing great, quality code, however, is extremely difficult and can be frustrating at times, but it can be highly rewarding.

During those years, I started to notice that there are professionals in different levels of their careers. On the first level, the software professional’s behavior is the same as of that of a Freelancer, focusing on writing code (also called programmer or coder); the second level is the Software Engineer, who also utilize engineering skills other than writing code; and the third level has two paths: the Specialist and the Software Intrapreneur. These levels already assume a certain level of expertise in software development and they do not equate with how good you are at writing code, nor with your years of experience. It is mostly dependent on your career choices. Let’s take a closer look at each of them.

Disclaimer: The levels described in this article are not meant to replace the seven stages of expertise in software engineering described by Meilir Page-Jones; rather, it’s a look at software development in another axis.

1. The Freelancer

Freelancers (programmers or coders) are pretty good at coding and probably have the full stack. They deliver small to medium projects and mobile apps fast, if not in record time, and are not afraid of trying a new technology if it’s challenging and exciting. If they are working with more programmers, they’ll use the divide-and-conquer approach, where each team member creates a different piece of the puzzle and then integrates the pieces together. Meetings are interruptions to their state of flow and should be kept to a minimum, but they can be also fruitless, since project managers (PMs) or product owners (POs) have a hard time understanding what the programmers are saying.

Freelancers do their jobs by writing code.

Are you a Freelancer?

If you are a freelancer, you are excited about getting your hands dirty, getting to the code level, and building cool things. That’s what attracted you to this job in the first place.

Most programmers on this level I know are freelancing or come from freelancing background (thus the name) or a one- or two-man startup where all above skills are amazing. So you if you are actually freelancing, you are probably doing well by focusing on what you do best. You might get some value out of the next levels, but at this point in your career, they might not be your focus.

However, once you start building a growing startup or begin working on a longer, larger project, involving a dozen or dozens of other programmers, because of the nature of your previous type of work, there are probably a few habits that you should lose:

Habits to lose when transitioning from Freelancer to Software Engineer

In order to meet that freelance deadline, you probably didn’t have time to write too many tests. And since your contract might not have included maintenance work, there was no real incentive to develop code with higher quality, which takes more time.
You are more reactive than pro-active. Since you are used to getting requirements from your clients, you don’t know who your final users are and why you are building these apps and features for them.
You got used to building everything yourself , since you were hired to do so. For you, it’s less frustrating building things from scratch, than finding the right product in the market and to integrate with your app.
And because of all of that, you find working in teams extremely difficult , because of all the interruptions, synchronizations, and mentoring you need to give to your team mates.

Consider the example of Rick, a Freelancer who might have been a great coder, but that didn’t make the transition to Software Engineer. His brilliance didn’t translate into working on a long project, and as the codebase became larger and larger, his code, less and less readable and with fewer and fewer tests. He went into a downward spiral where eventually he was fired and the project was cancelled.

These habits will need to be reevaluated in the case of working on larger projects. But if you are aware of them, you can start making the transition in your career from Freelancer to a Software Engineer way more smoothly than Rick. Let’s take a look now at the qualities of a Software Engineer.

2. The Software Engineer

A longer project will involve not just building, but also maintaining the project for a long period of time. So if there is already an app out there that can can be integrated on the business logic of your app, you could buy it in order to avoid having to maintain that additional piece of functionality. For example, you don’t need to code a shopping cart functionality to your ecommerce site because there are multiple companies that specialize in shopping carts, and you can just integrate an app of your choosing into your site.

Like Freelancers, Software Engineers will have all the skills to develop code. But they will also have other T-shaped skills, since the role is not simply to ship products, but to ship, maintain, upgrade, and support users for years after shipping. Because of this, Software Engineers know that speed is not the only factor, but quality as well. Other characteristics include a preference for working in teams and knowing that the best code designs come up during pair programming (sometimes mob programming) sessions.

Qualities of Software Engineers

Software engineers:

practice pair and mob programming;
understand why TDD, CI, CD (Test-Driven-Development, Continuous Integration, Continuous Delivery) are important, and are familiar with several software engineering practices;
work on Agile teams, often trade ideas with their Agile Coach/Scrum Master and understand that retrospectives are a chance for teams to adapt to a better way of working together and growing;
know that an extra hour spent on quality at the beginning of the project can save hundreds of hours and thousands of dollars for the project down the line;
clean up after themselves (i.e. refactor).

Software Engineers know that their job is not to just write code, but to be part of an orchestra of developers all working together towards the same score. The software engineers do their job by architecting high-quality software products with a team of developers.

Are you a Software Engineer?

Being a Software Engineer, you discovered that your job is not to write code, but to deliver value. In fact, sometimes you deliver value without writing code at all by building prototypes to validate ideas. Before writing a single line of code, you had to plan it, discuss it, prototype it, test, survey your users, and test again. All along the way of writing the code, you will write tests to make sure it’s doing what you think it’s doing. As matter of fact, you might even write your tests before the product itself, using TDD techniques.

By becoming a master of building software products, from here you have two options: 1) you can look inwards and strengthen your relationship within your team and become a mentor, or 2) look outwards to your POs, stakeholders, and users, and become an expert of the product you are building.

Let’s take a look at these two options.

3.1. The Specialist

Specialists not only know how to work with teams and long projects, but they care about their team mates and the work they are doing. They also coach their team-members to evolve into Software Engineers or Specialists as well.

Specialists are experienced software engineers and invariably end up as team leads of software teams. They not only continue mastering their crafts, but also coach their team members to grow as well. As a matter of fact, they take on the KPI (Key Performance Indicator) for their team-mates growth. They value meaningful results over just doing tasks; understand the meaning of the phrase “If I had 8 hours to chop down a tree, I would spend 6 of those hours sharpening my axe”; and truly understand that you don’t need to be writing code 100% of the time in order to be productive. After all, the best code is the one that doesn’t need to be written.

(One of the 12 principle of Agile states: “Simplicity–the art of maximizing the amount of work not done–is essential.)

Specialists do their jobs by fostering an environment where the team is always learning and delivering products with more and more quality at an increasing and, most importantly, sustainable pace.

3.2. The Software Intrapreneur

Having an entrepreneurial mindset is the paramount quality for professionals of this level. Intrapreneurs enjoy not only building cool stuff, but also do it with the customer in mind. They know to sync with the product manager or product owner and to build software not just with speed and quality, like the software developer and specialist, but also with the focus of building the right things. It’s the key difference between effectiveness and efficiency. When you are efficient, you can build things right. But what good is that if you are building the wrong thing? That’s what differentiates the Software Intrapreneur: they are also effective, that is, they build the right thing. They know the value of what they are building for the customer and can provide invaluable feedback to the PO. They strive not only for software development mastery, but to delight the customer.

The Software Intrapreneurs run their teams as if the team were a start-up within the organization. The Software Intrapreneurs do their jobs by making sure that real value is being delivered to their users

Are you either a Specialist or a Software Intrapreneur?

You know that great software is not simply done by writing code. As an Intrapreneur, you will be talking to the PO or the users to understand exactly what they need you to build. As a Specialist, you will make sure that great craftsmanship is being applied to the product by everyone involved in building it, from the junior to the senior developer. You will make sure the team has enough support before, during, and after the development of the product. You will make sure the team is progressing, not simply with the development of the app, but individually in their crafts and together as a team. A gelled team is much greater than the sum of its team members. Teams that have gelled perform at a much higher rate than non-gelled teams.

So what’s next after these two levels? If you are a Specialist or Intrapreneur, you probably already know the answer. You probably already have a blog like this one. Maybe you are thinking of writing a book or speaking at a conference, or even starting your own startup.

Conclusion

As I mentioned at the beginning, the levels presented here do not equate with years of experience. You can be an experienced and highly successful Freelancer (and may use one or two techniques of the Software Engineer) who decided to focus your career on the freelancing world. Or maybe a beginner who becomes a successful Software Intrapreneur.

As an agile coach, I want to coach the members of an agile team to become Specialists and Software Intrapreneurs, because they will be the most successful working in a team. If you treat your software engineering skills and your career as something of value that you are selling (as consultancy or to an employer), you should not just focus on learning new technologies and new languages; but also in learning agile and soft skills that will make you more hireable. You will have the upper hand when negotiating your salary to your future (or current) employer, and you will also enjoy a more exciting role at whatever company you decide to work for. And most importantly, you will be creating products that delight your customer.