The missing piece in your Agile process: Start growing your dev team!

Teams usually adopt an agile process in order to achieve a happier customer, a happier team and a happier manager — see this previous post for more on that. But by having a good agile process teams can achieve other great benefits as well. One of these benefits that most of you probably aren’t focusing on, is growing your dev teams to be mature, responsible and effective.

And it‘s no surprise this is not what you’re focusing on. It might be clear how being agile can contribute to your delivery and the value you’re providing. It might be less clear how being agile can contribute to your engineering team’s development. Also, it’s more straightforward for managers to work on team members’ personal development than on team development. But it’s a shame this aspect is sometimes overlooked. In the long run it’ll help the team deliver more complex features with higher quality and in less time.

In this post I’d like to highlight how to elevate your agile process — mainly the sprint planning, daily standups and sprint retrospective — to allow and encourage your engineering team to grow and develop.

Sprint Planning

Agile teams usually start their sprint with a planning session where the product owner and the team discuss upcoming tickets. The goal is to set the scope of the coming sprint (a.k.a the “sprint backlog”) and get the team’s commitment to that scope. The sprint planning is a great place to grow the team — or keep it from growing.

The planning should definitely not be where the product owner lets the team know what they’re expected to achieve this sprint. I know, it’s tempting… But this kind of approach puts the team in a place with very little responsibility and no real commitment. Instead, the product owner should highlight the team’s priorities for the coming sprint, go through each relevant story and present what’s required. Then it’s the team’s job to make sure the ticket is ready for work and the acceptance criteria is clear.

The team may ask for clarifications. They may ask questions the product owner doesn’t have the answer to or hasn’t even thought about. They may raise concerns or impediments. And in case it has a major effect on the complexity/dependencies of the task, they may need to discuss the implementation on high level. Great! These are good things! As long as the discussion is effective and well-facilitated, this is an investment of everyone’s time that will return itself. The team needs to do that so they can:

1. Estimate how much time these tickets will take, and
2. Actually start working on these tickets once planning is done and the sprint starts.

Some tickets are ready for the sprint. Some tickets may not be ready yet and should be put back in the product backlog. Others may require more preparation and we need to do some research or talk to some other team so we can start working on them next week. You go through the tickets, add them to the sprint backlog one by one and discuss each of them. At some point the team says “that’s it, this is the amount of work we believe we can do this sprint”. If you’ve been around, you already know making this decision is a complicated thing by itself, and we’ll keep it for another post.

If you don’t do the above, three things are very likely to happen:

1. The team won’t be able to truly estimate how much they can get done during the sprint. They won’t be able to commit to anything with some degree of confidence.
2. All these questions they didn’t ask during the planning? They’ll start asking them once they start working on the different tickets. And that’s much worse.
3. The worst thing is that some of these questions might not even be asked by anyone at all. And they will make a comeback — as bugs due to misunderstandings or things nobody thought about.

This will happen, I assure you.

Actually, unless you’re working on a very simple project, it’s probably already happening.

If you do encourage your team to be more active in the sprint planning, you’ll be doing them and yourself a huge favor.

1. The team will understand the scope and challenges of each of the tickets, so they’ll be able to commit to a defined sprint backlog with a good degree of confidence. Obviously this is great because now everyone gets a good sense of where you’ll be when the sprint ends. It also pushes the team to keep up with what it committed to. You will have a sense of accountability as a team.
2. Agreeing on a sprint scope is great for another reason. It sets the ground for the team to look back at the end of the sprint and ask super important questions. “Did we manage to hit our goal? why? how can we get better next time?”. It will be clearer how and on what you can improve as a team.
3. The more they ask questions, raise concerns and discuss these tickets — the better they’ll get at it. They’ll start asking the right questions and raise important concerns. They’ll have more efficient discussions. More people will participate. You will become a better team.
4. Bonus: The product owner will also learn what types of questions and concerns are usually raised. As time goes he’ll arrive to the planning more prepared.

The team should also be responsible for adding and prioritizing engineering tasks. This could include areas such as monitoring, error logging, upgrading 3rd party libraries etc. They know the product’s engineering side best, so they should be responsible of these tasks. If you encourage them to do so they will raise important issues and this will lead to a more stable, robust and faster product with less bugs and downtime. This will also push them to be more proficient and proactive, to think more about the product, and even to learn more about these topics.

The sprint planning is a conversation. And in that conversation, the team is a participant, and a valuable one.

The more you encourage the team to participate in this conversation it will lead to faster delivery of more quality features. And the more the team participates, it will grow and become stronger, more proficient and more responsible.

Daily Standups

The daily standup is a quick daily meeting agile teams hold to catch up and sync on the their tasks. A lot of teams use the famous three questions practice to have an effective session.

So we have a daily meeting where all team members take turns in talking about their progress yesterday and what they plan to achieve today. With the team lead present, that’s basically the perfect setup for… micromanagement. Even more so if that team lead is a dominant figure (and many times they are). An interesting symptom that you can see in a lot of teams is team members talking mostly to the team lead when they give their update. It’s just a very human thing to do.

If you let yourself fall into the “daily micromanagement” pitfall you’re keeping team members focused only on their current tickets. They focus on their current tickets all day, and at the standup they should also focus on the team’s goal to complete what we committed to. You’re basically encouraging them to keep a very low level of responsibility and accountability. You’re missing out on a great opportunity to grow the engineering team.

Let me be very clear about it:

• The goal of the daily standup is not to see where each team member stands with their current task, but rather to get a picture of where the team stands with their sprint backlog. Talking about each person’s task is very helpful in drawing that picture, but it’s not the end goal.
• The goal of the daily standup is not to provide the team lead with that picture, but to provide the team with it. The standup is a great place for the team lead to get visibility on his team and their progress, but it’s not the end goal.

The team is the owner of the sprint backlog. This is very important so I’m going to repeat it:

The team is the owner of the sprint backlog.

And it’s the team’s job to do whatever they can to complete the sprint backlog by the end of the sprint. The daily standup is a tool which serves to help the team understand their progress versus the sprint backlog. It’s their opportunity to communicate, see where they stand and adjust accordingly. If there’s a problem with one of the tickets we can notice it together and communicate it to our stakeholders. If one engineer is stuck, another engineer may offer help. If there are many items waiting for code review, the team might make a decision to not start working on new items before reviewing those. If we’re getting close to the end of the sprint and there’s a big ticket we haven’t even started yet, the team may decide to make that the next ticket. The team owns the sprint, we sync every day and regroup as needed, as a team.

By applying this state of mind in your daily standups, you’ll remove the dynamics of the team lead and product owner as the only people responsible and team members caring only about their tasks at hand. It’ll be replaced with dynamics which allow the team to take ownership, encourage them to be responsible for their progress and results, and make them face daily challenges and find solutions as they go. The beauty is that once the team is proactive and takes responsibility there’s much more to learn from and improve on when the sprint ends.

When team members make comments on where you stand as a team considering the sprint backlog, when they suggest how to handle a problem they’re facing as a team, when they make eye contact with everyone during their update and not just with the team lead — team growth is taking place.

Retrospectives

The sprint retrospective occurs at the end of the sprint and is focused on learning from how the team performed during the sprint. While there are many ways to conduct this meeting (google it), my first tip for the retrospective is this: do it!

Some teams focus on the more straightforward meetings — the sprint planning and daily standups — and leave the retrospective out of their process. Don’t be that team. This is where we can look ourselves in the eye, and ask what went well and what could have gone better. This is exactly where the team can grow! And it’s even more true for a new team. If the team was just recently formed, don’t wait for it to be more “mature” before you introduce this meeting into your process. Having a place to examine how you worked together and what you could do better next sprint is a great tool for your team to get better faster.

Run the meeting with a learning and improvement state of mind. Discuss interesting positive/negative incidents that took place. You know how they say catching an exception is a good thing because you now know there’s a problem? Well, discussing a negative experience is a good thing for the same reason. You realize there’s a problem and you talk about how to improve for next time. What did we do well? What could we have done better? How can we become a smarter, more productive, more effective team when the meeting ends and we leave the room?

Look at what you thought you’ll get done at the beginning of the sprint. Were we close to our estimations? What can we learn about our pace? If we achieved much less than we expected, was it just bad estimation or did something hold us back? If we accomplished much more, what can we keep doing to maintain that momentum in the coming sprint/month/year? We were the ones that set the sprint scope, and we were the ones looking at the board every day trying to adjust according to our progress. So we are the ones accountable and it’s up to us to check how we did

Getting everyone involved, not just the already very engaged team members, is crucial for effective group learning.

Here’s what you can do:

• Create an open and positive atmosphere and encourage people to talk.
• Experiment with different formats and find the one that captures everyone’s attention.
• Let someone that is not the team lead or product owner lead the meeting. If there’s a Scrum master that’s great, otherwise anyone with some passion for it will be great.

What’s in it for you?

Apply the above and you’ll start seeing a couple of things:

• Team commitment and accountability for the sprint backlog. This leads to a bunch of great things. It pushes you as a team to finish by the end of the sprint. It encourages the team to proactively organize itself during the sprint. It sets the ground for introspection at the end of every sprint.
• A stronger sense of a team. You discuss tickets together, you adjust together along the spring to finish it successfully, you retrospect together at the end of the sprint. You have more responsibility as a team. It’s not about each team member owning the task they’re currently working on. It’s about collectively owning the product.
• Stronger engineers. First, because they have more responsibility for what’s going on. Second, because they have a place to apply learning at the team level and at the personal level. We create a culture of ongoing improvement. Third, because they’re expected to identify product needs from an engineering standpoint and learn more about them.

By applying these small changes to recurring meetings you can achieve the above and help your engineering teams grow. This will help the team deliver more complex features with higher quality and in less time. Try it out, let me know how it goes!

If you liked this post click the ♡ bellow. As a writer it means the world.

If you want Medium to tell you about new posts click the Follow button.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!