 Hi there, I'm Jeff Watts and welcome to a new playlist on my YouTube channel called Agile Interview Questions. I get a lot of messages from people asking me about what they might get asked in an Agile interview or they've been asked a difficult question and weren't quite sure what they should have answered and I even get questions from people asking me what kind of questions they should ask in an interview and what kind of answers to look for. So I thought I'd give it a go and see what I can do to help you with those Agile interview questions. The first thing I want to get out there is that there's no guarantee that the person interviewing you and certainly not the person who wrote the job out there, have an in-depth knowledge of Agile values and principles and the nuances of the role that you might be interviewing for. If you're in the interview and you get the feeling that this person or these people don't really get it, that's a more of a reflection on them than it is on you. And if you end up not getting the job, I would suggest treating that as a lucky escape. So the first question we're going to look at in this opening episode is one I've been getting a few messages about recently and that is what metrics do you use to assess an Agile team? Well, first of all, this is a tricky one because actually I'm personally not that interested in assessing a team. I'm more interested in whether a team can and wants to assess itself. And secondly, a lot of the aspects of what makes a team a team and makes a team Agile are very easy to measure. Now, there's a famous Einstein quote which says, Not everything that can be counted counts and not everything that counts can be counted. Now, while you may struggle to get that rationale passed an accountant, there is a lot of truth to it. And I think that's true not just from an Agile perspective and a team perspective but in life. Now think, is it easy to measure love? Is it easy to measure happiness? Is it easy to measure friendship? But you know they're all important and you know it when you see it and when you feel it, right? Well, it's quite similar in an Agile context as well. Just because something isn't easy to measure doesn't mean that we should not try and move towards it. We can still try and get more of something or less of something even if it's difficult to actually quantify. So for example, love may be difficult to measure, but hugs might be a decent proxy measure for love. The more hugs we have, the more love we feel, perhaps. So we'll be able to find proxy measures that can help guide us in the direction that we want to go. And you've got to be careful, obviously, because every metric is going to change behaviour and there's a good chance that it will be gained. For example, I used to work at an organisation that took the logical view that retrospectives are Agile. Agile is good, therefore retrospectives are good. The more retrospectives we have, the more Agile we are and the better we are. Now, you can probably see the floor in that already. So we ended up seeing teams have multiple retrospectives per sprint just to hit that metric. And while retrospectives are a good thing, by overdoing it and doing it for the metric's sake, actually saw the reverse. We saw less creativity. We saw less engagement. We saw less improvement. We saw lower morale. And the value from the actual practice went down. Now if we look into this deeper, we can realise that it's not actually the practice of retrospectives that we want. But rather the continuous improvement that that practice can give us. So we're looking for metrics that will help encourage the behaviour rather than institutionalise and encourage a specific practice per se. So what are we looking for? Well, when it comes to the successful Agile teams that I've seen, they tend to have a few common characteristics. The first one is self-improvement. So you see more and more examples of teams getting better by making and taking opportunities to improve. For these teams, staying good enough doesn't seem to be good enough for them. They just want to continuously improve and get better. And they take pride in that. They don't also need to be told to get better either. And they probably won't even wait to the retrospective to find opportunities and put those opportunities into practice. But they'll improve whenever they see an opportunity to. The second thing I tend to notice in great Agile teams is quality. So great Agile teams take quality seriously. They take pride in their work in doing things right and doing it well. Not talking about over-delivering and gold plating here. They do try and minimise waste and over-delivery and focus on the simplest thing that will work. But they do make sure that it does work. One of the Agile principles which happens to be my favourite from the Agile manifesto is continuous attention to technical excellence and good design enhances agility. And this principle really resonates well with great Agile teams. As well as delivering well, they're always taking opportunities to tweak things and make things better and leave things in a better state than they found them in. Those are hallmarks of a great Agile team. The third thing we tend to see in great Agile teams is unity. What I mean by unity is sticking together great Agile teams generally put the team first over the individuals. I don't mean that we don't care about individual development. We do. It's just that the needs of the team will trump the interests of the individual team members when it comes to it. The individual members of a great Agile team don't tend to see that putting the team first as a sacrifice either because it's something that they gladly do, mainly because they see the benefits of being part of a great team. It's something that they enjoy and it's something valuable to them as an individual. And they know that they can expect the same behaviors from their teammates. So look out for some stories where people go outside of their job description or they're swarming or they're taking collective responsibility for things. They're good examples of unity. Another thing I've noticed about great Agile teams is that they're brave and audacious. They take risks. They put themselves out there. Both as individuals and as a team as a whole. And they enjoy pushing themselves. They seek responsibility. They seek autonomy. And they don't really see it as a risk like some people would because they know they've got each other's backs. They know they've got support for when things get tough. And they've also got many examples of success as a team as a sort of backup to draw on. Now, this doesn't mean that they're easily persuaded to take on impossible tasks and burn the midnight oil in order to get them done because they know that would be to the detriment of their physical well-being, mental well-being and the product itself. And it doesn't mean that they value individual heroes either. Instead, these teams, they look at a situation and they see the possibilities rather than the blockers. They assume that it is possible and success is an option. They say, let's give it a go rather than, oh, I don't know. They challenge the status quo and they also challenge their own assumptions. Finally, despite all of those other factors that I've just talked about, great agile teams don't forget about delivering. At the end of the day, they know they're here because they have a job and they need to deliver stuff. They need to work hard and deliver value. And they enjoy delivering value. They enjoy satisfying and, well, really delighting their customers and their product owners and their users. Great agile teams find a way to get stuff done rather than just say, well, I've done my bit or I'm making progress. But bear in mind, it's not about story points or velocity or efficiency or utilization. It's whether our customers are happier. Is our net promoter score going up? Are we becoming more predictable in our delivery? Are there fewer last-minute panics? Agile teams take pride in their deliveries being boring. That might sound strange, but they don't create dramas. And when we factor in their previous focus on quality, we know they're not just delivering shoddy work just to get stuff out of the door to meet a delivery quota. They're delivering good stuff too. Now, if you've been paying attention, and I'm sure you have, you will have noticed that these traits that I've been talking about here have formed an acronym because great teams have squad depth. And I want to come back to something I said near the beginning, which is me assessing a team is never anywhere near as good as a team assessing itself. And great teams want to be great. They want to become greater. They want to stay great. So helping them define what greatness means for them and then giving that team the tools, the environment, the support, the space and the psychological safety to be able to inspect and adapt themselves is the number one thing that we really want to be looking for and looking to create as any kind of leader within an agile organization. I hope you liked this video. If you did, then I've got some metrics that I use to determine my value delivery, whether I'm doing well. And some of them you can help me with. So if you liked it, give it a thumbs up. That's one metric I use to determine which playlist to focus on in the future. You can give some comments. You can subscribe. These are the metrics that I use to determine whether these videos are adding value to you. If you've got another interview question that you'd like me to tackle in a future video, then let me know. Leave a comment and I'll try and cover it. Don't forget to subscribe and click that little bell next to subscribe because then you'll be notified when a new video comes out. You won't have to keep checking. And if you've got an interview coming up, good luck.