Why Agile is not for developers
I know several developers who extol the virtues of Agile - and how it's made life as a developer so much easier. You're doing things faster, some say better - and finding out what people like (and don't like) about your software (and documentation!). You're communing with other teams and not re-inventing things that other teams have perfected. You're working smarter. I think that's great - but to me, Agile is something that's a broader concept that delivers on communicating with customers. Let me be clear this is my view, not some widely adopted 'manifesto'.
I know - that's a tall order, and it's covered by other areas of the business, so it may seem like it's not at all related to conversations with customers, but when it's done right, it should be. I believe the crux of making Agile work for customers is the PM and the user story (and Epics). Every developer likes well detailed, clear user stories - and I'm behind that 100%. What I am advocating for is that you consider someone who you generally don't when writing user stories: Marketing.
OK... I feel I may have just lost you, but hear me out for a moment.
If you, as the PM, can write your user stories in terms of how marketing will describe the feature or function to customers, you're building in success that can permeate the entire product. Sure, you need details about the core (and stretch) requirements you want delivered in a story -but you should also be describing the business and technical values of the solution in a way that is inculcated throughout the life of the product.
When written well, a marketing focused user story goes beyond defining features/functions for developers. When written with marketing in mind it delivers a narrative that your sales team can use to talk about the features, you sales engineers get a script to demonstrate the value of the feature, the documentation team knows how to write about it, the training team creates an educational narrative around it and support knows how to support it. Let's also agree that it adds flexibility to the development process - explaining WHY you are describing requirements for a feature - and giving them the artistic license to deliver on what customers needs rather than a rigid menu of requirements.
If you're interested in seeing what I mean by a marketing focused user story, let me know and I'll provide an example.
Marketing cartoon from FunnyTimes
Agile Marketing + Agile PM + Agile Dev = SaaS that sells™ * Mitch ;)
Here's a <modified> story written so that Marketing can make use of the data in the story (I've lost the formatting, so apologies if it's hard to read, with proper formatting, it's easier to discern what's going on a little easier when you get some formatting And just to be 100% truthful, I’ve removed the Customers: Section to protect their privacy (as well as a changed some of the wording in order to keep this “generic”). I can clarify individually ----------------------------------------------------------------------- Pain/Problem: With Windows 2016, Microsoft introduced a new server SKU called "Nano Server". This is a headless, remotely managed version of Standard or Data Center version of Windows 2016 intended to host high capacity, light weight applications and services. Nano server may be used for "elastic" applications. Today I can't install agents on the Nano Server SKU, so applications and services running on Nano Server are not being monitored and no data can be collected to report long term stability or service levels / availability. Business value: Coverage for all SKUs of the Microsoft Windows Platform provides competitive upkeep and differentiation (when delivered early in the life cycle). As our customers add Nano servers to their environments and place key services on them, the ability to provide monitoring and data collection for reporting will give customers more complete coverage of their infrastructure, application and service catalogs. Technical value: Providing the ability to manage this extension of the Windows platform is key for customers who run lightweight servers that can only be remotely managed. Being able to monitor applications and services from the distinct and granular level to the over-arching service level provides customers with availability and troubleshooting down to the granular/atomic level to rapidly diagnose and return degraded or non-functional systems back to service. Requirements: *As a Product Admin, I can (remotely) discover and manage Windows Nano Servers. *Management of Nano Servers mirrors existing remote management of windows servers. *Remote management includes *Server response on ICMP ping and response time to ping requests *Service management (status, settings, etc) *CPU, DISK, Network metrics Investigate and validate other metrics with Technet (see ref section) *Product identifies the managed device as Windows 2016 Standard: Nano Server or Windows 2016 Data Center: Nano Server in details of collected / presented information. *Documentation is available that describes limitations introduced by Nano Server (no GUI, no local logon, etc) where Product functionality is limited or inhibited. References: https://technet.microsoft.com/en-us/windows-server-docs/get-started/getting-started-with-nano-server http://www.tomsitpro.com/articles/how-to-remotely-manage-nano-server,2-1051.html https://technet.microsoft.com/en-us/windows-server-docs/get-started/manage-nano-server Acceptance Criteria: Please demonstrate…. Discovery Remote Discovery of Standard and Data Center versions of Nano Server. The computer being managed appears as a (remote) Windows server in the console / tree view. Management/Monitoring Applicable management capabilities (CPU, Disk, Network, services) are represented with icons. Data – charting - reporting Data collected is assigned to the appropriate/selected remote Nano Server and reports (of remotely managed data) are associated with Nano Server. Alerting / visibility When a remotely managed Nano Server is unavailable (as reported by a remote availability job), the Nano Server is identified and users are directed at investigation steps to determine what to address in order to return the server/service/app to service.
Darn short cut keys... I got half way through fixing the formatting when chrome/linkedin went buggy!!! Re-posting in hopes it's going to keep the formatting Give me a sec... :) Tim
I thought the idea was that you need very well-rounded Product Owners that understand sufficiently the business analysis, marketing, development, etc to be able to pull together coherent stories. I.e. surely having a 'Marketing' person write a story is just as big a pitfall as having a 'Developer' write one!
With some very important people requesting an example... I'll post one (once I "anonymize" it. But I will say that writing a marketing focused User Story isn't something that should take days (even hours)... Let me get you the example!