This is a brand-new post from the ZenHub Blog. Let us know your thoughts below!
Product Owners, Help Your New-to-Agile Team Members Get Up to Speed Fast
Nine lines of text rarely have the power to change the world for the better. Agile is one exception to this rule. The original guiding principles of Agile thinking helped propel software development teams forward to build revolutionary products.
Today, Agile has broken the bounds of its original wording and become commonplace in teams across many industries. Take me, for example. I’m a marketer, not a software developer or project manager, but I’ve come to use Agile principles and methodologies in my everyday work.
Don’t be misled, I’m 100% an Agile newbie.
But before you write me off – I’m here to help and provide my unique perspective on what it’s like to start in an agile company without any previous knowledge. Agile thinking can seem unapproachable for people new to industries that rely on its frameworks. Whether you’re a developer, a manager, or a marketer like myself, having a roadmap to ensure that any new member of a team is set for success in an Agile environment is critical. As a product owner, building out this roadmap is the first step towards setting up your new-to-Agile team members for success.
Agile isn’t something that’s taught in schools (but that might be changing!). Instead, Agile needs to be learned on the job or during onboarding. Having a clear and structured process to make this as quick and effective as possible can help your team reduce onboarding time and improve team cohesion.
Here are some steps that will help you take new-to-Agile team members on their journey to become Agile experts, coming from someone who is on that very journey.
Stage 1: Start with the Agile basics
Yes, we all want our new hires to hit the ground running. But sometimes it’s best to start by taking a step back and evaluating the best direction to run in. I can say from (recent) experience that getting a solid start can make or break anyone’s first Agile experience.
I was lucky enough to have been pointed in the right direction towards countless resources that kickstarted my Agile learning. Of course, that means reading. A LOT of reading. Some great resources for beginners include Agile Alliance’s Agile Essentials and Harvard Business Review’s Embracing Agile.
Contrary to popular belief, in my personal experience, the most daunting thing about adopting Agile thinking was not a change of mindset. Instead, the sheer quantity of jargon and terminology took quite a bit of getting used to. Terms like story points, epics, sprints, and all of the various ceremonies were completely unfamiliar to me. At the same time, these terms are used so commonly in Agile teams that it can be difficult to get by without understanding them. That’s why the best way to start off someone on an Agile team is to encourage them to take the time to understand the jargon before jumping into trying to fit into the framework – or provide definitions along the way
I would also recommend checking out some longer-format material. For example, there are countless books such as the Scrum Guide, or (shameless plug incoming) ZenHub’s eBook Project Management for Teams in GitHub.
Sharing resources like these with your new hires will kickstart their learning, and will ensure that they have everything they need to move in the right direction.
Stage 2: Understand your team’s flavor of Agile
Now that all of that reading is out of the way (phew!) the next step is to apply all of the basics. But that’s much easier said than done.
The simple fact is that if you take one hundred different Agile companies, you’ll get one hundred different versions of Agile .
This is why taking the time to develop a framework for new team members to understand Agile at your organization is so important. Even different departments of the same organization can have different styles of Agile, and so recalibration for new team members (new-to-Agile or not) is a critical first step towards integrating them into a team.
At its most basic, Agile can be divided into different frameworks. These include Scrum, SAFe, Kanban, Extreme Programming, and many others. One of my favorite visualizations of the different variations and their specific terminology is Agile Alliance’s Subway Map to Agile Processes. This shows just how complex Agile is, and how teams often pick and choose which terms they want to use. Take a look and see how many of the terms you use at your organization, you might be surprised.
It’s also worthwhile to look into frameworks that your team doesn’t use. Often we can pick out specific ceremonies and practices that help out the team, and being proactive about incorporating these can make a big difference. For example, Kanban and Scrum are two different frameworks, but there are elements of each that can coexist. Having a complete understanding of these two frameworks will allow your team to adopt the elements that work best.
There are two different key areas that you need to take into account when developing a plan to introduce new team members to your version of Agile: communication and technology. Don’t forget to document your processes, so new team members have something to refer back to.
Communicate with your team
Here’s the thing about Agile: people are passionate about it and are eager to learn. Yes, you can learn the theory of Agile on your own and become an Agile expert. But, learning the intricacies of your team’s Agile system relies on the idea that everyone is on board. On a personal level, I have found that there was a lot of support on our team for the specific version of Agile that we use. Being in marketing, we don’t necessarily have as many elements as a development team would have.
If you’re a manager helping team members learn your unique flavor of Agile, encourage questions and be open to feedback. We must continually iterate and optimize our practices to ensure that we’re doing what’s best for our team. After all, teams change over time and so must our Agile practices.
There are often naysayers on an Agile team, and this is often the result of frameworks and processes that are poorly matched to the needs of the team. A quick scroll on Reddit’s r/Agile shows that often developers are at odds with the processes that have been set out for them. Just as a developer should be consulted about their tech stack, developers need to have a say in the processes and frameworks that they work within.
Get on board with your company’s software
For any of your new hires, there’s bound to be an onslaught of software solutions being thrown their way. Logins left and right, and different pieces of software for a wide variety of functions. These tools were built for the most part to make your life easier, not harder.
Software is often the best way to make complex Agile concepts super easy to understand and digest. For example, the marketing team at ZenHub uses a Kanban-heavy version of Agile, and the ZenHub board was the perfect place for me to play around with building Epics and moving issues through pipelines. Sure, it can be done on a board with sticky notes in person, but the ease of use and visibility of online tools shared by the entire team can’t be beat.
This is where learning by doing really is the best way to learn to be Agile. By learning to use tools that they’ll be working with on a daily basis, new team members can get a much better understanding of the way that Agile works at your organization.
Stage 3: Taking the Next Steps
Your new hires have now read up all things Agile, collaborated with your team to get comfortable with your specific form of Agile, and are familiar with the software that will help you stay Agile. But what next? Your new-to-Agile team member is ready to go. They might even dream about Agile methodologies, surely there’s nothing left to learn?
Of course, there’s still more to learn! Remember that Agile mindset we set aside earlier? Now is the time to bring that back. Knowing about Agile is one thing, being Agile is another. It’s putting everything that you’ve learned into practice that can be the tough part.
This is the part that I myself am still working on. It’s easy to forget to move things on a Kanban board, but it’s even easier to close an issue and never look back. But Agile thinking is more than just opening and closing issues. Instead, it’s reliant on the overall mindset and your ability to see the bigger picture, realizing that every issue is just part of the constant iteration that Agile demands.
Having an Agile mindset takes time, it can’t be taught. But once you have it, you’ll always have it. It’s this stickiness that’s helped Agile move beyond just software. It’s in government, in medicine, and many many more industries thanks to champions who have broken the bounds.
My final piece of advice would be this: help your team members find what form of Agile works for them, and encourage them to use that everywhere they go. Agile isn’t meant to be cumbersome or daunting, it’s meant to make the world a more experimental, more iterative, more collaborative place.
Since y’all are Agile experts, what advice would you give me as an Agile newbie? Is there a critical piece of the puzzle missing that helped you on your first Agile team?