Presented by Christina Noren of Splunk
Been at two companies where dev wanted to do agile, but as a PM, had a sense that it would be a way to cut her out of the picture.
Decided to embrace it as PMs, and make sure they have a good perspective with some automation.
Going to go into the live Jira system.
Love Prag Mktg's rules -
These three things are her focus as they work in agile.
It can be confusing for the field if requirements change during development.
Market info: Lots of different sizes of customers, so confusing set of market input.
A lot of feedback for a 100 person company - better than the opposite problem of having only a few customers.
Spent $10k's on customizing jira.
Splunk has a very open approach - free download, high touch. Open architecture and APIs (applied to lots of apps that are unexpected). Public documentation, public roadmap, blogs and dev videos, even about new R&D.
Splunk's public roadmap has always been out there, but needed automation to make it reasonable to publish. Not a contract, can change it, but want it to be an honest picture of the future.
Splunk has a full-time video guy - using it for product marketing. Needs to be able to tie the product roadmap to the openness of having dev videos.
Need to mediate between product marketing message and low-level technical message, both of which get out the market. Want to avoid confusion in the market between these two stories.
"Loosely SCRUM" - 5-7 scrum teams at any time. 2-4 week sprints, some sprints are design or QA-based.
Preview releases for continuous customer delivery - Don't want to constantly deliver new GAs - have a preview release program - like MySQL and their "stable" and "unstable" branch. Building a capability for having the build engineer update the preview release based on the nightly build. Preview releases are not beta, betas are an artifact of the old waterfall methodology. Don't promise to have any features in any preview release, even if promised for the next GA.
Most recent Splunnk release is first GA dev'd fully agile.
Roadmap was contentious. Agile and roadmaps are oil and water.
How would they get market and competitive inputs?
De facto positioning of new features
Would PMs be able to be there for key decisions? PMs are out in the field all the time.
Decided to use Jira for PM - already on there for dev and QA. Looked at other tools - but engineering would feel that a PM tool would be considered to be a PM black box. Felt needed to have full integratoin between CRM and Jira and PM tools. When they poked, found that the tools weren't really integrated with other tools. Need to support PM in their role to interconnect various parts of the organization.
Felt that agile tools didn't really support PM very well - lip service. E.g., customer requests go into backlog, rather than having a process for triaging, etc.
Jira was extensible, and she was able to prove for herself that Jira could be extended to do what she wanted.
Key points on Jira - accepted by every member of the engineering team. If she could make sure that every issue that it was worked had a link back to a customer.
She's not creating any (static) documents that get out of date - hasn’t for two years.
Not cheaper than (e.g., Accept, other PM tools) but more digestible.
(Christina shows a nice picture of the information flow)
Engineering queue - bug or requirement. Not using tasks.
Created an issue type of enhancement requests. They get entered into the system (email-based integration) via monitoring an inbox and polling the inbox. Also picks up changes - if the customer changes the description or it's reclassified, the changes are reflected back into Jira. Key fields - name of account. Enhancement requsts are a work queue for PMs. PMs are also judged on how many call reports and market data points they enter. Market data points are of type competitive - e.g., a competitor has this capability that we should worry about. Another datapoint would be the growth of the virtualization market.
Call reports are based on customer visits. If you visit a customer, write a call report.
One goal is to encourage people outside the PM org to do some PM work, but keep it visible.
Everything gets turned into problem statements in Jira. Use case detail goes in there. Problem statements get prioritized. There are about 350 in their system. They go into hierarchies under themes. The major part of the PM work is creating and organizing problem statements.
Priority planning for their problem statements went very well this time, compared to the previous times it's been done. Already working well for them.
Problem statements map to requirements and to features. Features are bullets for the product roadmap. Requirements are at an engineering level. Dev-centric tools trivialize the difficultly of mapping between a customer presentation of a feature and dev presentation of a requirement. Features are meant for external consumption. Have a feature statement and a benefit statement.
Engineers (e.g., leads or architects) are allowed to enter requirements into the backlog if they are needed. How are these prioritized into the backlog?
Lots of kinds of requirements - documentation requirements, technical requirements, etc.
The biggest issue with Jira they have today is reporting - hard to track how defects are tracking through the system.
Things can happen in different orders in the system - start from an engineering idea and later determine (make concrete) the problem statement and the feature. Or do it the other way.
If they know they want to do a feature, then they have to figure out why they should - come up with a problem statement or link to one that already exists.
PMs enter usability requirements and tech design requirements (but the engineers or usability people actually implement them).
Q: Are they using personas? If needed, they are in the body of the problem statement. Not a first-class formalized thing at the moment.
Using some third-party Jira plugins for some reporting. Also had their consultant create a number of reports.
Demo: Showing the Jira implementation they've done.
Standard actions:
Would like to track deal value when there's a deal associated to a feature. Sales person would enter a "Blocker" vs. "Influencer" in the case.
Prioritization is done via a weight. (1-9 weighting - to workaround a Jira limitation.) So there's no stack rank of all the Problem Statements. Then requirements are prioritized by the PMs and engineering managers working together.
Using "blocker" features as their release themes.
Distinguish features and applications on the Feature element type, using a field.
Sistema de revisão feito pela Weblocal hospedagem de sites!