This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - Showcase talent through IT project evaluation and management: Read more in this section
- IT project management best practices show off IT talent in Miami Beach
- PPM process tips from CIO Niel Nickolaisen
- Do Agile projects spell trouble for project managers?
Explore other sections in this guide:
- 2. - Project evaluation: Let's go to the videotape
- 3. - Keeping your projects on course
- 4. - Project evaluation: Some terms to know
In this podcast transcript excerpt, agile project expert Joseph Flahiff clears up some of the confusion between the product development lifecycle and the project management cycle, and explains why some product development practices conflict with agile project management. Listen to the full podcast to learn about must-have agile project management controls, and why it might be a necessary evil to use a Gantt chart as part of an agile project.
Download for later:
- Internet Explorer: Right Click > Save Target As
- Firefox: Right Click > Save Link As
SearchCIO.com: I've heard you speak about enterprise project managers feeling like they're
trying to fit a square peg into a round hole when starting an agile project. What are the problems
that they're encountering?
Joseph Flahiff: What people run into is fundamental to the difference between running an agile project in an enterprise versus running it in a software company. Agile was developed by software developers for running software product development in software companies. The principles are great, and they found a lot of success using these principles and approaches. So, people said, "Hey, well let's apply it in our enterprise; it makes sense in smaller companies, so let's use it in bigger companies."
I'm not saying that software companies are all small that use it, but it's a different animal. So, they try and apply it in an enterprise organization and they run into roadblocks. The roadblocks they run into when they put it into an enterprise organization are that software is not the driving product of your company. In any agile approach, you talk about having lots of contact with the software product owner. That's a full-time job that somebody in a software company has; that's the title on their desk.
In an enterprise organization, [product owner] is a role, not a job title typically; and it's a role that we know that we need in an agile project because we've been told that we won't be successful with agile projects unless we have this highly involved product owner. So, we find someone who has a full-time job and put this label on them: "You're the product owner now." So, in addition to doing this job, they're supposed to do this other full-time job; and it's not a surprise that there's a problem doing that. They don't have the time to commit to an agile project that a product owner would have running an agile project.
Have you found a way to work around that? Are companies more willing to dedicate someone to
Flahiff: It is still a problem, and no, they are typically not dedicating a person to it. What I found that worked well is [first], be aware of the problem. If you're not aware of this as a problem, you'll just bang your head against the wall: "Well, my product owner isn't involved enough." Well, they're never going to be involved enough, so don't expect it. Then take an approach of "OK, that solution doesn't work in this context."
What's the goal? The goal that you're striving for is to have someone who can represent the customer heavily involved in your project. So, maybe that's not a product owner but a couple of people. Agile purists are going to tell me that I'm sinning when I say that, but I live on this planet, in the real world; and in the real world, that's what you run into. Again, if you're aware of it as a problem, then you can look at it as, what is the purpose of this role and what are we trying to accomplish; and find creative ways, like having a group of people represent the customer instead of just one person.
Is that the main problem you encounter, or is there another key one?
Flahiff: Another key one is that agile is developed as a product management approach, not a project management approach. And there are some fundamental differences between those two. A project is a particular piece of work, and the Project Management Institute Inc. has a specific definition that says, "A project is a temporary endeavor undertaken to create a unique product, service or result. It has a defined beginning and a defined end."
If you're doing product management, you don't have basically any of that. It's not a temporary endeavor; it's an ongoing endeavor. It may have a defined beginning, but it does not necessarily have a defined end. It may come to an end, but it's not part of a definition of product management. Product management is, "Hey, we have this product -- a piece of software -- and we want to develop it to create a customer base, or serve a customer base, and we know [user] needs are going to change over time, so we are going to be continually growing and adding and changing this product by continually growing and adding and changing the features of it."
So, again back to that product owner: In a traditional project, part of the role of the project manager is to control [project scope]. You've heard people talk about how in agile projects we don't try to control scope -- and we don't. We look at scope as something that changes and moves, but if you're trying to approach [the project as one with] a defined beginning and a defined end, then you will be looking to control scope. And when that product owner adds features, you'll think that they're doing something wrong. But if you look at their role as a product owner of a product development lifecycle, then it is their job to come up with new features. If they are not coming up with new features, they're not doing their job! So, we really want them to be coming up with new features, and that's why agile has this whole product backlog that we use. Adding features is very well defined, and it's an easy process in agile because we want it. So another key thing that people run into is, this is a product development management lifecycle, not a project management cycle.
Now, that said, a product likely has a lifecycle with projects. You're going to have releases, and each of those releases can be viewed as a project where you have a defined beginning and a defined end. But, you need to look at it as a project that is working within the context of a product. If you take that lens and can view your project as part of a larger effort to maintain and deliver a product, then you'll be able to implement agile a lot easier because you'll have a broader view of what your responsibility is to the company. It's not just a limited view to the project, but you're here to help the company deliver a large product to an internal customer in enterprise organizations.
Joseph Flahiff is president and CEO at Whitewater Projects Inc., a firm that provides agile project training and consulting services to enterprise organizations. To learn more about agile project controls, register to listen to his "Agile Project Controls for Project Managers" webinar.
Let us know what you think about the story; email Christina Torode, News Director.
Subscribe | Contact us | Follow SearchCIO.com on Twitter