I'd like to introduce my colleague Yael Grushka-Cockayne, Assistant Professor of Business Administration here at Darden, and one of Yael's specialties is Project Management. So we're going to talk a little bit about the larger scope of project management and how that relates to agile. So, Yael, project management. Thanks for joining us. Project management has been around a long time as a formal discipline. What do you think are some of the biggest differences that someone who's been trained in those more traditional approaches is going to notice when they work on a project with Agile? >> Yeah, thanks again for inviting me. That's a great question to start us off. I think that the approach is almost flipped on its heads. In traditional no project management, there's a lot of emphasis on identifying the scope up front. There are tools and techniques. [INAUDIBLE] work, great job structure or visualizing it. Finding out the critical path, really to nail down the scope to remove any ambiguity and any scope creep down the road. And then our main emphasis, while the project is actually being executed, is on the timeline and the cost. In the Agile framework in developing software in today's world and following your guidelines, it's really allowing and opening the door for that ambiguity in the scope. We no longer fear that scope creeper. We no longer fear, or try to nail it down exactly, but we're really trying to progress and allow the work itself and the client and the feedback that we get adapt the way we progress. So I think that that's really one of the biggest differences. And that means working with teams differently. Allowing teams to inspect and adapt, listen to them and be more flexible as opposed to have a clear path from start to end. >> Beyond the kind of obvious playbooks stuff that they would have learned. What habits do you think they most need to watch out for, if they've been trained and are used to working in these more traditional environments? >> Well, I think that there's a tendency in the more traditional environments to distance yourself. To start with a plan, to identify the requirements and the specs, and then to kind of take a step back and work in isolation and come back after a long amount of time or a long period of time. I think that, that is something that they need to watch out for, to open up. To be very close to the client, to be close to the team, and to allow for full transparency along the way. It's really a different mindset, because you're looking for input as opposed to moving away and sheltering yourself and trying to complete your work behind closed doors. You're opening your entire progress of your, you're showing your code maybe, or your functionality that you've developed. And you're looking for reactions to that. So really this notion of, where does the work get done? And how does it get done? And just allowing for more transparency, I think that's going to be a real sometimes a real hard transition. Another one is just working within a team that has many different skills and that is going to come up with ideas and suggestions for deviations and changes along the way. Our project managers are not necessarily always ready for that. And they're not always looking for that type of input. They're really hoping to hear, I've completed my task. What's next? And not necessarily hearing for suggestions for something new, or new path forward. And so they really need to listen to their team and to their clients in a different way. >> And given that, I would say, you have your Silicon Valley companies, your present company's using Agile. This is generally accepted the idea that it, for most types of software, probably, works better, why do you think that these traditional project management techniques are still so prevalent in digital and software creation? >> Well, I think that if you go back, the reason that they started off the way that they have and the way that they didn't immediately start with where we are now with Agile, the software has been an evolving field. Programming has been evolving. 20, 30 years ago not everybody in their organization felt so comfortable looking at code and talking about code and developing these types of functionalities. And so there were really fewer programmers, they were scattered around organizations, the resources were more of a scarce resource. And so they had to work and utilize that resource differently. Companies had to plan the development in a different way. Now we have different organizations that can allow their teams to be physically in one place and work together on a single project over a long amount of time and then move on to the next project together. That has not always been the case and organizations are slowly moving in that direction. But really to get to a place where the infrastructure allows for a more of an Agile approach, takes time. And so the traditional project management techniques were developed on the idea that we may have a resource join our project but then go off and work on a completely different project because they have a unique skill set but only they can provide a certain piece of work. And so as organizations are restructuring their teams and restructuring their capabilities, we're seeing the methods support that and move towards your Agile philosophy. >> It's certainly not mine but I'm a big fan. You mentioned about the people coming in and exiting teams. What do you think are the material differences, if any, between how traditional project management would suggest you compose and maintain your teams versus Agile? >> Well, I think that in the Agile environment, the teams are as a single unit. Okay? Self-organizing teams in the Agile framework. They're self-organizing, they're multidisciplinary, they have more of a capability to move from one task to the other to help each other out, and to complete functionality in certain interrations. In traditional project management, the is the entire project. So, there is less of a need for the team to be able to complete quickly and swiftly a piece of work, but for an individual resource they can spend their allotted amount of time. Complete their task that they were assigned to. And they are likely to move on to a different project while that task that they completed moves down the chain. And so there's a little bit more, a fluid flow of resources in and out of the project in a traditional project management environment, which adds some complexity of its own. That means that organizations are often matrix types of organizations, where resources are allocated only temporarily for projects. And so they really rely on due dates, and they rely on this idea that once their involvement in their task is done, they move on. In the Agile environment and in the way the software development gets developed in that setting, it's different. You work as a team and you stay with your team, and you move on together with the learning and with your conclusions from the retrospective. You move on the next phase, if it's the next friend or if it's the next situation or if it's even the next release. But you stay as a cohesive team. Which provides for opportunities for growth and improvement. >> I'm a traditional project manager, I come into an Agile project. What do you think are going to be the rewards? What do you think they might notice that they do like about it and they're finding useful as they initially get started? >> Well, I think there is a lot a lot that they are going to get excited about and probably the biggest one is that the quicker feedback, the quicker success and a quicker feedback. I've worked with many larger organizations perhaps more traditional industries like construction and banking. And you often hear that new employees come on board, they're full of enthusiasm. They start working on a project and two years later they haven't seen a project to completion. And they get frustrated, they've not seen a product produced or released and they haven't heard any customer feedback or gotten any good signals that what they worked on so hard is worthwhile. And so, by changing their mindset and working with the set of tools and the techniques that Agile encourages, I think that they'll see much quicker feedback and much quicker success. Quick wins, I think were today's generation is looking for much quicker satisfaction and quicker wins and they will get that with the Agile framework.
