The Role of Product Management in an Agile World

1. The Role of Product Management in an Agile World Product Management Webinar Series January 2013 Jim Foerster Senior Product Management Director Smart Infrastructure Weather

2. Agenda • Agile Team Roles • Keys to Success • Product Management Framework in an Agile World • How Do We Get Started? • Beware of Mines • Early Lessons • Summary and Questions

3. Agile will… • Result in better product outcomes • Generate a higher initial product quality • Drive collaboration • Eliminate meetings and documentation that don’t add value • Identify and address product implementation risks early • Find quality issues early in process • Increase productivity

4. Who’s who? • Scrum Master • Leader and “Team Coach” • Ensures that the Agile process is being followed • Facilitates the team, obtains resources for it, protects it from problems • Product Owner • Focal point for ALL product decisions • Must make decisions in a timely manner • Determines what will be worked on next by the team • Clearly defines success measures for work being performed (e.g., Acceptance Tests) • Team Member(s) • Those responsible for creation and delivery of a system • Modeling, programming, testing, release activities, etc. • Stakeholder(s) • Direct or indirect user of end product; managers; partners, etc.

5. Supporting Roles • Some Roles are part of the Agile Team or just used a in a consultative basis. The Agile Team decides. • Architecture • User Experience • Other Roles are generally never on the Agile team but provide support, input, or expertise when requested by the Team • Subject Matter Experts • Customer Service • Marketing • Sales • Management

6. Typical Small Agile Team Typically part of PM

7. Keys to Success • Most or all team members must have a formal understanding of Agile • The team must agree on common definitions for Agile terminologies as well as team roles • The team must be dedicated to adhere to the Agile principles • The team must have full support from management • The team must have a distributed or web-based scrum project management software

8. Product Management Framework ProductRoadmapping Communication Sprint X+ ~ Translating Strategy Brain Storming Release Theme Roadmap Backlog Requirements Documentation Release Plan Sprint X +30 Requirements Gathering Incorporation of Backlog Release Notes Support Release Planning Sprint X +7 Collaboration Sizing Backlog Defining SprintGoals Project Kickoff Analysis Prioritization Sprint X Scrum Pre-Planning Planning Stand-Ups Sprint Review Scheduling

9. Roadmaps ProductRoadmapping Translating Strategy Brain Storming Release Theme • Translating business strategy into roadmap items • Assumes market exists and there is a place for Schneider Electric to play • Goal is to have “planning” 12-month roadmap and “defined” 6-month roadmap ahead of current sprint • Get buy-in from Sales and Executive teams • Monthly business priority meetings • Consistency with BU strategy? • Aligned with partner strategy? • Identify broad themes that can be focus of product marketing • Seasonal, industry specific, etc. • Constantly be on the alert for new ways of doing things • Product enhancements based on feedback • New features • What’s the competition doing?

10. Requirements Documentation Requirements Documentation Requirements Gathering Incorporation of Backlog • Not a huge change from Waterfall methodology • Cast a wide net and ensure all stakeholders are represented • Ensure there is a level of clarity to each item that is easy to understand what is being requested • The better the requirements document, the more successful your project will be • Think ahead when you write – and realize this epic will need to be broken into stories

11. Release Planning Release Planning Sizing Backlog Defining SprintGoals Project Kickoff • Release planning is needed to help the team determine what they must produce by what time. • Prioritize themes and goals for release • How does project fit within other current priorities • Contractual commitments? • Development capacity • Opportunity cost • Target release date set

12. Go! Scrum Pre-Planning Planning Stand-Ups Sprint Review • Pre-Planning • A key step in determining which and how many stories to include in the next sprint • The Product Owner really owns the sprint pre-planning meeting • Typically the flow is… • Product Owner chooses initial set of stories from product backlog • Team reviews/discusses/exchanges/drops user stories • Team estimates the size of the stories (story points per story)

13. Go! Scrum Pre-Planning Planning Stand-Ups Sprint Review • Planning • Attended by the Product Owner, Scrum Master, and the entire Scrum Team • Outside stakeholders may attend by invitation of the team • Product Owner describes the highest priority features to the team. • The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog. • Product Owner should seek to populate at least first 2 Sprints from this meeting

14. Go! Scrum Pre-Planning Planning Stand-Ups Sprint Review • Stand-Ups • Run by Scrum Master • All team members are required to attend the daily Scrum meetings. • Daily, the same time, ideally in the morning • Time-boxed to 15 minutes – no chatting • Only those “committed” are allowed to participate • Not a problem-solving or issue-resolution meeting – take those offline • Get in, get out, get to work

15. Go! Scrum Pre-Planning Planning Stand-Ups Sprint Review • Sprint Review • At the end of a Scrum sprint, the teams conducts a sprint review • During the sprint review, the team demonstrates the functionality added during the sprint. • The goal of this meeting is to get feedback from the product owner or any users or other stakeholders who have been invited to the review. This feedback may result in changes to the freshly delivered functionality • Could also lead to revising or adding items to the scrum product backlog.

16. Communication • Must communicate effectively to multiple audiences • Roadmap reviewed and updated monthly • Backlog constantly evolving with “old” and “new” items • Backlog is essentially a “living requirements document” • Marketing support and rollout plan • Frequency of publication for release plan and release notes are fixed (every sprint) Communication Roadmap Backlog Release Plan Release Notes

17. Support • Weather team actually runs Support as it’s own Sprint due to large volume of support items • Some capacity allotted each month for projects • Product Backlog must be prioritized with cross-departmental input • Customer Service team heavily involved here as the voice of the customer • Still owned by Product Management Support Collaboration Analysis Prioritization Scheduling

18. How Do We Get Started? • MRD provides the initial Vision • An MRD would be called an EPIC in Agile terms • Initial Story backlog is generated from the MRD

19. User Story Creation • A user Story is a concise statement of a need, capability or effort that needs to be completed to deliver a product. • Basic form • As …, I need to… so that… • Stories should be as specific as possible • Stories can be added at any time

20. Story Examples • As a Pilot, I need to enter my destination using an airport code so that I can track weather patterns across my route • As Customer Service, I need automatic notification when a customer has purchased ASO so that they can be configured in the system. • As a technical architect, I need to create a POC to validate the performance of the new Google map version

21. Acceptance Test • Provides clarity on what is expected from the Story • Completes the Story Definition • Generally, written by the Product Owner or creator of the Story • Defines Success Criteria for Developer • Provide a detailed statement regarding what is expected by the Story • A good Acceptance Test • Requires a LOT of thought • Is generally not long • May require ancillary material (i.e., image, UI model, wireframe, etc.)

22. What about the SRS? • SRS is no longer needed • The “holes” in the MRD will be filled by defining additional Stories • Instead of trying to drive out all the details up-front, details will be determined at the time they are needed • Acceptance Tests provide detail about the Story

23. Managing Progress

24. Early Lessons • Must have strong internal advocate – preferably at management level • Must have strong Scrum Master as will be resistance and slow adopters • Communicate early success • Challenge of external market-facing duties conflicting with daily responsibilities • Missing Stand-ups • Becoming bottleneck • More projects = more work • Don’t let Stand-Ups turn into long-winded meetings • Cross-project conflicts can arise due to existing silos

25. Product Management – Agile Style • Communicate daily • Build upon incremental successes • Demonstrate working solutions as quickly as possible • Everyone contributes everyday • Rise and fall together; One Team & One Voice • Don’t overthink; learn from doing • Improve continually • Automate everything reasonable • Embrace change

26. Questions Jim Foerster +1 952-457-9937 jim.foerster@telventdtn.com