I'm here with my colleague, Professor. Thanks again for joining me Yael. >> Hey, Alex. Thanks for inviting me. >> What do you think are the characteristics of a project manager, who's going to be successful with? >> Well I think a project manager has to be aware of the tension around different parts of >> Of the organization that come with the Agile Framework. There could be less tension or more tension depending on the setting but I think the project manager has to recognize why different parts of the organization are asking for different information. Some individuals or some departments may need a deadline. They my need a due date or a completion date, or they may need some cost estimates. Those are sometimes hard to derive and come up with in the agile framework. Maybe I'm just adding why they're looking for that information or helping them get some knowledge of the plan would be helpful. Project managers are typically expected to know things like time, budget, scope. And when they don't have that input. They don't have that from the team, or they can't necessarily commit. That makes an organization feel a little bit uncomfortable. And so, the project manager has to realize why individuals are asking for information, and try and satisfy that. And what do I mean by that? Typically, I like to say that there's always going to be an area where you can compromise on. If somebody's asking you for the timeline, when the product's going to finish, try and understand why they need that information. Are they constrained by anything? Are they limited in their time or can they actually compromise it, but they're just not thinking about the tradeoffs? And so, project manager has to do that translation, it has to help the rest of the organization Understand what the development they're trying to do. And kind of shelter the development from questions that are not necessarily helpful, that they cannot necessarily answer. >> What about working in these small, relatively self contained batches, this kind of lean aspect of pairing with Agile. Is that hard for someone with a traditional project management background to sell? >> I think it is initially, although there's a few things that you have to think about. First, it's not uncommon, or that it's not that we can't point to other organizations that have been doing something similar for awhile. Agile has been, or lean I should say, has been common in the industry. Pharmaceutical companies utilize flexibility in a different way. And so selling this idea that we work, we make some progress, and reevaluate can be a mirror to what's going on in pharmaceuticals. This idea that we can bail out at some point, or this idea that we will Adapt our plan to the information that we learn, is acceptable out there. And so they just need to point to other industries and examples in which this gets used and utilized and capitalized on, to add more value to the company. Another distinction that I think is helpful for a project manager is this notion of process versus project. A traditional project management thinks about projects as a unique set of activities that has a start and a finish. The more and more we move into an agile framework with self-organizing constant fix teams that work on constant continuous delivery and small iterations, we're moving towards a world of process. and the measures are a process measures and the way that we think about things has to be done like we consider a process. Like we consider manufacturing cars in a manufacturing plant. It's an ongoing, continuous process. If a project manager understands that that's how a software team is going to be working, they can move away from some of the more traditional Project lingo into process lingo, and then support the organization and understanding how it's going, and how it's progressing. >> What do you think is advisable versus not advisable, productive versus not productive. In thinking about Agile, as a product management methodology versus something else. >> Well, again I think that it's this notion that we can get the feedback and that the product and that the process will ultimately lead to the superior customer interaction. So, I think it's productive to recognize, that that's. One of the key motivations here. Whether or not we're thinking about a critical path or whether or not we're thinking about small iterations or sprint like work, we really want to develop something that's useful and is used by the end client and that is then going to lead the company to be successful. And so it's productive to keep that On the top of your mind. I'm sure that you've talked about the manifesto and the Agile principles that inspired the movement or inspired much of the practices out there. And I think that keeping that in mind and constantly reflecting on the motivation is very helpful here. Sometimes we lose track. We're so busy. Fixated on trying to finish a project and complete it on time, for some reason, or within budget. And again, those may not necessarily be the goals. But we just get sidetracked and lost. And so we need to go back to the fundamentals. and remember the motivation with working in this new approach. >> In terms of fundamentals, what do you think are the other challenges for a modern organization or firm that is trying to approach that's trying to approach innovation in a systematic way? Well Agile is definitely inspiring. The enthusiasm and the happiness of teams and the happiness of clients is definitely noted and so although the organization's more traditional construction or banking industries are Have a desire to move in that direction. It's not always easy to see how some of these principles can move or translate across industries so I think one of the challenges is how do you take some of the principles or how do you take some of the inspiration and And apply it to your domain. One area that I think or one industry that I think can really capitalize on this and I'm seeing some signs is for instances services. Consultants and lawyers, and some organizations that have more of a service orientation. Can't actually start thinking more in the mindset of Agile and working with smaller iterations, quicker iterations and with more in close proximity to the client to get feedback sooner And so I see that they are starting to adapt some new practices. But in general When you work with hardware or if you're working with the physical world, it could be sometimes hard to apply some of the concepts that AJOL is trying to encourage.
