Skip to Content

Category Archives: Scrum

Remote work in pandemic times

One of the best things about working in the IT industry is that we are in a state of constant digital transformation, which means that we are able to use technology to adapt our processes and meet the high standards of a fast-paced world. 

It has been 7 weeks since we started to work entirely remotely at Tango, following the government’s recommendations to avoid the spread of the virus, but that doesn’t mean we are new in this game.

Just to add context, Tango has offered the possibility to work remotely, even before the pandemic situation. Consequently, we have been improving our process to manage distributed teams for the last decade. We know transitions to working remotely can strain your internal performance at the beginning if you’re not used to it, but it can help you get ahead of the curve.

You should be prepared for distributed teams, with or without the pandemic, for various reasons like increased productivity (35-40% more productivity), better quality (40% fewer quality defects), higher engagement rates (41% lower absenteeism), and higher profitability (21% higher) (Forbes, 2020). All of these reasons are driving companies to go remote.

Given the benefits and the current situation, organizations are preparing to invest in remote teams more than ever, so we need to find a way to train ourselves to dive into this not-so-new way of working.

Here are 5 points that  I’d like to keep in mind each time that I need to work with distributed teams.


1. Trust isn’t negotiable: 

According to the research report “Why Trust is Critical to Team Success by Reina and the Center for Creative Leadership, trust is a must for you and your team. By building trust you can:

  • Deepen the engagement of your talent
  • Foster collaboration
  • Drive change


“Trust building helps teams step into the ambiguity, to stay committed to managing the unknown with confidence, and to embrace change as an opportunity to learn, grow, and do great work together.” (Rina, PhD, Reina, PhD, and Hudnut, MIA, 2017)

2. Communication is key:

The lack of communication can lead to the worst outcomes. N. Sharon Hill and Kathryn M. Bartol wrote an interesting article about communication that is worth giving a try: Five Ways to Improve Communication in Virtual Teams.

The book “From Chaos to Successful Distributed Agile Teams mentions:

The first principle for successful geographically distributed agile teams is to establish acceptable hours of overlap. The Key is enough communication time and sufficient communication tools.

According to Johanna Rothman and Mark Kilby, authors of “From Chaos to Successful Distributed Agile Teams.”, an agile team requires a minimum of four hours of overlap a day for sufficient collaboration. Teams without the possibility of adequate hours of overlap can avoid chaos if they follow an organized agenda.

3. I need a committed team:  

This is important to keep up with the Continuous Delivery model we are following at Tango. I need to know I can trust my team will get the job done.

Increasing commitment involves the two aspects we previously mentioned: Trust and communication, according to “The Five Dysfunctions of a Team (Lencioni, 2019), also adding the importance of healthy conflict, which drives commitment to decisions, avoids an environment where ambiguity prevails.

Lencioni mentions in his book how the lack of commitment can lead to the avoidance of accountability, which results in inattention to results.

4. We should be looking for continuous improvement:

The Institute of Quality Assurance defined continuous improvement as “a gradual never-ending change which is focused on increasing the effectiveness and/or efficiency of an organization to fulfill its policy and objectives”.

This definition does not exclude the growth of your team, and that should encourage you to seek the improvement of your organization by the gains of your team members.

A way to keep teams motivated is by showing them that failing is part of the learning process and success comes with a lot of failures. No one is going to hit you if you break the staging server; just rollback and check what happened, taking on the responsibility to determine what you missed. 

5. We should follow a methodology:

We decided to follow the Scrum methodology since it has worked the best for our team, but you can choose any methodology you think it’s most appropriate for your team. 

Using a methodology will allow you to understand your processes better, know your limitations, be consistent across your projects, and it will give you consistent metrics and expectations.

In case you are interested in the Scrum methodology, let me share our routine.

On Monday, we start with our Sprint Planning meeting, adding a quick standup to check what the team did during the last working day. All work must be ready and without missing details. The whole team follows the Definition of Ready and the Definition of Done, so we don’t have chunks of non-working products. We run 2-week sprints, following the Scrum methodology.

We have a standup from Tuesday to Friday and don’t use a camera at all unless it’s our Retrospective meeting (We like the feeling of privacy in our teams), and when we do have our Retrospective meeting, team members feel motivated to turn on the camera, so we all interact. 

Here are some practical tips I like to take into account when I approach any of my team members: 

  • Before calling my team, I ask myself: “Do I need to call them? Could a message or email be enough?”
  • Icebreakers to start, don’t take too long, but that would make any meeting run more smoothly.
  • When messaging your team, include the reason for the message right after the salutation. This is not rude, people’s time is essential, and just because you combine the greeting and a question doesn’t mean you don’t care about the person.
  • Agree on the best time to have a call. Unless it’s an emergency, it’s better to have an arranged call than to cold-call your team members.
  • If you create an event, always add the topic, so that everyone is aware of the discussion.
  • Be patient. We all have to deal with bad internet connections, interruption by our pets, family, and other external situations.

 

Conclusion.

Remote work is no longer just a perk, in fact, it’s more like a way of living. Let’s be more intentional about how we work and show that we can still be productive while adding value to the work we do while being a remote team member. 

Productivity is a top concern for companies, but we found that working remotely actually makes us more productive overall. So, if you are in the process of transitioning to a distributed team, you can start by implementing some of the tips I shared here. 

As an additional benefit, remote work has allowed me to join worldwide teams that share work-related ideas, workshops, and helped me to continue growing as a professional.

Have you observed any similar situations in your remote working experience? Let us know in the comments down below.

 

0 0 Continue Reading →

The product owner’s job: to say no.

Have you seen a team that doesn’t understand the reason behind developing certain feature? Have you had a sprint review where more than a half of the features are rejected? Or that the team develops a huge feature that doesn’t add any significant value to the product? If you’ve seen this in your project, it might mean that your Product Owner is doing something wrong.

We can consider the Product Owner to be the main stakeholder. She should own the product and determine direction. The reality is that the Product Owner role is different from that of a project manager, since she has the passion, the vision, and, unlike a project manager, has to say no to people. Let me explain.

Saying NO to stakeholders.

On a typical project, the team delivers a certain amount of story points per sprint. But it’s common to see that once stakeholders notice what the team is capable of doing, they start asking for more and more stuff. Imagine that certain project has around ten stakeholders, and each one of them suggests a new idea, which represents, let’s say, two story points. The problem is that the team is only capable of delivering ten story points per sprint, and if we let this situation run out of control, then we will end with an infinite queue of pending work.

The Product Owner is the one in charge of prioritizing the work queue. More than that, he is the one in charge of preventing the creation of that infinite queue of features, and the only way to do it is by saying NO to stakeholders. At least from time to time.

It’s true that the Product Owner must develop a good relationship with the stakeholders, and part of this is helping them decide what should or shouldn’t be part of the product backlog. By having a clear product vision, a well-studied market, and regular interviews with end users, the Product Owner should be able to determine what features are the best for the product.

Saying NO to the current backlog

The business value produced by each feature tells the PO what should be the priority for each story. Let me clarify, when I say value I’m not talking about the size in story points, I talk about the actual ROI of each story.

The Product Owner should be skilled enough to find out the real value of each feature, by studying end-user behavior and market trends. Let me give you an example of that.

“Jim Employee” is part of the marketing department of a graphic design company that sells templates to graphic designers. On a sprint review, Jim proposed to add a small countdown clock right below the daily offer section. The only problem is that his requirement was down the road in the backlog because of the urgent features that the accounting department has requested.

“Mark Product-Owner” decided to support Jim with his idea and he put it at the very beginning of the next sprint. After an (expected) argument with accounting, he stood his ground, and the team developed Jim’s idea.

At the end, that small requirement increased sales, and it wouldn’t have been possible without Mark’s support.

What if one of the stakeholders proposes a simple change to the interface that improves the end product a whole lot? If the stakeholder doesn’t have enough influence and there’s a lot of pending work on the backlog, chances are that the feature could stay in the backlog forever. It is the product owner’s job to support good ideas that have high value.

Saying NO to the Scrum Master.

It is true that the scrum master is the one in charge of making sure that Scrum is followed as intended. However, there is just one person that can say no to the Scrum Master and change a sprint’s path or add features, and that is the Product Owner.

According to Voltaire, “With great power comes great responsibility” and, in this case, that quote applies very well. The Product Owner is the only one that can say no to the Scrum Master, and if she doesn’t use this power wisely the team could end with a useless Scrum implementation.

But, when can a Product Owner interrupt a sprint? There is no rule for this; it depends on the urgency of the requirement. As a rough guideline, I could say that most of the time a sprint can only be interrupted because of the appearance of an urgent bug on the production server. It is the Product Owner and the Scrum Master’s job to exert their judgement and decide when a sprint can be interrupted for the sake of the project’s health. Nonetheless, the Product Owner has the last word.

Saying NO to the team.

It’s the team’s job to think outside-the-box. However if they didn’t have any external boundaries to keep them in check, the product could easily become something different than what the market, users, and the company need and want.

One example of this happened to me when I was Product Owner of a project that started as a small demo to a group of investors. After a few months of work it became a more serious networking application.

On a Sprint Review Meeting, one of the most experienced developers of the team asked me to spend a significant part of the upcoming sprint time on redefining the architecture of the application. He explained to me that the design that we had up to that point didn’t fully support the new requirements, and we had to do it right away.

At that time, we just had one “urgent feature” to develop, so it was easy for me to say yes to that. I wasn’t sure I had made the right decision until some time passed, and the velocity of the team went up. When I asked about what changed, they told me that the new architecture was allowing them to develop things faster.

Later, I received a suggestion from the same developer about moving to a NoSQL database. According to him, that database model offered better compatibility with what the product was becoming. I analyzed the situation, asked for some advice and I decided that it wasn’t a good idea to proceed at that moment with the change. We were far away from launching the product and, even though we were near to the deadline, the improvement on the application’s response time wouldn’t be significant.

In other words, the Product Owner is in charge of making room where the team can experiment with their ideas.

Having a great relationship with everyone.

I’d say that this is the hardest part of the work since this involves a lot of what some people call “soft skills”. It involves leadership, friendliness, persuasion, and more.

The Product Owner must have a good relationship with her team and become the main bearer of the product’s vision. She or he should maintain a good relationship with the Scrum Master since he will help her to mediate difficult situations and will support her with the improvement of the Product Owner’s performance.  Finally, she should maintain positive relationships with the stakeholders. They are her customers, investors, and end-users. Without them, the project wouldn’t be possible.

The Product Owner role is a complex one that needs skills and knowledge in professional communication, user experience, and market research. At TangoSource, we have internal Product Owners who act as the eyes and ears of our customers. They are in charge of interviewing the stakeholders, studying the market trends, and defining the features of the project. Ultimately, they’re responsible for the results at the end of the sprint.

Want to know more about how we run Scrum within the company? Drop me a line or follow me on Twitter, I’ll be glad to strike a conversation.

Thanks for reading!

R.

0 10 Continue Reading →