Active Product Management is about focussing more on the active backlog items, i.e items planned for the shorter increment (Potentially Shippable Increments), rather than focussing on the complete backlog set planned for the whole release.

Many Organizations over the past few years have embraced agile and have experienced good results. Even after this transition to agile and following for several years, Organizations still face difficulty to release the software to the customers as per the commitments.

Would like to discuss the general problems with the traditional way of doing release planning and how "Active Product Management" can reduce the risks in delivering the commitments.

 
3 favorite thumb_down thumb_up 2 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Introduction

Walk through the presentation (Power Point Slides)

Question and Answers

Learning Outcome

The session can give an overview of the general release planning issues and risks being faced by product owners and product management group and how smaller potentially shippable increment roll outs can mitigate them...

 

Target Audience

People who are actively involved in Product Management and in scaling agile in their organizations

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Saket Bansal
    By Saket Bansal  ~  2 years ago
    reply Reply

    great topic, can you share more details about the emergent product backlog concept you would like to talk about, some case study where it really worked well will help.

    • Ramesh Lakkaraju
      By Ramesh Lakkaraju  ~  2 years ago
      reply Reply
      Thanks a lot Saket for the review and the comments.

      Here is what we have done in our organization a couple of years back to do an important release to win over a critical customer which was very much important for our business growth.

      What we have was done was to break the entire release into three smaller drops. The entire back log was divided into three major buckets (drops). Each drop was planned and executed for about  four months duration ( roughly four sprints ) and delivered to the customer. The first three sprints of the drop were used for developing(implementing) the planned backlog and  the fourth sprint was used as a hardening sprint to test the implemented functionality and then the drop was given to the customer. This way, the product mangement group(Product Owner group) was having more control and a dedicated  focus as the concentration was always   on a smaller chunck  of the backlogs which gave them lot of advantage in planning, tracking the dependencies and executing with good success rate. Even the customer who got the drops was very happy to see their requirements getting implemented. It also gave them a chance to review and see if the functionality that Is delivered was as per their expectation and also provided a platform for giving the immediate feedback to us which was very much helpful in grooming the backlog for the next drop. Doing this way the product mangement was always in complete control of  what is being done at any point of time and if it  is as per the expectation and matching to the requirements given by the customer. Another major advantage that was seen  by doing smaller drops is that the unkonwns were not kept till the end like in doing  a single release where the product goes for final integration testing just before releasing to the customer. The hardening sprint that is done at the end of implementation phase in every drop provided a very good opportunity to catch the  unknowns as the dependency and integration testing is getting performed in it. Even the predictability of being able to do all the committed backlogs within the time frame as per the customer requirement was also improved quite a bit in these short drops of potentially shippable increments. The customer was very happy at the end of the three drops as he saw his requirements getting implemented and he always felt that he was kept in loop on all the major developments as part of the release ( done through drops) instead of getting the information in the fag end of the release. This way we could win his confidence and ultimately the business which we were looking for.

      Hope this use case that we actually implemented gives a better understanding on the APM...

      Thanks,
      Ramesh




  • Liked Vijay Bandaru
    keyboard_arrow_down

    Vijay Bandaru - Scrum Master - The Team Spirit Guardian

    Vijay Bandaru
    Vijay Bandaru
    Agile Coach
    IVY Comptech
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Lord Krishna was our first Scrum Master who helped "Pandavas" to win the "Kurukshetra" war without using a single weapon. On top of it, he was the almighty with so many invisible powers, but he still guided the "Pandavas" through his servant Leadership.

    Inspired by this concept, I have created a session to highlight the role of a "Scrum Master" and how can we make a Scrum Master a true "Servant Leader" without so much depending on authority or tools rather concentrating on simple things that can make his contribution to the team a true differentiating factor.

    In this task, I am going to cover the following topics:

    - Understanding the team formation stages

    - 5 dysfunctions of teams

    - Gauge the team members' behaviours

    - How a Scrum Master can make his team GREAT

    - Soft skills for Scrum Master

    - How a Scrum Master help his team in various situations

    - Importance of learning for a Scrum Master

    - Scrum Master's backlog for his team's improvements

    - Scrum Masters checklist

    I will also cover anti-patterns of Scrum Master in this session along with suitable remedies.

  • Liked Krishnamurty VG Pammi
    keyboard_arrow_down

    Krishnamurty VG Pammi - Do you get equivalent value for the price you pay? What is missing?

    Krishnamurty VG Pammi
    Krishnamurty VG Pammi
    Agile Coach
    IVY Comptech
    schedule 2 years ago
    Sold Out!
    60 mins
    Talk
    Beginner

    Price is what you pay. Value is what you get. According to the Standish Group research, 20 percent of customer application development features are often used, 30 percent are infrequently used, and 50 percent are hardly ever used. This means that a major percent of the performing organization's effort does not correlate to value generation.

    Of the projects that met triple constraints, Standish Group research showed that only 13 percent yielded very high value, and 27 percent of the projects yielded high value. This means that about 60 percent of the projects yielded average to low value. And this means that, in the words of the study, "Sometimes you pay the price for a project but do not get the value."

    What is missing? - I reflected on this experience and also reached out to teams to learn what can bridge this gap. Interestingly, I got collective feedback that stated, "Either we fail to understand end-user experience, or we do not give much weight to it."

    User experience highlights the experiential, meaningful and valuable aspects of human-product interaction. Take the iPhone, which was launched in 2007. The phone’s unmatched user experience made its competitors out of the game; it set a new standard for smartphones. One of the secrets behind its success is the narrow set of customer needs Apple selected. Building customer satisfied products in the domain “internet of things” are becoming difficult and interesting now-a-days compared to other domains because gauging user experience in internet of things is quite dynamic and thus becoming quite challenging.

    When developing a product with agile, planning takes place at multiple levels. Agile projects involve planning upfront and throughout the entire project. This way, agile teams perform adaptive planning at last responsible moments by incorporating the then risks, issues, assumptions and constraints into consideration.  This will enable teams to change their course of action even in scenarios where requirements take abnormal shift or when teams come across unforeseen challenges. Agile planning thus remains more relevant and useful as it can guide teams till destination. Products that are complex, creative and high-risk in nature certainly prefers agile planning approach because traditional approach of “upfront plan the entire work and work the initially set plan for rest of the journey” cannot guide them till  destination.

    Experiential insights: I will unfold my experiential insights on how agile planning events (Vision, Product, Release, Sprint and Daily planning events) propel each other and nurture user experience periodically. I will explain how these adaptive planning outcomes connect each other and align themselves to the goal of delivering customer satisfied products.

    User experience is no longer a choice -- it is a means of survival: You have got to start with customer experience and work back toward the technology, not the other way around. The user experience approach is no longer about usability, it is about value creation. It is no longer the role of one person or department, it is about culture. It is no longer a choice, it is a means of survival. In the words of MarketingTech, "74% of businesses believe that user experience is key for improving sales, conversation, and loyalty." Thus we cannot afford to underestimate the impact of our users' experience.

    User experience does not start at purchase, it begins when the user has a need:  Agile planning events nurture user experience by discovering user needs. Aligning the product road map with user needs will certainly correlate product price to value creation. In fact, going with this approach, we can create situations in which end users perceive more value in our products than the price they pay for them. Google analyzes users' response patterns to their online posts and predicts user behavior even before users understand their responses themselves. It is an interesting journey toward understanding user experience, especially on products that leverage the Internet of Things. It is not an easy job to predict user experience. However, if we champion this aspect, we will indeed correlate product price to value creation.

     

  • Liked Madhavi Ledalla
    keyboard_arrow_down

    Madhavi Ledalla - The essence of Product Ownership

    Madhavi Ledalla
    Madhavi Ledalla
    Agile Coach
    ADP
    schedule 2 years ago
    Sold Out!
    60 mins
    Talk
    Intermediate

    Scrum introduces a very vital role called the Product Owner who is the key person responsible for the product success; he is one who is accountable for the customer delight.

     In this session we would be doing a deep dive at this role, the essential characteristics, the prime responsibilities, challenges and how can this role be scaled in a scaled environment where we would be discussing some of the structural and coordination patterns.

    The key take away of this session would be the last part where the participants would build a story map using “Jeff Patton’s” story mapping technique to visualize how a day of the Product Owner looks like.

  • Liked Saikat Das
    keyboard_arrow_down

    Saikat Das - Switch from Sprint Retrospective to Toyota Kata

    45 mins
    Talk
    Intermediate

    You have been doing agile for a few years now.

    With a regular cadence you have retrospectives and a lot of problems and great improvement opportunities are raised but nothing seems to really improve. Stop doing retrospectives!


    Can we shift form collecting problems and start improving? Create the habits of continuous improvement.

    It can be done is time to start using Toyota Kata!


    Toyota Kata is two behavior patterns, or Kata’s, that is the foundation in Toyota’s continuous improvement work.