Insights and Takeaways: Agile Topics at Project World/World Congress for Business Analysis
For the past several years, I have had the privilege of chairing the Agile Summit portion of the Project World/World Congress for Business Analysts. I hope you were able to join us last month in Orlando. We had a tremendous turnout and enjoyed our time learning and networking with each other.
Since then, I’ve had several requests for a summary of my half-day tutorial with Ainsley Nies, “An Agile Approach to Project and Products” as well as the Agile Summit presentation “Got Value? A Practical, Sustainable Value Model for Making Agile Product Decisions” and the track session I gave: “It’s the Goal, Not the Role: The Work of Agile Project Management and Business Analysis.” I wrote up a quick synopsis of all three, along with some suggestions that you can try in your next planning or retrospective session.
Continue reading
As I prepare to deliver my tutorial (“The Essential Product Owner”) and presentation (“Product Roadmaps: Collaborating to Deliver Value”) at Product Management Festival in Zurich later this month, I wanted to share with you an excerpt of an interview with Mary Gorman and me that was recently published on their blog.
Last time, I told the story of a team that experienced a breakthrough after clarifying the scope of a stalled project. Noting that scope creep—the unrestrained expansion of requirements as the project proceeds—is cited as one of the top project risks, I promised to describe some of the good practices that help product partners manage product scope in a disciplined way. With clients, I always stress the importance of developing a product vision, identifying goals and objectives for the product, and clarifying the product partners’ value considerations very early in the project before development proceeds. Let’s look at ways to do that.
Recently I worked with a project team developing a software product under grant from four entities, with a government agency as their ultimate customer. They called me in because, three months into a four-month project, they were desperately behind. Why? They’d been spinning in circles, trying to satisfy diverse stakeholders who had overlapping as well as conflicting requirements. The funding was split among several competitors, each with its own competencies, and there was a sense that the government agency was playing favorites based on its own preferences in the domain.
Impact Mapping: Making a Big Impact with Software Products and Projects
