 I'm Dr. Rishina Hoda from the University of Auckland in New Zealand, and today I'm gonna be talking about some research to do with agile, specifically to do with the journey of becoming agile and how that might be different from simply doing agile. And that kind of fits in really well with the agile mindset idea, which we've been hearing about throughout the day. So hopefully you'll get some good insights out of this and there's also an interactive component towards the end of the session, so stick around. Okay, so before I get into the talk, there's something I need to get, sort of something I need to acknowledge, which is what's happened in Christchurch just a couple of hours before I took my flight out to agile India. I'm not gonna be able to say a lot about this without getting emotional, so I'm gonna stick to the basics, we all know what has happened, but I would like to focus on the positives that have come out of this, which is the huge support, the love and the generosity of the people around us in New Zealand as someone who is there and can feel it in the true sense. I can tell you it's been amazing. So one of the things I will point out is the fact that the Victim Support Official page for charities has raked up in excess of six million New Zealand dollars, and to give you some perspective, there are only nearly five million people in New Zealand. So that's pretty amazing. Our Prime Minister, Jacinda Ardern, has been an amazing role model at this time, standing up for us, not sort of, you know, beating about the bush, actually just taking stands and being really clear and calling people out and calling the act out for what it was. So I would just like all of us to maybe just take a moment of silence in respect for people who have lost their lives in this absolutely horrendous strategy. Sorry, and then we'll get on with the talk. You can keep sitting if you want to. Thank you very much. All right, so this is New Zealand and I love it. I mean, this is gorgeous. Look at it. Why wouldn't you want to be here? So this is the glowworms. This is how we do our rugby, although I'm more of a cricket person being originally from India. You can kind of understand where that's coming from. This is Hobbiton, which for people, how many Hobbit fans in here? Yay, so there's the set. The original set is still intact. You can go there and visit it and look around. Spoiler alert, you can't actually go inside the halls. Those are fake, but nonetheless, it's an awesome experience. This is the University of Auckland. In Auckland, this here is our clock tower and you will see how beautifully the two architectures, the old and the new meet in our university. This here is our engineering faculty and we've got a brand new engineering building coming up which should be finished in time for next year. Cool, so what's the connection between me and Agile? So if you notice, my Twitter handle is Agile Raschina right from back in the day, 2008 or whenever I signed up. So I go back, me and Agile go back a long way. I did kind of my PhD on the topic, specifically looking at the self-organizing team aspects and I've been studying and researching the human and social aspects of Agile for a really long time. Most recently, I now have two students who have graduated with their PhDs on Agile topics, one around Agile retrospectives and the other one around the role of the Agile manager and I've got two more currently at the moment who are looking at other Agile topics. So in this, all of this time, I've published over 60 research publications on the topic and I'll be talking briefly about how you can access them. And of course, I teach Agile, so I introduced the Agile course at the University of Brooklyn, that's been running in collaboration with the local industry for some time now, really well. Okay, so I thought I'll start off by asking on behalf of you to myself a few questions that people are always thinking about but never quite sure to ask the researcher. So here are some questions. How much do you earn for each research paper? You were thinking it, you were thinking it. Okay, here's the answer. Nothing, zero, zilch. It's ridiculously awesome because we do it as part of our job. And then the next question you might ask is, well then how come it costs me to access your research? And the answer is publishers, period. I'm not gonna say more about that, okay. The entire community of doing research, peer reviewing research, publishing research and getting it out there is voluntary and free and that's what we do as researchers and the access part is controlled by the publishers. Now, that's not all bad news. So if you want to access my research for free or other people's research for free, you can do so. So for example, what I do is I put all my publications up on my website and it's free to download, okay. And a lot of other researchers are increasingly doing this. So if you don't feel like you can't access it or it's too pricey, you can always try and go to their own individual websites and see if it's available for free. Now you might be wondering how and what am I doing this if publishers are supposed to be charging you money for that? And the answer is there's something called open access which is very similar to open source but for research. So you're trying to make science and research open and accessible as possible. And also the fact that we can share pre-prints of our paper which means it's the same content but it's not fancy, it's not been put into the publisher's sort of format. So if you're trying to read it in a draft version that's what we do, we just, it's the same content, right? So that's all available and this is not just me as I said this is most researchers out there so do feel free to sort of tinker with their websites and try find stuff. All right, so today's talk is based on a paper that I wrote in collaboration with Professor James Noble from the, from Victoria University of Wellington. And we wrote about the theory of becoming agile which was presented at the International Conference on Software Engineering 2017 in Buenos Aires and it also did receive one of the six distinguished paper awards at that conference and for me it was personally really, really awesome because it was, I've seen the whole journey to putting in my first paper about agile, getting reviews around what is this fluffy stuff to going all the way 10 years down the line and receiving distinguished paper award on the same sort of topic which is a full circle for the research community as well which is quite nice. All right, so I'm not gonna go into the details of the research method, this is not the audience and I do recognize that but I'll briefly share that it's called grounded theory and the reason it's called grounded theory is that it's an empirical method that's focused on practitioners and the industry. So we're really interested in looking at how things happen in the real world, not sit in some lab in a university and think up stuff. So we actually go into the industry, talk to people, observe the practices and that's why it's grounded from the bottom up based on how you do it, right? And it's a theory, theory is not, it's not your E is equal to MC squared kind of theory but it's a theory in terms of these are the findings that we finally come up, these are the common patterns that we find when we talk to a number of people across different domains and also a set of hypotheses which you will see in a minute. So this is my favorite slide because this is my state of mind before and after I finish a project. So when I start a project I have a whole bunch of questions, right? And it's a clean slate of, gosh, how does this work? So some of the questions driving what I'm about to present today were these. So how is it that teams do become agile? What's that journey like? So it's a really broad question. The other one was, how come some teams are more agile than others? What's up with that? Like, my agile is more agile than your agile. Like what's going on there? And then there's also the fact of is it just about the software development practices but it doesn't seem like it's just about the software development practices. What's going on? What are the different aspects that change in this transition? So that's kind of where it started. And of course what you do is as a researcher you look at what other people have done before so you're kind of not reinventing the wheel and in that what I did was I found that mostly the current understanding around agile adoption has been that it's a one-off sort of process or a one-off event even in some cases where you're going through a step-wise approach to becoming agile. Step one, do this, step two, do that, step three, do this and boom, right? So a lot of the research-based models were focused on getting to agility or to becoming agile by step perspective. And then also the fact that most of these models focused on either really the high level abstract value so they're talking about things like speed, flexibility, adaptability and you're not quite sure what that really, how can you quantify that or even understand that or the really low level development practices like, all right, let's start with prior programming or let's try TDD and other stuff. But as an individual we're starting on this journey. That's a mammoth gap to try and reconcile between the high level values and the low level practices like what's even going on? So this here is the theory of becoming agile. Just notice the colors look a bit weird so we'll see what the other slides look like in a bit. But this is the overall theory of becoming agile in a model, a picture or a diagram fashion. And we've got five dimensions that I found teams transition through, okay? So these are software development practices. That's a no brainer. This is one of the first things that happens. There's also team practices, the management approach, reflective practices and culture. So we're gonna break that down very quickly. So I'm gonna get straight to it. And oh, by the way, the edges that you see, those are the hypotheses and we'll get to that soon enough. All right, so what do I mean by software development practices? This was a little bit tricky to disentangle from the team practices, but I've given it a shot. So here I'm sort of looking at the delivery model, whether it's sequential or whether it's iterative and incremental, things like what do your meetings look like? Are they still kind of the status reporting kind of meetings? Are they really your deep level daily standup like Shane mentioned before? And artifacts, are you using things like the Gantt charts or quite heavy weight documentation versus lightweight scrum boards and things? So very basic agile stuff. Now what I found was that different teams or different individuals were at different levels when it came to this transition. So if you were like for the teams that were really just starting off, a lot of these software development practices were very traditional. So what I'm gonna do is I'm going to bring in some of the quotes from the actual practitioners so you get a sense of what is it that I've been hearing as a researcher. And P numbers, it was a P25 or P36 is just anonymizing for confidentiality reasons. This is why people tell me all they tell me because I don't name them, right? So here's an acknowledgement of a tech lead in India and they said transitions happen slowly. Initially you don't understand what's all this sprint planning demo thingy and then soon enough slowly you get into the pattern and you start practicing those things. So in the beginning it's very much traditional software development. You don't just turn agile overnight. The next one what I saw was teams that can be said to be in a hybrid state. So they're kind of getting there but not really there yet. And some of the things to highlight in that case is people are resistant to changes. So when it's new it's exciting but when you have to kinda do it every day then it's like what did I sign up for? So some of the things you might start questioning again. And it does take time and it takes a while to get into the pattern and really absorb those practices. And finally when teams have embedded the basics of agile software development practices and that's when I'm saying they are further along on that maturity of the software development practices dimension and this is where you have a consistent use of the practices and you're actually deriving value from the use of that practices. So you've really embedded that into your culture and organization. So that one actually is one of the most intuitive dimensions we all kinda expect that. The other one was team practices and this is almost some of the teams Wednesday start transitioning into agile. They're like not sure I bargained for this but okay. So these include things like project management, activities like requirements, specification, estimation, clarification. Remember as traditional teams most of the time this was done by the BAs, the managers, that's right. And now suddenly the team is like whoa, we can do this. That's pretty cool, right? So that's what we found in this case. That's not me, I swear. And the other aspect is task management which is delegation versus self assignment. In fact in some ways this was a hallmark feature of self organizing team with their ability to self organize. So if the team was quite new to transitioning on the team practices dimension then they were largely manager driven, all right? So the manager is still doing most of the requirements specification for them or the facilitation or being the face of the team to the customer and definitely delegate still delegating tasks. So on this dimension you're still manager driven as a team, right? The next one was manager assisted. So you've moved on from being manager driven now you're kind of either looking to your manager for help or your manager is offering you help actively and hand holding a little bit to help you to get to the next point which is becoming more and more autonomous as you move on on the team practices dimension. So here's a development India saying oh we do get assistance from our scrum master to assign the task in the future we will be doing this ourselves. So there's a self awareness we're not there yet but that's the goal where we finally wanna be. And then finally for teams and these were rare to be honest and it because it takes time these are more mature teams that were further along on the team practices dimension and this is where you have a scrum master in New Zealand for example saying our teams are exclusively self assigning. They just work on their own in terms of the tasks but also senior development India saying we allow direct contact to the customers. So that you are free to talk to your customer you don't have to go through your scrum master you don't have to go through your BA to be able to do that. So that's the team practices dimension. I hope you see how it's different from the software development practices dimension. Another one which was really tricky to sort of disentangle was the third one which is management approach. Now I'm gonna say this I think honestly team practices and management approach are two sides of the same coin that's called self organization. You cannot have self organization if both of them are not moving in the same direction. So this is almost focusing on the same kind of things which is the management practices and customer collaboration but from the manager's perspective is the manager ready for it. And when I say manager I mean people like the scrum master your title may be a product owner your title may be a project manager, product manager all of those titles that we carry but typically it's your practical role is to facilitate the team on an everyday basis. So what kind of a manager are you? Now how many people managers in the room? Think about your management style as we're going through this and for others who have or know managers you can think about their management approach. So of course the beginning for teams that were starting to transition towards agile the management approach was of the driving kind. Okay so very traditional. I'm the leader, I'm the saint on the stage kind of thing I'm gonna tell you what to do here's even if it's agile, right? I'm gonna tell you what to do and that's fine that's kind of where you need to start because you can't just shove a bunch of people in a room and say go self organize, right? So that's that hand holding period right at the beginning was kind of important. So you've got somebody here saying all right the manager is the first point of contact between the product owner and the team and that's fine. When you were further along the issue is if you get stuck there you don't wanna be stuck there so the next bit is then adapting. Your management approach becomes adapting which means you have real good sense and feel of the level of autonomy your team is ready to accept and assert, right? So this is where you differentiate between you may be ready to give that autonomy but your team may not be ready to take it yet. So in this sort of hybrid state the managers approach is really one where it's adapting to the needs of the team and individuals within the team that are autonomous to different levels. So if somebody is really happy to run with it and self assign their task you let them do that whereas some people may still need your help and assistance and so you need to sort of be cognizant of their needs and adapt your management style. You can't have one management style for all at all times. So that's what I found with teams that were kind of in the evolving process and that teams that were sort of further along the management style moved to becoming empowering in the true sense and that's because the team also was ready for it. So here's a scrum master in New Zealand saying oh a self organizing team is something that wouldn't notice if I disappear. And it's just running on an autopilot I'm really happy with it. But here's a senior developer in Australia pointing out look actually that does not mean that you don't need no stinking managers kind of approach. That's not true, you still need them and some of the reasons you need them is for things like cutting off interferences from the outside, conflict resolution, sometimes people tend to revert to old ways of working all of that needs to be sorted out and facilitated. But so that's the sort of pinnacle of the management approach dimension is when your manager's approach has moved on to becoming empowering. Next one was reflective practices and we just had a lovely session just before on retrospectives as a by Mia, seeing at the back there. Talking about retrospectives as a way of reflection. So one of the interesting things I saw on this dimension and the reason that it's been put aside as a dimension on its own is that this was the hardest one to get right in some ways, okay? It was the hardest one to do in the true sense not just lip service, okay? So for newer teams that were new to the concept of reflective practice, their reflective practice was really limited. So you'll see it from this quote here. They say, all right, we might figure out how the whole team lacks a particular knowledge area. So we have got training session but the problem is time consumption. Okay, so you can see the attitude towards reflection there is you recognize you need the time for learning and reflection but it's still seen as time away from the main stuff which is implementation, right? It's stuff that is taking your time out. It can't possibly be good if it's too long, right? So the approach is not very mature yet. So that's the limited approach to a reflective practice. Next was a focused approach. So if you were further on that dimension you're kind of focusing on one process or practice at a time and starting to hone that a little bit. So for example here they're saying, all right, we've decided that we want to introduce planning poker and through their retrospectives they are starting to really track how they're doing with that estimation strategy and if it's working well for them. So it's really focused. It's not a full on reflection practice yet. And for teams that were further along on this dimension it was embedded. It was part of their DNA. This was just normal to be reflecting. It wasn't time taken out of work. It was part of the work, right? And you made time for it and everyone was comfortable with it and you recognize that this was truly important. So and that's supported not just by what the teams feel but on the organizational level by the initiatives from the organization. For instance a developer in India said we've got initiatives from the organization where if someone's learned a new technology or something they can come and teach it to the rest of the organization. So the organization, the company has set up a culture where why it's okay to take time out of implementation and spend time on learning and reflection and that's part of the culture. So that's the extreme sort of end of this particular dimension. Next up, the final one is culture. And as a researcher, this was one of the fuzziest ones to grapple with. It's like what is culture? And the sort of final definition that I came up with and I still need to sort of go into the details over time. I'm sure I'll do that. But for now my operating definition is this. It's the work culture or the operative culture is a combination of the individual's mindset, the team culture and the organizational culture. And the reason I came up with this is because I've seen two teams or multiple teams within the same organization that have different culture and different norms and values. So organizational culture as a whole, you cannot paint every team by that color, right? Every team has their own unique interpretation of that and then you come to the individual. Even within the team, you have individuals who have different set of norms and practices. And so you have an individual mindset that you need to align. So that's sort of this big mushy combination of these three is what I call culture. As I said, I'll need a bit more research to really sort of define that a little bit better, but for now that's the operative definition. The culture for teams that were quite new to Agile was really hierarchical in that you have, this one's really telling you need approval from the managers to follow it up with the product owner who in turn follows it up with the client. So you can start to see the communication channel and the information flow is really, really hierarchical. The next one was evolving. So again, that middle intermediary stage where it's evolving. So the communication hierarchies are being broken down but they're not really there yet. So what does being there yet look like where it's really open? Okay, so people can rock up to junior developers can rock up to the CEO with a new initiative idea and they're actually taken seriously. All right, so that kind of a culture of psychological safety and all of that good stuff where you are really feeling comfortable and able to practice the Agile mindset in a true sense. All right, so from there, derived a few hypotheses and some predictions of how might things go for teams that are starting on their Agile journey. So this, as I said, the software development practices is most of the time for software anyway. I mean, there's Agile beyond software but that's not what I'm talking about today. So within the software realm, the software development practices are the first to start transitioning and that's obvious because that's probably the first reason why you even thought of taking up Agile. Right, that's because you wanted to change how you do your software development. So that's the first one to start the transition. The team practices and management approach, as I said before, there are really two parts of the same coin. Both of them need to move towards self-organization if this is to work. Reflective practices and this is potentially controversial is going to be the last to mature and that's what I can say on the basis of my research because I've seen teams, it's not to say don't do retrospectives, by all means do retrospectives but by the time you can really get full value out of the retrospectives is when your software development practices dimension is further along, your team practices, your management approach is already starting to mature. That's typically when you start to get the real value out of reflection, when all the other ones are further along in your journey. As I said, the culture dimension is a mix of the individual, the team and the organizational culture, not just one or the other and it is indeed the most critical dimension that influences all of the other dimensions and that is to say if you had a agile, conducive culture at your organization, all of your other dimensions are probably gonna move faster and smoother. All of your other transitions will happen quicker and smoother and vice versa. So if it's not conducive, then your team may be wanting to become autonomous and it's not gonna really happen or happen really slowly. So that's one of the most telling and most important influencing factors. Okay, so the main takeaway here, the big sort of difference between becoming agile and doing agile is we're wanting to move away from thinking of agile as a one-off sort of stage progression of practices with whether it's software development practices or those abstract values. That's really what I call doing agile. You're just stuck on one single dimension. You're not looking at the holistic picture. Whereas becoming agile is when you're looking and acknowledging the fact that this is going to be holistic, it's going to be complex and it's going to be ongoing. You cannot really define an end point. All right, as of first of Jan, we're all agile, right? It's a journey, it just keeps going. So that aspect is becoming agile. And an example I'll take here is of child development. So as a mom, I mean we and as parents or as people who have kids in their lives, you know that you often get into issues of comparing two kids of the same age, right? So you've got two five-year-olds or two five-month-olds and oh, mine's walking, mine isn't walking yet or he's talking and he's not talking yet. And that's not the true sort of marker for progress or growth just because they're both five months old. And you can take that to the agile teams and say just because they've both been practicing two teams for five months or one year doesn't mean they're both there exactly. Why? Because we can't just judge them on the basis of their physical growth kids, for example. There's a whole lot of other things going on. There's the social, there's the emotional, there's the cognitive, right? And similarly for agile teams, it's not just the software development practices. Oh, I know pair programming and we're sweet. No, there's all of these other dimensions that they need to transition across. And that's why it's so important to have that holistic picture. This is another view that's really, really light. It can't just, okay, that's meant to be an iceberg. So right at the top, you've got doing agile as just looking at the software development practices, for example. And underneath, you have to use your imagination here because the font's really light. All of the other stuff that also needs to transition if you want to really become agile, not just be doing agile, right? So all of these other dimensions. Cool, so I've got time. I managed to finish the theory part. So in theory, there is no difference between theory and practice, but in practice there is. So we're gonna try and apply this theory of becoming agile. And you have to bear with me. This is the first time I'm gonna be trying this out as in an application of the theory. So if this doesn't work, I'm gonna do what Deb did or recommends around the failure bow to be ready for it. Thank you. Okay, so with being handed out to you, my attempt at trying to make this theory practical, yeah? And while that's going around, I'm quickly gonna walk you through this. This is an exercise I did with a couple of teams that participated in the research. What I did was I used a spider chart or a radar chart to track their progress or their current status across the five dimensions. So you will see you've got five dimensions, the software practices, team practices, management approach, reflective practice and culture dimensions, yeah? And there's blue is team one and green is team two, that's just one example. And you can see these are two teams in the same organization. One of the things I'd like you to notice is that culture is not exactly aligned even though they're in the same organization and their reflective practices are really far apart. So one of them was further along on their reflective practice than the other. So for the moment, what we're gonna do is, I would like you to, I'm sorry if not everyone has it, I was prepared for a smaller group and there was, you know, very graciously, a lot of interest and we've been moved into this bigger room so I apologize if there's not enough printouts. But on the front half, what you will see is the five dimensions, all right? So we're gonna take five minutes and for each of the dimensions that's about a minute and then rank your team, or you could do it individually, but think about your team perhaps, rank your team on how they're doing on that particular dimension at the moment. Now if some people are from the same organization of the team, they might wanna team up and do this together. So for example, the software practices dimension, if you thought that you were really iterative and it was really agile and your team meetings were kind of getting there, not really getting the essence of agile yet, you might give them a five, which is a hybrid, a 10 for where it's on the extreme end of the dimension and a one if it's really still traditional. One left, I've got just this one, but you can have it. No worries. So there's a little bit of maths to be done here. If you're in the far end, which is all 10, under each dimension there are five questions, right? Five aspects. So you can score between a minimum of five to a maximum of 50. Okay, I see people turning their pages. Are most people done with the first half evaluating your teams? Yes? Move on to the next one. Some people still doing, but just give them maybe one minute if you can refrain from the visualized part, that would be awesome. Okay, cool, is visualized. So I've used that, remember that radar spider chart. And what we wanna do is if you've scored on a particular dimension as between five and 15, that's a low. So we can do rough estimates here. You don't have to be exactly accurate. But between 16 and 30 is a medium for that particular dimension. Between 31 and 50 is a high for that particular dimension. So what you can do is you can chart out, say what your software practices look like, team practices, management approach, reflective practices and culture, and then just connect them through the dots. We'll get a picture of something like that. And that will show you which areas you are really doing well in, whereas which areas need a little bit more work on. Do you wanna connect the dots? Awesome. There's one other way to visualize this in terms of the journey of becoming agile. So I'm gonna take the theory diagram we saw earlier, and what you can do is you can sort of color out the areas in terms of percentages of where you are in your journey on that particular dimension. So as an example, if you think you're about intermediate in your software development practices dimension, that's about half of it. Whereas if your team practices are a little under half, then you can shade out a little under half. If your management approach is actually fairing a little bit better than the team practices dimension, you can reflect that. Same for reflective practice, I've shown that as one of the most needing a lot more work and then culture similarly. So you can shade it out for your current standing of your team at this point. Awesome. So as you can tell, this is something you can do again with your team in three months. You can do that again in six months time, a year's time to see how you're tracking on those dimensions. At this point, would anyone like to share their experience of evaluating this and charting out the journeys of their team? And I can tell you from where I'm standing, every radar chart is different, right? And that is why every agile team has a unique experience of becoming agile. It's not just the one step, two step, boom. So do people wanna share their thoughts on this process? One, don't be shy, Shane. So Shane said a useful tool for initiating a conversation with the team. I couldn't agree more. So in fact, a good reminder for me to sort of comment on the fact that metrics, all metrics are really starting point for conversations, right? Any other, yep. Quick and simple, so a really good quick way to assess where you'll pick it up really well. Yeah, so the main thing of doing this is like to ensure for the managers or the leaders to ensure that this is a psychological safe environment. Because if it is always a kind of goal-driven, people will kind of tend to keep always high and which is not willing to reflect the right picture. So it's very important for the managers or the leaders to tell them it's always good to fail here to show the transparency because then you will understand like where you are standing in terms of what this looks like. That's right. So that will give you the right view. That's an absolutely excellent point and it reminds me of a similar comment I got from Scrum Master, I was sharing this with and what they said was for new teams in particular, one of sort of a related concept is they don't know what the whole journey is supposed to look like. So it's difficult for them to tell where they are which means for newer teams it's probably best if your agile coaches are facilitating this because they've seen all a lot of teams go through this process and they can help you a certain way you are right now. And your very critical point about psychological safety because this can easily turn into something around oh, we're the best or worst case within the organization my team is more agile than your team, right? But that's not what we're aiming for. So indeed the culture around that needs to be conducive. Thank you for that. And the last bit, what we're gonna do with this sheets of paper, if you wanna keep it by all means you can keep it but it would be awesome if you can come up to the front I can take pictures of it for my own record or the other way around you can take pictures of it and give me the printouts back. Please don't forget to put your job title on there because it'll give me a sense of how teams or people, team members are perceiving this versus for example managers are perceiving this and how that might need to change. So last bit is would you consider using this as an assessment tool for your team? No and that's fine, yes as it is or yes with these improvements. So welcome your comments on improvements. And as I said as a researcher sometimes it's really comforting to come up with a theory and get an award for it and let it stand there cause it's so beautiful and untouchable. And then to step out of that comfort zone and say well actually it should be helping people so I'm gonna push the limits and try and see if it's actually practical. So that's what I've done here today and I hope that's yeah I really welcome your comments so please do make sure you give me some comments on that.