Three things I learnt being a scrum master

Giuseppe Sorrentino | User Interface Engineer, Hotels.com in Rome

Originally published on The Hotels.com Technology Blog

Introduction

I am very happy to have had the opportunity to work in the Agile world for almost 4 years, that have been fantastic and challenging.

Being a Scrum master is an invaluable experience and makes you understand and reflect a lot about company processes and software development in general.

It is very hard to discover and address disfunctionalities in teams’ processes. In fact, disfunctionalities are often sneaky. Metrics and surveys can help you but you need to develop an insight to recognize them and this helps you improve a lot as person and professional.

I decided to share with you three thoughts I noted down in these years.

1. Training is not enough, make it real by being assertive (when necessary)

In these four years I did tons of training. Prepared tons of presentations on the various agile practices and artifacts: Kanban, Scrum, backlog and backlog refinement, pair programming are only examples.

One thing I learnt is that while training on agile is valuable, practice is more valuable. The capacity toward making practices real in day to day life is fundamental in the scrum master profession. In order to do that there are two different and antithetic approaches:

  • wait that a practice emerges in the team
  • be assertive and effectively contribute by pushing for the application toward some beneficial practices.

Being able to find the right balance between these two approaches is a fundamental key in a scrum master role. In a perfect world the Scrum master would always choose the first approach. But in the real world, this is not always feasible. For example, there could be situations where it is not possible to wait until the team becomes mature enough to adopt a practice. On these occasions, in my honest opinion, is when the Scrum master needs to be assertive.

2. If you want to go with Kanban, start with Scrum

I am assuming you are familiar with the Tuckman’s stages of group developmenthere.

The Tuckman’s stages of group development

It is harder to start directly with Kanban than starting with Scrum and transitioning to Kanban. In fact, Kanban requires much more discipline from the team than scrum. Pulling stories at the right time, limiting the amount of work-in-progress items, are very challenging tasks, even for a very small group of people. This makes Kanban more functional in the teams that are in the norming or performing phase or however not at their beginning. While scrum being more prescriptive, is perfect for a team in the forming and storming phase.

It is a good idea to start with Scrum and transition smoothly to Kanban when you feel the team is ready, or rather when the team is entering in the norming/performing phase. There are many indicators a team is transitioning toward the norming/performing phase:

  • stability in practices adopted
  • stability in team composition
  • continuous success of sprints
  • self-organization in main scrum ceremonies
  • stability in velocity and throughput.

3. Scrum application outside the software world often is not clear

While scrum is supposed to be an universal framework, in the sense it should be applicable outside of software world, this application is not always immediately clear.

In Hotels.com we give training on Agile to very different functions and we encountered difficulties in recognizing a way to apply scrum to certain realities outside of technology. For example there is not so much literature on how backlog items should be documented. Neither is clear how to manage realities where we have mostly personal work rather than team work.

Conclusion

I had four challenging years as Scrum master and this opportunity make me grow as person as well as IT professional. During these years I had the opportunity to reflect on some aspect of the Scrum master practices.

Particularly I discovered that the Scrum master need to be assertive and effectively contribute by pushing for the application toward some beneficial practices when necessary. The natural emergence of all the team practices is simply a Scrum myth.

I, furthermore, think that Starting directly with Kanban for a new team can be counterproductive. My suggestion here is to evaluate Scrum as bootstrap for Kanban.

The last point: the fact that Scrum universality (its application outside of IT projects) is not crystal clear. Under this point of view a great community effort to make Scrum more accessible is needed.

Thanks to Gayathri Thiyagarajan.

Deciphering Product Roles

Amanda McArthur | Talent Advisor, Expedia Group in Bellevue, WA

Product, Technical Product, and Program Management. If you are in the product world, you know the struggle is real. Companies (and sometimes even teams) have different definitions for each. It can be difficult to understand what roles are a strong fit given your background and personal career goals.

My goal here is to help you maneuver Expedia Group and find exciting opportunities with us that are more in-line with your experience or career goals.

First, the Program Manager:

In several large tech companies, this is a title predominantly used to describe someone who is closely aligned with Engineering. Generally speaking, within Expedia Group, the Program Manager is more focused on business process and programs. With one exception; the title Technical Program Manager is used in a few divisions and the responsibilities are similar to a Technical Product Manager.

This role is great for someone who excels at surveying the ‘big picture’. You enjoy finding and fixing inefficiencies. You build business processes and programs that scale, are streamlined and cross-functional. Like most other Product or Program roles, you are also an excellent communicator who is able to build consensus through influencing without authority.

While searching, I would consider areas of expertise as well and use keywords as part of your search to narrow your results. Maybe your area of specialty is talent acquisition, business operations, finance, or marketing. If you do have a functional area that you are focused within, do include it in your search.

https://lifeatexpedia.com/jobs/?keyword=Program%20Manager

Technical Product Manager:

Within the Expedia product ecosystem, we have both a Technical Product Manager (TPM) and a Product Manager. As a TPM, you are more closely partnered with Engineering teams.

All of our teams follow the Agile methodology, which means you can expect to attend (if not lead) daily standups. You will likely build user stories and participate in sprint planning. The lengths of our sprint cycles vary by team. Some could be as short as a week, others are a few weeks. We have a ‘Test and Learn’ culture and a bias toward action – giving our teams the ability to move faster with less red tape.

While most roles don’t require a background in software development, it does help in most cases. I’ve seen a lot of Engineers make a successful transition from development to TPM. It’s a natural progression for those wanting to take on broader responsibilities over product creation. You’ll partner cross-functionally with several teams. You act as a liaison and help your less technical counterparts understand technology constraints and possibilities. You’ll also help to communicate timing for execution, helping to prioritize feature work within the roadmap.

Keep in mind if you’re looking to move into Technical Product Management, there are some TPM roles that definitely need someone who comes from a hands-on development background. While this isn’t the norm, I have seen roles where the TPM would continue to own some code as part of their broader responsibilities.

https://lifeatexpedia.com/jobs/?keyword=technical%20product%20manager

Product Manager:

This is purely my opinion, but I believe finding the right Product role is pretty tricky. The level of technical aptitude needed to be successful is different for each team and depends heavily on the product space. Because most of our Product teams are dealing with digital products, the level of technical knowledge needed tends to be on the higher end of the spectrum.

That said, there are definitely Product Management roles that are more focused on stakeholder management, strategy, or user journey and UX. As the Product Manager, you own the roadmap planning, feature release cycles, backlog prioritization, varied levels of reporting, and product related problem-solving.

In general, all of our Product Management teams are going to be looking for someone who is comfortable working in a highly matrixed organization. Because a lot of products span multiple brands, you may have several stakeholders and they could be located all over the world. That means that not only will you work cross-collaboratively with UX, Engineering, Marketing, etc. you may also have the added complexity of working across brands. For someone who’s looking for more complexity, this may be perfect for you.

https://lifeatexpedia.com/jobs/?keyword=product%20manager

A few things to keep in mind:

Our teams are truly Global. I know, on the surface this doesn’t sound very different from other large tech companies. I’ll explain. I’ve worked with some companies that have a large global footprint; however, in a lot of cases, the product work was dispersed by location. London had their part, Sweden had another, and both were part of a larger body of work. In those cases, they had regular check-ins but the interdependencies were fewer which required less coordination. In our case, your immediate team may have a global footprint. It’s possible that you’ll be managing close dependencies where you’re coordinating with immediate team members located on the other side of the globe.

Your Search:

First and foremost, don’t be discouraged if one position isn’t the right fit. If you are a Product veteran you probably already know how unique each position is. Maybe you don’t have enough experience with complex information architecture, but nail the customer experience and user journey. Everyone has different professional experience and those are the things that will make you a unique fit for the right team.

All Things Agile – The Importance of Team Norms

Mouy Loeung | Software Engineer in Test II in Sydney

This article aims to answer the following questions around team norms:

  • What are team norms?
  • What is the importance of team norms?
  • How do we set our team norms?
  • How do we follow through?

What are Team Norms

Team norms is a relationship agreement or a social contract between the team members regarding the way they operate, interact with each other, deal with conflict and what is expected of everyone. This, in turn, will help promote positive behavior and discourage negative behavior.

What is the Importance of Team Norms

To understand the importance of team norms, I want to touch base on the agile definition of the stages of a team

Team norms help the team to focus on outcomes and drives towards a high performing team by:

  • By allowing the team to agree on a set of team behaviors, they will stick to instilling trust and respect within the team
  • Creating a safe and desirable working environment for open and constructive feedback and healthy discussions
  • Holding each other accountable for their actions and provides a sense of responsibility to promote self-growth
  • Removing assumptions by setting concrete points on what the team expects from their members and what is expected of them
  • Making teams self-organizing by promoting decision making within the team
  • Emphasizing communication, knowledge sharing and belonging to a “team”

Research indicates that team norms a.k.a  social contracts, if implemented correctly, have many positive benefits, such as giving employees a feeling of control and security in their relationships with their leader and teammates. These contracts also instill a sense of responsibility, accountability, and trust among team members. For the leader, these contracts help motivate desirable workplace behaviors and can discourage dysfunctional behaviors without heavy-handed surveillance.

How Do We Set Team Norms?

To make team norms brainstorming sessions successful, participants should come with an open mind and be willing to actively participate.

There are a few ways to set team norms:

  1. Split teams into 3-4 members and brainstorm, then come as one team and combine each team norms. This allows a more intimate feeling as there are fewer people to discuss with
  2. As one team, brainstorm together

Having a facilitator is also a great way to help move questions and suggest topics along if teams are struggling to build team norms. The following can be some discussion pointers that may help:

  • Working agreement – How decisions are made, core time and availability, expectations
  • Sprints – What is expected in sprint planning, standup, retros, day to day sprint activities, and achieving our goals
  • – Best way to communicate
  • Status reporting – blockers, updating the team, and communicating to stakeholders
  • Meetings and discussions – What is expected of each of the members in meetings
  • Conflict resolution – How do we solve them, what is expected of each member during times of conflict
  • Team expectations – What my team can expect from me, What I can expect from my team
  • Definition of Done – When is a story complete?

NOTE: It is important the team comes up with what they want to discuss as their team norms as opposed to providing them with a list of already made discussion points

How Do We Follow Through?

Once team norms are set, it is important the team continues to visit these norms so it is engrained into their day-to-day work. Here are some ideas:

  • Revisit 3-4 team norms every retro
  • Regularly update team norms to improve the effectiveness
  • Find creative ways to incorporate team norms in things such as bookmarks
  • Make copies of the team norms and make sure everyone signs it as a contractual agreement
  • Print out norms posters and put it around the team where it is most visible

Why not create a team norm bookmark so members can use them while reading agile books”  (smile)

References:

https://hbr.org/2012/04/to-ensure-great-teamwork-start
https://cdn.auckland.ac.nz/assets/psych/about/our-people/documents/Rosie%20Curwen%20-%20The%20Psychological%20Contract%20-%20White%20Paper.pdf
https://www.agileconnection.com/article/creating-team-norms

Career Check-In with Garrett Vargas

Garrett Vargas | VP & CTO, Carrentals.com in Bellevue, WA

What does your typical workday look like?

It’s really hard to call a day typical in an environment like CarRentals! Since I’m responsible for all parts of the technology that we use, it’s not unusual for me to meet with my teams to understand how current tasks are progressing, meet with the leadership team to discuss a strategic challenge, and get hands-on playing with new technology all in one day!

What have you enjoyed most about working at Expedia Group?

As someone who’s been a software developer my whole career, I like that Expedia Group gives me the opportunity to work close to the underlying business. Even at junior levels, software developers are expected to understand how their work provides business value which I didn’t see working at a tech giant right out of school. I think this makes our engineers more well-rounded in their approach towards problem-solving.

What makes your team unique?

CarRentals is the smallest standalone brand in Expedia Group, with only 150 employees worldwide. This gives us all the benefits that come with the backing of a large company like Expedia, but the start-up feel and culture that you get with a small group of people. CarRentals gives everyone a chance to interact with all parts of the business, work on projects across the board with a high degree of ownership, and really see the impact of your work in a way that’s harder to find in a larger team.

What accomplishment are you most proud of?

We recently completed a multi-year journey moving the CarRentals brands (in addition to CarRentals we operate two other brands – CarDelMar and AutoEscape) onto a single microservice-based technology stack. While we were a cloud-based platform prior to this migration, refactoring the code into microservices positions us for explosive growth and an ability to iterate and innovate much faster than previously possible. What I’m proud of with this feat is not just what we accomplished, but how we did it – making sure that we learned about and tried different AWS product offerings while building solid agile engineering practices that allow us to even better take advantage of this technological accomplishment.

Who has influenced you the most?

About ten years ago, I was at Microsoft working in an incubation group within Windows, and a large part of our efforts involved developing new business models. I found this interesting and decided to go to the University of Washington for an evening Technology Management MBA. One of my classmates worked at Expedia and sold me on the ability to work in a technical environment but much closer to problems that moved the underlying business. A few years after graduating, she had an opening for a development director at Expedia, and I moved here. She really focused on the transition process for me and helped ramp me on several aspects of Expedia which set me up for success here.

How and where do you find inspiration?

I am inspired by a learning organization – I like working on side projects playing with new technology to learn what’s out there. One of my favorite interview questions is to ask someone to describe some side projects or hobbies. When I see someone who gets a spark in their eye and a passion in their voice as they talk about their “labors of love,” I know I have someone who is a continuous learner and will do well in my group.

How did you learn to embrace failure?

Learn from it! When I first became a development lead, I thought my job was to divide up tasks for my team while keeping the “grunt work” that no one wanted to work on for myself. While it made my team happy, it kept my focus off the big picture while I gained a deep understanding of the mundane tasks (not exactly what you want your dev lead doing!). I didn’t have that leadership position for long – and by reflecting on this failure, I was better positioned when the next lead opportunity came along.

What is your favorite piece of career advice?

Be an owner. No matter what you do or what you’re responsible for, think like an owner and understand the big picture. You’re not just working on a small feature in isolation – it’s part of a larger customer experience or product offering, and if you think about what you’re building end-to-end not only will you be able to do your job better (delivering what *actually* needs to be done, not just what you’re told to do), but you’ll demonstrate an ability to understand and take on larger projects to grow your career.

Tell us about your favorite vacation?

Two years ago, my family went to Europe. We wanted to visit England, France, Italy, and Germany and decided to take a train to get from city to city. Traveling by train in Europe is a wonderfully scenic experience, and as I was working on our new Rail product offering at the time, it gave me an opportunity to experience first-hand the full travel experience – from booking through various methods, with a different website for each leg, to actually relaxing and enjoying the ride.

What is your favorite weekend getaway?

I’ve always been a fan of Las Vegas – so many different experiences in one area, located out in the middle of the desert! While I’ve been going to Las Vegas for several years, this last summer I drove there from L.A. for the first time, and I really appreciated that “middle of the desert” aspect!