Agile, Kanban, and Scrum buzzwords that have gained popularity in the engineering and project management fields over the past decade. They’ve evolved out of the Agile Manifesto published back in 2001. Yet, each framework can be seen as a starting point, with organizations of different sizes and priorities finding a way to adapt it to what suits them.
We had a chance to sit down with Hector Reyes, an experienced Scrum Master and Senior Project Manager that has been implementing these practices across diverse tech teams, from healthcare, finance, retail, and now the cloud.
He really is a master in project management that has experience driving teams towards objectives for large companies for more than seven years. He’s played a fundamental role in executing ideas, implementing process improvements, and coaching team members about agile and scrum best practices. Even in challenging environments that resist change.
In our conversation we talk about remote work, general management, and engineering management practices, taking a deep dive into agile project management and how to best use it for different company sizes.
Hear the podcast episode here:
Remote Work
Have you ever worked remotely with a team?
As Scrum Master, the team can be in India and the U.S. project owner, so that qualifies for working remotely with a team. However, I’m usually in an office setting working directly with the tech team at the company I currently work in. Of course, because of lockdown, we’ve all moved remotely for the rest of the year.
How did shifting to remote work impact your everyday activities?
Since I’m so used to communicating via Slack or other tools alike, there was no constraint around, “I got to see the person to get the job done.” So I was ready for remote work and virtual communications. However, it’s not the same for everyone; some folks rely on face-to-face conversations and meetings to make decisions, that’s where frictions happen. But as you lead the way in virtual communication, they follow it.
General Management Practices
Management is no easy task, and there’s a lot of different ways to approach it. In your eyes, what’s the role of a manager?
A manager is there to guide you as opposed to acting as a leader. Managers provide leadership making the team aware of where we are going as a team and what’s the road map.
Managers also make sure no one is falling behind, and if somebody is falling behind, they identify how as a team, not just the manager, can help them succeed.
As a Scrum Master, it’s quite interesting, because I have to lead and manage with cero authority because nobody reports to me, which makes it more challenging when I’m trying to make changes.
From your experience, how do you approach when individuals are resistant to change?
It is more art than science. You always have to listen because you never know what a team or person has gone through, what took them to where they are right now. Maybe they had a different approach with another agile practice or perhaps they tried something a couple of times and didn’t work out. So you have first to understand the background of the situation. Talking to key engineers in the team and not just other managers is a big part of it. There are always engineers leading the group without them knowing or holding the responsibility of a leader as a title. Listen and understand what they are trying to accomplish, to solve, to change, and why.
When you can prove that you are listening and taking everybody’s consideration when implementing something, they immediately switch to – Oh, this person is really on our side – that means that yes, you will be leading, but we, as a team, are all driving the change.
Engineering Team Management Practices
Managing a remote tech team is an entirely different animal than just managing a remote team. Let’s dive into that. You’re an expert in Agile Project Management.
What’s the one thing people usually get wrong or misunderstand about Agile?
People think that Agile will make them deliver faster and that you can change things like crazy. Many people believe that Agile is built to be flexible, but in my experience, shifting the workflow will end up confusing the team.
To me, Agile is more of a mindset, is a way of doing things, not necessarily a framework. Nobody can use Agile, Scrum, Kanban, or any framework the way the textbook says because that’s not real life.
The point is not to be Agile, it is to be efficient.
As an Agile PM, what’s your number one goal?
To make everyone in the team aware of our mission and how we upgrade to achieve that goal, while also understanding the role of each engineer and how their role brings value to the project.
How do you get started with Agile project management? What are the first steps modern managers should take to implement this methodology?
In no particular order:
- You know who your customers or users are. Are they the team that sits next to you, or your sales team? The customer or user is the person that will be consuming your product.
- Understand how the team prioritizes its work. What’s the intake funnel? Are we getting requirements from our users? How do we get them? What are the mechanisms for us to get requests? It could be anything, like a phone call or a ticketing system.
- Identify who will be responsible for answering the “what are we going to do?” in the team, that could be a Project Manager or Product Owner. What’s the criteria for us to say that’s something’s worth doing. Is it based out of revenue, dollar amount? Or if it’s coming from the CEO, CFO or C-level. Or if the prioritization is based on who yells the loudest – because that happens a lot. They are the ones that will prioritize the work.
These allow you to understand your surroundings, your context – the who’s, the what’s, the when’s. From there you would move to agile.
Also, do not assume everyone has the same definition of Agile as you do. So it is vital to level-set everyone to make sure everyone is on the same page. If you ask folks that have done agile in different industries, everyone will give you a different opinion, everyone understands it differently. So it’s important to have everyone on the same page.
You can do a quick role and responsibilities workshop and answer:
- What are our team working agreements?
- How are you going to define work is genuinely something actionable?
- What’s the definition of done? Does it have to be in production, or ready for QA or in staging?
If everyone has the same answer to how we’re going to get to our objective, it’s the number one thing to get started.
Then you can layer down all the agile practices.
What’s the next step after this?
It’s how we’re going to measure we’re being truly efficient. What are the numbers that we’re going to measure to drive our improvement? This is where an expert should come in because if you delegate that task to a people manager, it’s pretty complicated for them to be objective with the team to measure what you need.
If you define: these are our goals and this is how we’ll be measuring them in the short, medium, and long term. Then you can use those to know you’re on track.
Start with the basics to get a grasp on measuring data.
- Burndown
- Ticket Velocity
- Story Points
As your team matures, and you’re able to generate and gather more data, you’ll evolve your metrics to define what’s success is and what it’s not.
One of my favorite metrics is the committed-to-completed ratio, which basically tells you how predictable a team is in terms of work done.
As a manager, if you can say – this is what my team can do in the next month in terms of effort – with at least 95% confidence, you’ve succeeded in proving efficiency.
Are there some qualifiers to see if a company is eligible or qualifies for Agile?
In theory, considering what I mentioned previously that Agile is more of a mindset, everyone, not just IT, should ideally qualify to implement Agile’s concepts. If you go to finance, HR, or marketing they should be able to use it. They all have projects, objectives, and deliverables, so it should work for them. Construction, maybe that wouldn’t work, but in some other areas I mentioned will work.
In a sense, the less you know the more you qualify for agile. It’s based on an iterative process, where you don’t have 100% context on what the project will be. In most projects, you’re usually given a problem, and you have to get creative to find a solution and define a project. If you have a 100% defined project and you have to execute, well then it wouldn’t make sense in using agile, you could use it to execute, but you wouldn’t get a lot of value out of it.
Who would qualify for Kanban, Agile, or Scrum? Why would they be eligible for one but not the other?
Timeboxing and defined timelines. Shipping incrementally. If you can make this commitment and say you can put tasks in a timebox or sprint, then that’s scrum at a super high level.
Kanban is about repetitive operations if you have an operations team. If the effort of completing one task is pretty similar from one another, and you’ll be measured on how many tickets you’re closing, or how fast you’re moving them, or how much time that ticket spends in one area, then to me that’s more of a Kanban qualifier.
If you’re an operation’s team it’s hard to plan for two weeks or a timebox doesn’t make a lot of sense, because once you get started you’ll get bombarded with emergencies. Then it doesn’t make a lot of sense to use scrum.
Also, there’s nothing wrong with using a hybrid approach for teams that are developing and fixing fires and problems at the same time, which is the case in small and medium businesses.
My recommendation is to have a dedicated team or person that’s outside of the scrum bubble working on putting out fires. Implement a rotation program so that everyone gets to work on putting out fires, without interrupting the scrum bubble.
I would not recommend that if you’re doing scrum, try as much as possible not to include all the fires within that same sprint or board. Try to have them at least on a different board and in a different place to reduce the mental load.
What are some of the standard metrics that businesses use to measure tech teams?
- Velocity
- Committed-to-Completed Ratio
- Release Trend
Metrics have to be shown in combination with others. It’s the whole context that these provide that it really adds value. These three are relatively easy to get and are really helpful.
Release trend helps you when you have the flexibility to map all your requirements and allocate efforts to them via hours or story points to show you a trend to hit your goal. It’s very helpful because it gives you leverage when a decision-maker or an unforeseen task or change comes in, you can confidently say that the release date will be pushed out for X amount of days and it’s not you, it’s the numbers. It gives you a good foundation to say – ‘I can put something in this sprint, but I have to get something else if we still want to hit that deadline’. It becomes transactional.
How do you know when you need to hire engineers to meet the goals?
If you’re able to get your team to a steady state where you can get to that predictability point with your engineering team, and still you’re in a position where your customers are not entirely happy because it’s taking too long to release, then that’s an indicator. If you’re constantly delivering value, but you could be delivering more value, assuming that the requirements backlogged are truly delivering value.
If this happens then you analyze what’s the pain. Are we lagging in the front end, or the back end, are we lacking quality? Then you can start making decisions.
Another conversation starter is when you’re analyzing the product roadmap and as the project manager, you realize that it looks massive and you won’t be able to hit that goal. So you say, if you want me to hit that goal, then we need two or three more resources. If it’s truly important for you as a business, then we need more people to do it.
It’s always a tough conversation.
Last Word
When it comes to managing your team, you’ll find many methodologies and approaches to get things done. Scrum and Kanban are both helpful tools to get work done in a structured way that delivers results. Companies of all sizes from small, medium to large can benefit from these project management practices. However, the implementation level will vary differently, as team size and data collection vary from size to size. In a nutshell, this allows you to make better, more informed business decisions that will impact your main revenue driver – your customers.
Discover more useful advice in our guide to “Managing Remote Software Engineers.”
