Our guest
Jennifer Dempsey, technical product marketing manager at Appfire. Jennifer is a certified scrum master & project manager with more than 12 years of experience helping organizations attain their marketing objectives. Currently, Jennifer helps create marketing messages catered toward software developers and DevOps teams.
Listen to this episode
Transcript
Gosia: Today I’m here with Jennifer Dempsey, technical product marketing manager from Appfire and certified scrum master. Hi, Jennifer.
Jennifer: Hi.
Gosia: Jennifer, I think that in the Agile world, the term empowered teams is heavily overused. So many teams I see don’t have the liberty to make their own decisions. Today, we’re going to talk about should developers pick the tools according to their personal preferences. What is your take on that?
Jennifer: That is a great question. There’s a lot to unpack there. I’m going to have to say it depends.
Gosia: It depends on the team, or on the organization?
Jennifer: Yes. I think the goal is always to respect developer autonomy, to allow a developer to work in their platform of choice, and to allow them to customize their individual way of working. But I think the size of the organization is really what makes that more challenging as organizations get larger.
Gosia: Right. So, would it be more difficult to actually let the teams pick their own tech stack in larger organizations? If it’s more difficult, why is that?
Jennifer: I think if you’re thinking about a small team of developers, maybe one to five, probably a smaller organization, their decision around what tools they choose is going to be based highly on budget. They may be leaning more toward a free tool.
That tool may be unsupported. It may work very well and solve the problem for the developer, but two or three years down the line, if the developer of the tool stops updating it, it starts to have bugs and issues, and the developers need to leave that tool and move over to a different tool, the impact in a smaller organization just isn’t going to be as great in a situation like that as it would if you were a midsize or an enterprise organization with hundreds of developers who might be using the tool at that point.
That’s definitely one factor. I think another factor is around collaboration. If you have five developers and they’re using five different tools, but it’s still a small enough team that they can catch each other up on updates and what they’ve been doing, the collaboration is much easier in a smaller team than it would be with a larger team.
Gosia: Right. Is there a risk? Let’s say we’re in a big organization and we have a couple of scrum teams, and each of them is using different tools. Would this increase the technical debt, is there a risk of that?
Jennifer: Definitely. Tech bloat, as well, just too many tools and that creating inefficiencies. Also, when you’re talking about reporting, tracking of information, transparency across teams, having different developers using different tools creates issues around that as well.
To go back to the earlier point about unsupported tools and the risk that can bring, not just related to bugs, but to security as well. If those tools aren’t being updated on a regular basis for security, that’s putting the organization at risk as well.
Gosia: Right. What would be the best approach from your point of view for these bigger organizations that this causes more issues if a couple of teams work with different tools?
Jennifer: I think one of the strategies that you can use is to have the developer team be involved in creating and voting on a short list of tools that they would like to use, and then the organization can approve that list and the developers can choose from there. I think that gives them a sense of ownership over that process.
I think something else that you can do is look for tools that are customizable for the user. In Jira, even though that may be a standardized tool that the whole organization is using, there are a lot of options there for how you want to set it up for yourself personally. Maybe you prefer a Kanban view, maybe you prefer a project-level view. How you set it up for yourself and how you manage your own tasks, having a tool that is customizable like that for the individual gives them a greater sense of control and autonomy.
I think the last recommendation I have on that point is around integration. If you have a developer who is using a tool that’s their platform of choice, they really enjoy working in that platform, rather than forcing them to move to a different platform that maybe another part of the team is using, or in the case of an acquisition you have a new team coming in and they’re using a different tool, an integration tool is going to be able to allow both of those teams to continue working in their platform of choice. Then you don’t have those issues around context switching, there’s less issues around knowledge transfer, trying to get up to speed on the new tool, and nothing has been forced on them.
Gosia: That’s brilliant. Integration sounds like a great compromise. Let’s say, if an organization forces the tools on the team, is there a risk that this impacts experimentation and growth? Like you said, it’s so important that developers have their say in picking the tools. The organization shouldn’t force, but should let them vote. Right?
Jennifer: I think as much as possible. There’s always going to be that push and pull between autonomy and standardization. I think communication is going to be key. Does the developer team understand why this tool is being used, why they’re being asked to use it. I think making sure that they’re involved in the communication and the decision-making as much as possible is really the key to that.
Developer satisfaction, happy developers are going to be more productive, they’re going to be more efficient, they’re going to be more engaged. It’s just going to be better working conditions for everyone.
Gosia: Definitely. I think developers on the team know exactly what they need to perform a particular job. I know that I love some marketing tools that I’m always pushing for them because I know that they are amazing and trying to convince others to use them as well. So, yes, definitely that is very important.
Can you recommend if they vote, or if they have a list and they have a say which tools should be included, should this be revisited after some time? I don’t know, after half a year, or every year. What do you think is best?
Jennifer: Life moves fast. Doesn’t it? Especially in the technology space.
Gosia: So, is six months too long?
Jennifer: I don’t have a hard point on how often to review that, but definitely do. Maybe even once a month. Quarterly, for sure. There are changes in the marketplace that happen. As the organization grows, their budget and what they can afford may change. It may make sense at that point to go to a more standardized approach.
Change management, just lead into that gently. Put a lot of communication in place and just communicate with the team before you make those kinds of changes. Let them know that their voices are being heard.
Gosia: I think that’s essential to motivate everyone. There will be a better outcome if the team actually feels involved. Definitely, that’s super important to revisit that and have this conversation, maybe every three months.
One last question. Let’s say the team is already working with a selected tech stack and someone comes up with an amazing tool. What would be the best way of either persuading or what should this person do to maybe show the benefits? How to approach it to show the team maybe we should start using this?
Jennifer: I think that can be a challenge. Of course, senior leadership and executive leadership are busy. I think an introductory email asking for maybe 10 minutes with the engineering manager, CTO, whoever might be the decision maker, and using that time really efficiently and effectively to outline the research that you’ve already done that explains why this new tool would be of benefit not just to the team, but to the organization at large, how it would help to support their revenue goals or increase efficiency on the team.
From there, perhaps ask for a larger meeting with more of the decision-makers, putting together a deck or some other kind of presentation, just metrics, having those stats to be able to support the request. Then it’s not just a personal request, but it’s something that is going to benefit the team and the organization at large.
Gosia: Right. Would you recommend, let’s say, if the team test it out for some time and then present we tested it for a month and these are the numbers and if they even show that this tool is not only beneficial for their team but to the whole organization, they will be able to persuade the higher management?
Jennifer: Exactly. There can be a disconnect sometimes between leadership and some of the pain points that are going on with developers. That’s a great opportunity to address those as well. The reason why we’re requesting this tool is because we’re running into roadblocks, or the present tool we’re using is slowing us down, creating frustration, developer satisfaction is down. It may even be that you can quantify that with exit interviews from developers who have moved on to a different role in another organization. Having that evidence is very helpful.
Gosia: Right. A larger understanding of how this tool will really benefit everyone. This is a pretty cool idea to use exit interviews and realizing maybe we should listen more to each team member’s feedback because then they feel more valued and they take ownership, which makes the team more empowered.
Jennifer: Exactly.
Gosia: Great. Thank you so much, Jennifer, for this chat. Thanks to everyone for watching this episode of Agile on Board. Check out our previous episodes and subscribe to our YouTube channel so that you don’t miss future episodes when they go live.
Take care. Bye.
