Mark’s new story for Information Management on project portfolio management best practices in an Agile organization has been published. You can read it here.
Use our blog tag cloud to uncover more info on TechProdo’s discussions, best practices, experiences and more. Here is a direct link to our blogs on Agile . I am still cleaning-up our Forums site after we got bombed from spammers … But I hope to have the Agile Product Manager Manifesto forum back up this weekend.
Thanks & enjoy!
I was having a discussion with a program manager from another company last week about project management techniques and we started discussing what were some of the most difficult and complex projects that we’ve worked on in our careers. My career spans 16 years and I’ve been a PM on projects from large national system deployments to small development projects. I’ve seen waterfall projects, RUP, Agile and everywhere in between.
We both are big advocates of Agile in software development teams and are most definitely converts to the ideas of Agile from all aspects: product management, project management and development management.
But she challenged me with this: I said that the most challenging project that I ever worked on was a 2-year complex project for AT&T that deployed network operations systems across the entire United States, had hundreds of project participants, disconnected and non-collocated teams and no system in place to properly manage and collaborate on project initiatives. Her challenge question was, “Would Agile have worked in this scenario and would it have solved the problems of communication failures, project delays and overruns?”
I initially shouted out: “SURE!” Agile solves all ills … Then I thought to myself, “wait a second …” There would have been no way to coordinate Scrums, organize the teams in a way that they are not used to working, there were no Scrum masters, etc. That may be getting too stuck on the logistics and organizational structure at that time. Perhaps we could have stepped-back and implemented Scrum teams and worked through progressively elaborated lean scheduling.
To me, the bottom-line is this: Agile is proven in smaller teams on smaller-sized projects were not all of the requirements are known up-front, where lengthy analysis and documentation is not required at the outset. For projects that are contractually bound and have high risks of litigation and structured SLAs and SOWs at the outset, Agile may not fit.
What are your thoughts? Have you seen successful implementations of Agile self-forming, self-managing small teams cluster together on large complex projects that are not software development projects? Will this work?
InfoQ has a good recording of a session from the Agile 2009 Conference by Gerard Meszaros that details his experiences in planning and balancing JIT vs. deferred decision making. I am linking to it here and I recommend you take some time to listen to it if you are working in an environment as a PM in an Agile org.
What I wanted to also point out is my slight variation on his “Five Levels of Agile Planning”. Here are Gerard’s: Product vision, product roadmap, release plan, iteration plan, daily plan.
But in my experience, I don’t find daily stand-ups really to be a “plan”. That is much more JIT task-master work. From an Agile PM’s perspective, I would instead focus on these Five Areas of Planning: Portfolio Management, Product Roadmap, Product BRD, product backlog, release backlog. As a PM (program, project or product), your interaction at the release backlog may vary and may not be very deep. In fact, not all organizations following Agile methodologies use relase backlogs. More importantly, note that I included BRD in the list. I feel it is still important for someone in a “strategy” role, perhaps not a product owner, to own, document and detail product strategy in a BRD.
Lastly, I did want to mention that there is much more quality content in his session that you should check out and also that Gerard seems to slide between Scrum & XP throughout the talk.
Written from a project manager’s perspective, this is a presentation by Lois Zells, author, lecturer, and business consultant, specializing in software engineering consulting, that I really enjoyed reading. I came across it from my membership in my local PMI chapter as a resource they made available after she spoke to the audience about what she has perceived as some of the pitfalls of Agile Scrum, XP and other iterative software engineering processes.
If you are invovled in the engineering side of the business and work with or as project management, you may find this a great read. I don’t agree with all of her points of the downside to iterative or Agile. Particularly, my main issue with her take is that it very much is in line with the classic PMP or PMI negative attitude toward the lack of process, change management and documentation from development teams that abide stringently by the Agile Manifesto.
But one of my favorite parts of her presentation, which I linked to above, I have pasted here below to call out in particular because I felt it was funny, spot-on and classic when implementing, developing or planning new technologies:
Lois Zells New Technology Project Lifecycle
by Mark Kromer
I’m not going to spend a lot of time in this blog rehashing the Agile Manifesto, the history of manifestos or the pros and cons of Agile. Plus it’s very late and I’m blogging right now because I feel like an insomniac tonight.
Here are my favorite links for you to dig some more on these topics: Agile Manifesto, manifesto definition, and Saeed’s On Product Management pretty good discussion on this topic.
Those of us that must work in an Agile development environment as product or project managers can debate the merits of the approach (I recommend Cranky PM’s very cranky assessment of Agile from an experienced PM’s perspective) but we also have projects and products to ship. Which means we have this question:
Do we need a product manager’s Agile Manifesto?
To which, I say — YES. Because there is so much orthodoxy around Agile methodologies and because there is so much confusion and lack of consistency in the way that product managers and project managers participate in Agile projects, I say YES.
Let’s also go back to the Agile Manifesto itself. The authors and originators had visions of formalizing the objectives and reasons for “lightweight methods” and worked on coalescing around a set of core values. As product managers, we are in the same position now as those pioneers were then. Many of the leading organizations dedicated to evolving standards and frameworks for PMs (PMI, Pragmatic, etc.) have a stigma attached to them of being too bulky and not agile enough for Agile, so we cannot turn to them.
The principals of the Agile Manifesto are software engineering principals. In my experience, Agile teams over time, become very good at what they do, but are missing upstream elements of product & project management and often times lose sight of the value of PMs. I have tried to stay away from fighting against the innovations and creativitiy from Agile development teams. Besides, I have found that Agile developers tend to love this way of working.
Instead, I have proposed sets of working parameters for “Agile Product Management” internally to the organizations where I work. These parameters are generally slightly different from org to org but have commonalities focused on filling in the open space left from the Agile Manifesto around business alignment, prioritization and some acceptable level of change control. I promise to follow up on this posting with some samples and further discussion here.
Until we devise a set of principals that will guide product managers toward an Agile framework, the gap of filling the proper customer and business alignment along with finding the proper amount of project management and product owner control will continue to be filled haphazardly, by people not well fitted for that role and many times, these needs will be improperly forgotten or de-prioritized.
This is the role of product managers and we need to do a better job as a community of defining the standard role of product & project management in Agile. Because Agile ain’t going’ away, has proven its value and needs more attention to the business with more careful and deliberate analysis of customer requirements.
by Mark Kromer
I stumbled across this story from SearchSoftwareQuality by Colleen Frye about aspects of the Project Management Book of Knowledge (PMBOK) from the Project Management Institute. It is a good read and references another very good article from Forrester called The PMBOK and Agile: Friends or Foes, which I also recommend, if you have access to that material on Forrester’s site.
Anyway, reading this has proded me to continue my series that I started after receiving my PMP certification credential this year. Here is the 1st part of the series … So let’s talk a little bit about other areas of the PMP that I feel bring value to you as a product manager and since I’ve reference the 2 stories above about Agile Product & Project Management specifically, let’s stay on topic and stick with agile for now.
Many people tell me they believe that PMBOK and agile in a software development context offer 2 completely different ways to attack problems of software engineering projects. True. But there are areas of value in learning and applying the PMP style of project management even if your entire team from product managers to project managers to business analysts to developers are knee-deep in agile, scrum, sprints, etc.
Check out the stories I reference above for other good examples. But here are mine:
1. Project initiation. PMBOK does an outstanding job of providing guidance in both projects and the PMI program certs as well, in regards of assessing needs, ROI, cost/benefit and a systematic way of addressing costs & benefits BEFORE engaging on a project. This is an area where I feel that the Agile Manifesto ideas of less documentation and conversation of negotiation should be avoided. You need to make solid long-term business decisions from a pragmatic strategic approach. Not a trial & error approach.
2.Project closure. I spent several months working on a new product project for Primavera Systems in 2008 and their large-project customers gave me wonderful insight into how powerful it can be accumulate, index, store and learn from project lessons and build a knowledge base. PMBOK provides good guidance on how to document and perform these steps. This is best accomplished by an PMP-style project manager and to release the agile developers from this requirement. Besides, they probably won’t want to do this anyway!
3. Continuous improvement. A big part of the PMP exam centered around steps & procedures to create an on-going feedback loop of lessons learned, quality measures and other areas where the macro business process of software engineering in your oranization can be improved. This is best performed by a PMP project manager as opposed to the heads-down agile development teams.
Let us continue on the Agile Product Manager front again briefly today … We agreed earlier in this blog series that in Agile software development shops, the Scrum product owner is often times the product manager. This seems to hold true with product managers that are more engineering-focused or have a background in programming and software development.
But what about a marketing-focused PM? Someone who has an MBA, not an EE and has never been a systems or business analyst and has never worked in a development team before … Is that someone that would fit well in a team that has daily scrums, monthly sprint planning meetings, etc? I think it is very reasonable that a product manager with a marketing/business background would still have the expectation to write, analyze and review requirements. In my mind, that would include reviewing & mapping requirements to backlog item reviews during monthly Sprint Reviews.
But I experienced 2 specific examples both at Microsoft and at Oracle where product managers that had an affinity to product marketing and market analysis, did not work out well in an agile environment. They had worked well in a waterfall or iterative paradigm where there was a firewall between product management and development. But there was too much friction, lack of relationships, lack of patience and culture-clashes for these particular PMs to work in the agile world.
Keep this is mind when assigning product owners in an agile software development team. If you follow a purist vision of agile scrum, then the product owner CAN be a product manager. But that needs to be someone who can embed with the development team.
by Mark Kromer
In keeping with my current themes on agile development practices for product managers, I thought I would take us on a brief foray into portfolio management in an agile software development organization. This is a complex topic and I am working on a complete article which I will public on TechProdo if another publisher does not pick it up. But for this intro blog, let’s see if we can generate some discussion on the topic …
First, let’s start by briefly defining portfolio management in the context of a technology product manager. To me, this would entail having metrics, historic data, trends and current data about your products that give you a holistic view of the entire product portfolio from these primary perspectives: investments, benefits, costs, market performance and margins. There is one other very important aspect to those quantifiable statistics that portfolio management entails, and that is alignment of a product to corporate strategic objectives. In other words, does the product align to what your company goals are currently and into the future? Does the roadmap align to the high-level objectives and is the ROI in line with expectations?
That is a traditional take on portfolio management. Would a product manager in an agile development org operate differently?
First, here is a take on this from the Scrum Alliance, where Jochen Krebs talks about treating a portfolio in an agile way. That is, prioritization and selection processes should look at projects as stories on a backlog. That is an interesting approach that is expanded upon in this presentation from the 2009 Agile Alliance (you may need account to access). Essentially, you perform the same processes such as filling the funnel with great ideas, collect data & metrics, prioritize, perform selection criteria and document.
But my own experience in agile groups is that a product manager’s role managing portfolios changes very little. Go/No-go decisions and cut decisions on any project is still difficult and has consequences in product lines and resource costs. But I find that taking an agile approach to this process with limiting documentation requirements, approvals and market research, short-circuits some of the mechanisms in portfolio management that are intentionally practices to quantify and minimize risk, poor decisions and higher costs later in the build cycle.
If your organization is pushing agile mechanisms throughout the entire product lifeycle, then those references I included above may be of use to you. In my previous blog posts on Agile product management for TechProdo, I do mention areas in which you should adjust to the agile velocity and iteration techniques, particularly on release management and mapping BRDs to backlogs.
But for portfolio management, I have been able to still perform the proper checks & balances at a high level to balance investments, risks, priorities and alignment within an agile development practice.
Continuation of Agile Product Management discussion by Mark Kromer
At its basic, there is a confrontation between classic product management and agile development teams. That is, agile dev teams are formed with these pillars:
If I were to marry those up to a common product management perspective for product development, I would put these 4 classic pillars out there:
I have witnessed varying degrees of success and varying ways in which these teams can align. I’ll start with creating 5 agile product management common bullet points that can be used to jump-start further conversations internally in your organization. This is because I am not (at this time, anyway) making an attempt at a one-size-fits-all scenario. Instead, let us begin with common understanding between agile development teams and agile product managers:
by Mark Kromer
Is a product manager always the “product owner” in the Scrum? Not always. In larger organizations, there will likely by a product manager who is both inbound & outbound marketing as well as a technical SME or evangalist. In addition, there will be someone in a role of a program manager (as we find in Microsoft), a technical product manager (found in Oracle) or a business/systems analysts, which I see quite often in IT developlment shops. In most cases, those later 2 personas who have a much easier and more productive time on a Scrum team are the product owners. They are more comfortable joining the Sprint reviews and working on a product backlog.
That being said, there is not a proven hard & fast rule about the product owner. Instead, I like to provide the guidance that the best Scrum team includes the product owner in Sprint meetings (not daily stand-ups) and that person should be someone that the development team trusts with ownership of the product backlog.
From top-down, the product manager and marketing must have confidence and trust in the product owner such that their priorities are being properly addressed, pushed and managed from the product backlog. Bottom-line is that the product owner must laiason between the 2 worlds and is vital from a product management perspective.
© 2010 Techprodo Blogspot · Proudly powered by WordPress & Green Park 2 by Cordobo.
Valid XHTML 1.0 Transitional | Valid CSS 3
