Agile and PPM – Q&A

On October 27th, I co-presented the webinar, “A Marriage Made in Heaven: Agile and Project Portfolio Management”, with Russ King, Vice President, Product Development, Results Positive, Inc. and Caleb Brown, Systems Engineer at CollabNet. We explored the benefits of marrying Agile Project Management and PPM and we did a live demo showing this using HP’s PPM solution and CollabNet’s ScrumWorks Pro to demonstrate the powerful capabilities of managing a resource constrained project portfolio.

Judging by the number of questions, the audience was clearly heavily engaged. We had a 15 minute Q&A and did not come close to answering all of the questions, so I’ve listed most of them here and provided a response. I also encourage you to try ScrumWorks Pro for free.

As promised, here’s the follow up to the live audience questions.

Q: How feasible is Agile on Projects & Programs?
A: Agile is typically thought of in the context of individual projects. Companies sometimes fail to scale that paradigm to a program level, where the program is a superset of multiple projects, each running its own lifecycle and release plan. The trick is to weave those separate lines of development (projects) into a coherent and seamless deliverable (program). The complexity comes in gathering meaningful metrics and planning releases that thread the elements together. This is exceedingly difficult to do manually. CollabNet’s ScrumWorks Pro is a tool that can make this manageable. It supports the planning of complex releases that weave in multiple development threads.

Q: Will this process will be feasible for maintenance related projects (Incident handling, less than 8 hours development works, etc.,)?
A: From the PPM perspective, an individual defect is not in and of itself a project and as such, would not be tracked. What might be tracked is a larger group of maintenance items in the form of an Epic. From an Agile perspective, a bug report or defect is just another piece of deliverable business value, like a User Story or any other Product Backlog Item. From a bug report, the product owner and team would create a Product Backlog Item (PBI), along with success criteria (definition of done). It is prioritized against all of the other Product Backlog Item by the product owner. Again, multiple bugs/defects are often grouped in an Epic.

Q: It seems the PPM is geared toward a waterfall process. It appears there is only visibility into the Development phase, but with agile, you could potentially address all phases within a single sprint. Is that just because of the way this implementation was set up or is it there isn’t a true marriage of the agile within PPM?
A: PPM in this scenario is focused on evaluating the ROI of different projects and deciding where to make investments. Agile is focused on execution of the projects that are chosen. That said, the scenario we propose makes the entire organization more Agile, in that the feedback loop is instantaneous. This allows those that are making the investment decisions to adapt and make course corrections that are indicated by that feedback loop. The integration gives all team members the ability to work in a more Agile fashion, and gives Stakeholders and Project managers the ability to benefit from the faster feedback and data generated by the team working this way.

Q: Can the tasks in Scrum WorksPro be connected to tasks, timelines in Source forge?
A: Not with Sourceforge. However this is possible with Collabnet Teamforge, the current commercial version of Sourceforge.

Q: Can you clarify what part of Agile PPM can be done in scrum works pro without need for HP PPM?
A: ScrumWorks Pro is focused on project execution and project management. As such ScrumWorks does a number of things not accomplished in HP PPM. These include PBI tracking and prioritization, Task management sprint planning, release planning, team velocity, forecasting, and many other functions related to the management of an Agile project.

Q: So are you proposing (in the demo) to combine a phase/waterfall planning and design phase, but then execute in an agile framework?
A: Combining HP PPM and ScrumWorks Pro adds to the agility of the entire organization. Feedback loops between the development team and the PMO are enhanced allowing the PMO to make course corrections required. I would not say that as a result the entire enterprise has become agile – only that they’ve become more agile. Generally, we do not see many organizations that practice a pure version of ANY methodology –be it Agile or otherwise. The reality is that organizations have a mix of methodologies, like Scrum, Kanban, Waterfall, hybrids, etc. Different teams in large organizations will often build software differently, so the challenge is to roll up the data from those disparate teams. Despite their differences, there are a number of common metrics you can track regardless of project type. These include actual cost versus budgeted cost, scope change, personnel/resource change, delivery dates, and others. Tools like ScrumWorks and HP PPM do a good job in tracking these kinds of numbers.

Q: Continuing from the first question, from a portfolio perspective, having “”open-ended”” project budgets within the Agile/SDLC process is not in the best interest of my customer. How does budget planning and Agile development work together while still having some control over costs?
A: Project prioritization and the associated budgeting/funding are is under the purview of the PPM tools. The agile project management tool tracks the amount of time individuals spend on the project. The integration between the HP PPM tool and the Agile Project Management tool, allows you to easily compare budgets against actuals.

Q: In agile, what are the differences between being adaptive to late changes in requirements within a sprint and scope change?
A: Scope change refers to any added or subtracted scope, typically measured in some form of relative effort unit like Story Points. As such, scope may be added as a team discovers more about an existing requirement. In other words, if the team finds out that a requirement is more complex than was originally envisioned, they may re-estimate the number of story points and this might add scope to a sprint. The opposite could also be true. Whether this occurs because of a discovery inside a sprint or outside of it doesn’t change the nature of how it is tracked or reported upon.

Q: When a committed backlog item could not be completed in a sprint, naturally it holds the top most priority in the following sprint. How does ScrumWorks helps in tracking this item from the beginning to end?
A: An unfinished PBI may or may not be a high enough priority in a future sprint. The determination is made by the product owners. In any event, any activity against that PBI is tracked. Tasks completed that relate to that PBI are tracked, as are those that were uncompleted.

Q: What certification do CollabNet-trained scrum masters receive?
A: Those who attend one of our Certified Scrum Master or Certified Product Owner training are eligible to take the exam deliver by the Scrum Alliance. It should be noted that CollabNet is one of the leaders in ScrumMaster product Owner training. We have more Certified Scrum Trainers on staff than any other vendor, and we’ve trained more than 12,000 ScrumMasters.  We also give away free online Scrum Master training to supplement the certified training.

Q: If an organization wants to be able to report a metric of time to resolution for individual PBIs, what settings are available in this integration to include/exclude a PBI from the current active lists so that a countdown starts appropriately?
A: Forecast reports in ScrumWorks can be filtered on any number of aspects, allowing a user to deliver estimates on individual tasks, Stories, Epics or Themes. By the way, you can try out ScrumWorks Pro either in a hosted environment or as a free download.

Posted under Agile Coaching, Agile Methodology, PPM, Scrum, Scrum Coaching, Scrum training

Should the Product Owner Attend Daily Scrums?

In one sense the Product Owner is part of the Scrum team. The Product Owner communicates the vision for what is to be developed and revises priorities. However, that doesn’t mean that the Product Owner should be involved in every aspect of development. One particularly hard question is whether the Product Owner should attend the team’s daily Scrums (or daily standups). And the frustrating answer to that question is: It depends.  Our usual suggestion is to try it whichever way you haven’t been doing it in the past, then use the Sprint Retrospective Meeting to reflect on how it went.

Most of the time people ask us this question, we find the person playing the Product Owner role is actual a proxy instead of the real business decision maker.  For example, if you don’t have the authority to cancel development, you’re probably a proxy, not the actual Product Owner.  Often we discover the Product Owner proxy’s boss is the real Product Owner.  So a problem with stating the Product Owner must always attend the Daily Scrum is that it encourages organizations to choose Product Owners who have too much free time instead of the real decision makers who might not be available (or even necessary) daily. Ken Schwaber, who wrote the original books on Scrum, recently wrote about the downsides of a low-level Product Owner as encouraged by some XP folks.

Watch a team wrestle with this issue about halfway through this example Daily Scrum meeting.
Example Daily Scrum Meeting video

For new teams, the most frequently overlooked problem with involving the Product Owner in the daily Scrum (and also the Sprint Retrospective) has been described as the invisible gun effect.  Even when the Product Owner doesn’t try to dominate the meeting, the presence of someone with power and responsibility in the organization will prevent the team from stepping up to the same degree of self management.  For more information about the invisible gun effect, see the Sprint Retrospective Meeting elearning module, Is My Boss On the Scrum Team? or an upcoming book  by Adam Weisbart.

Invisible Gun Effect

Other teams have found it beneficial to include the Product Owner in the daily meeting, especially once their self organization habits are better established.  As suggested, try it whichever way you haven’t been doing it in the past, then use the Sprint Retrospective Meeting to reflect on how it went.

 

Posted under Scrum

This post was written by admin on October 13, 2008

Tags: