If you’re a developer, chances are you’ve at least heard of agile by now, if not worked in an agile development team.
Teams that follow agile project management will structure themselves (and their time) a little differently from traditional project management environments.
While it’s great if your agile developers love to workout together on their lunch break, working “agile” is a little different from physical agility.
When your team is agile, they’re able to adapt their approach and respond more quickly to demand, ensuring your product keeps up with changes in the market.
What is agile development?
The key difference between agile and waterfall/traditional project management is that agile development teams release and test updates and features continually.
To do this, developers need to operate in small, self-contained teams, communicate more regularly (ideally face-to-face), and do smaller releases each time.
More organizations are building agile development teams to improve efficiency and speed-to-market. But not everyone follows the same agile practices, and not all agile transformations go smoothly. So we thought we’d share a few tips to help you improve your chances of building a successful agile development team – or help your current team work better together.
5 tips for adopting agile practices
1. Let go of formulas
Pure agile isn’t realistic for most teams, so look at the different agile practices, methodologies, ceremonies, artifacts, and principles, then pick what’s likely to work best for your team. You might like scrum, sprints, kanban, stand-ups, retrospectives, roadmaps, increments, backlogs, SAFe … or all of the above. Remember, the goal isn’t to “be agile” or follow a strict formula. The goal is to get your team to gel so you can do better work together with less friction.
Every single human is different, and thus every single team is different. So, you can’t have a one-solution-fits-all kind of approach. You need to listen to the team, and over time, you work out what solutions help you gel.
2. Get clear on roles
One of the biggest changes when going from traditional project management to agile project management is how the team goes from managed to self-managing. The agile development team should have all the skills and members it needs to release software updates. This should include:
- Product Owner – Like a mini CEO. More marketing than engineering. Decides what upcoming features to prioritize, manages external stakeholders, and balances KPIs against other priorities.
- Scrum Master – Like a project manager. Focused on achieving the current sprint by preparing for it, managing it, unblocking the developers and analysts, answering the team’s questions, and helping them stay focused and in flow.
- Analysts – Problem solvers. The product owner gets support from analysts to better understand problems and solutions, and translate them into actions – like new features, designs, updates, and systems. They figure out what’s required and what all the details look like.
- Developers (Junior/Senior) – Creators. They work on new products and features, or bug fixes planned for the current sprint.
- Testers – Do a mix of automated and manual testing to ensure code is bug-free before it’s deployed.
In smaller teams, fewer people might wear more hats, but generally, all of the above roles need to be accounted for in an agile development team.
3. Increase transparency
When you’re continually developing, testing, and releasing software, your team members need to be in constant communication with one another. And your teams need to be transparent with each other to ensure that any dependencies are minimized or managed. It’s important to be upfront about progress as well as any challenges you have ahead, whether product or personal. Transparency has a lot of benefits, because if your team members can see that you’re human, they’ll be more willing to express their feelings and share their ideas without fear of judgment.
Regular face-to-face meetings (like a daily stand-up) can help with transparency. But it’s also ideal if you keep everything you’re working on in a cloud-based project management system, especially if some of your team are distributed/remote and can’t meet face-to-face.
Transparency is key. I think one of the challenges that experienced developers have is sharing when they’re wrong or when they don’t know something. I find it’s something that regularly happens with the technical skill sets in the team. If you don’t know something, tell the team. It should be well accepted.
Fortunately, transparency feels a lot safer for your team when you make them cross-functional.
4. Go cross-functional
Part of making your agile teams self-contained includes working with people from other teams and departments so you can get things done. It’s like making your team into a mini version of your company that can (to a degree) operate independently.
This includes working with people from marketing, legal, HR, and other departments to ensure you can deliver the work you’ve committed to for your sprint.
5. Cross-skill your team members
Effective agile development teams help their members develop a T-shaped skill set, which means each person has their deep area of expertise, but this is complemented by broad expertise across other roles. Or, for example, one team member might learn a new technology and then roll it out and share it with the others.
This minimizes dependencies because team members can step up and remove blockages, even if they’re not directly responsible for them. It’s especially important to help share the load when a team member is sick, on leave, or something else comes up. It makes for a much stronger team overall.
Cross-skilling means a willingness to seize opportunities to learn new skills within your role, and pick up surface-level skills from other roles. This could involve taking on a task you wouldn’t normally do or investigating a new technology. Occasionally, you’ll have to temporarily pull back on learning opportunities to efficiently complete a sprint, but it’s about trying to balance the flow of the work with room for individual growth.
Agile is different for everyone
We’ve already touched on this, but every agile development team has their own take on what agile looks like for them. Implement these tips, but don’t feel locked into doing agile in any particular way.
We’ve shared more about this in our next blog, which is about how we’ve adapted agile concepts to work for us here at Tiny.
Make sure you’re following us on Twitter so you don’t miss it!
