Your SlideShare is downloading. ×
  • Like
  • Save
Release Management: Successful Software Releases Start with a Plan
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Release Management: Successful Software Releases Start with a Plan

  • 8,975 views
Published

This presentation was given at devLink 2010 in Nashville, TN and will weigh the pros and cons of each type of release cycle and identify what else is needed for a successful software release.

This presentation was given at devLink 2010 in Nashville, TN and will weigh the pros and cons of each type of release cycle and identify what else is needed for a successful software release.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • This is a very good presentation and covers the majority of points with the exception of test environment management and how it fits into the end to end Release Management lifecycle. Regardless of the frequency of releases test environments needs to be managed for usage by projects or BAU to ensure contention is removed.

    Plutora Inc has developed software which managed the end to end release management process. http://www.plutora.com . The tool focuses on ensuring that as per your spreadsheet the release plan is mapped out and then the execution of the release is available for all stakeholders to see.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
8,975
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
1
Likes
10

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Project Plan vs. Release PlanRelease plan is usually at a higher level than a project plan. In some Agile organizations the release plan is the project charter and the project plan is replaced by iteration management.
  • Release:Should contain FeaturesShould be TestedShould be DocumentedIn Agile methodologies: May include multiple iterations of workRelease Cycle:There are several types of release cycles that we’ll review in a momentRelease Plan:Prerequisites:Product Roadmap(s)Contractual CommitmentsProduct StrategyRelease Cycle
  • Product complexity:Simple: 1 week of QAMedium: 2-3 weeks of QAHighly complex: 2-3 months of QACustomer absorption:Easier it is for a customer to absorb the release, the more frequent the release can beMajor UI changes can’t be released every month, users will get frustrated and leaveMicrosoft released Microsoft Office updates every 2 months, each time changing the ribbon.Tax software isn’t released in Mar 2011, it won’t be adopted and the software will failProduct Roadmaps:Marketing / product management have usually put a lot of research into product roadmaps, so don’t disregard themUsually Internal and external versions. Internal contains Customer commitmentsProduct roadmaps are aimed at keeping the software in step with the market and technologyProduct roadmaps don’t always outline all releases to be expected from a product, especially not “minor” non-marketable releasesIf you’d like to learn more about product roadmaps, there is a session on Sat @ 10:30.EstimatesWhether using Agile or Staged-Gate/Waterfall development methodologies, features still need to have a swag estimate in order to decide on the release cycle and build the release plan
  • Maintenance Release is generally included in either Time Based or Feature Based Cycles
  • Time based release cycles are great for software updates, minor features and minor technology supportExample: my product releases monthly, last month we gave users the ability to print their report, this month we are targeting the ability to save reports to Excel, next month we’re planning to release the ability to save reports to PDF and so on.Major features don’t work well within a time based release due to the risks in development. For example, moving a thick-client product to browser-based is not something you want to release based on time.AdvantagesUsers and management like time based releases because of the predictability.Everyone knows when to expect the release, so development, qa and customers can all plan appropriatelySales and marketing like set schedules.DisadvantagesLong calendar schedules (such as annual), can place too much time between releases. Allowing for too many features to be included, thus overwhelming the users.Short calendar schedules (weekly or monthly) can be too quick. This can aggravate users and give development too little time to complete features. Resulting in a release with no features or of poor quality.When you’re on a time base release schedule and you either don’t have time to complete a single feature (usually due to issues) or you don’t have anything prioritized high enough, you may not need a release, but you have to put it out because it is expected.
  • Great for supporting major technologies and grouping features into a cohesive set, or releasing a new innovative extension of a product (or even a new product).In contrast, minor features and technology updates don’t work well within a feature based release. Mainly because more time is spent in QA & Rollout than in Development, resulting in a negative ROI for the release.For example, upgrading your software database from Oracle 10g to 11g would be better in a Technology cycle, but upgrading from Oracle 10.1.0.2 to 10.1.0.3 is costly in a technology cycle as these upgrades are usually minor and are better suited in a Time Based cycle.AdvantagesTargeted QA and training – since the development has been limited to a specific feature group or technologyUnified set of features – “Improved Performance”, “New Scheduling App” gets attention by users and makes the release easier to market.DisadvantagesHarder to schedule, thereby requiring more communication to sales, marketing, customers and support teams.Project Delay risks – If there are any issues, you can’t move the feature to another release. Delays in an external technology.Increased Project/Release Management effort – many times longer in duration and riskier (especially those with external technologies), therefore requiring more oversight.Example: a product relying heavily on Microsoft Office, because of the risks, chose to release their full support of Office 2007 as a technology release in late 2009.Example: you may have a reporting product that runs reports for users against data and you are adding a scheduler to the product so the users can schedule their report for future dates. You may have several iterations to support the scheduler (able to schedule on a date, able to schedule recurring weekly, etc), but only want to release it to users once for training and marketability.
  • Market Demand BasedContractual Commitment - Bob from sales stopped by today to brag that he sold another large account. They are implementing in 60 days and guess what? The deal requires the software be branded as if it were the customer’s software (logos, software name, color scheme). Your next release cycle is now defined…SeasonalTax software – you don’t want to release new tax software updates in March or April, since that is high tax season. Instead it is better to release this software late in the year (Oct, Nov)School softwareCompetition/MarketStay current with your marketExample: Healthcare software adoption of ICD-10-CM codes needs to coincide with the government requirement of 10/13/2013Try to have your features out before your competitionThis is where having the product roadmap comes in really handyThis release frequency is used mainly for established products or custom products and is likely mixed with a feature/technology based cycle type.AdvantagesRelease as required – potentially more time in development/QADisadvantagesLittle control – the contract, season or market is setting your release frequency, not your organization.Little room for innovation – still trying to make it to market before your competition
  • Any of the Release Cycles can be mixed together, as long as the organization can accommodate. For example, I might have a product that releases on a quarterly basis (next release is expected Sept 30), but we’ve scheduled a major technology release 2 years out (tentatively set for August 2012) and have a customer commitment that must be in production by October 15. Just be sure to work with the development and QA management when deciding on release cycles and keep in mind the product’s roadmap, as sometimes it will need to be adjusted to reflect the reality.So now we’ve selected a release cycle, it’s time to Build a Successful Release…
  • In some organizations, this could be considered the project charter
  • GoalsShould be measurableShould tie to Product StrategyExamples:% increase in market share# of new sales% increase in customer satisfaction (usually measured by uptick in marketing survey)Average $$ savings of reduced resources (person hours or hardware hours) Productivity improvementFeaturesWhat is included in your release will depend on what release cycle you chose.Release Cycle has a date:Review the features in your backlogSelect those features where the total of the estimates can be completed by the date of the releaseBe sure to accommodate for release QA timeRelease Cycle has a set of features but no date:Identify the features required to release the softwareAdditionally identify some “nice to have” features that go along with the feature group
  • Milestone ScheduleLayout the key milestones of the releaseIteration start and end dates for each iterationQA start and end datesExpected release dateResponsibilitiesIdentify responsibilitiesIdentify owners as named persons, usually at the management levelExamples:Resources available and assigned to develop features - Development MgmtHardware environments available for development, unit testing, QA testing – IT MgmtQA resources available and assigned to QA release – QA MgmtAdditional details will be added to Requirements/stories as needed – Analyst Mgmt/Product MgmtMarketing program needs developed - Marketing
  • DependenciesIdentify all dependencies for the releaseExamples:Development environment availableQA environment availableOffice 2012 available for developmentRisks & MitigationsIdentify all risks for the release, as well as the mitigation strategyExamples:Outside vendor is behind schedule – project mgmt follow vendor closelyInadequate requirements – team review and adjust earlyPersonnel turnover – paired programming (if applicable) and/or code documentation/reviewUnderestimated requirements/stories – if date driven, adjust features; if feature driven, determine if req/story can be split into must and nice to have or adjust date
  • InternallyIf the supporting teams don’t know about an upcoming release, you set yourself up for your product to sit on a shelf, rather than being used.Types of internal communication:EmailsMeeting(s)Release Highlights/NotesExternallyIf you release a product to production and your users aren’t expecting it, you could loose your customer base, especially if the users are disrupted.Current customersPotential customersTypes of external communications:Press releasesRelease Highlights/NotesEmailsLettersProduct SheetsPhone CallsPresentationsFrequencyDepends on the frequency of your releases. Monthly releases = at least twice (beginning of release and just before launch).Internal communications could be more frequent, especially if the release date changes.Sales & Marketing Launch PlanWhen the release is a large, marketable release, then the Sales & Marketing teams need to create and work a Product Launch Plan.Launch plan will have a budget and can include items such as press release schedules, advertising, product demonstrations and trade shows.
  • To determine release readiness:Does the release contain the features you planned on (even if you adjusted your plan)?Do you still expect the release to meet the goals outlined in the Release Plan?Just some of the items you might find on a readiness checklist.
  • Doesn’t matter what frequency you release your product, as long as you plan, it can be successful.

Transcript

  • 1. Release Management
    Successful Software Releases Start with a Plan
    Connie Harper
    8/5/2010 12:00:00 PM
  • 2. Session Summary
    Even in an agile world, you need a release plan, unless you plan on releasing every iteration to users. Do you release your software based on time (weekly, monthly, quarterly, yearly), on features (groups, major, minor, committed) or when everything planned for is complete? This session will weigh the pros and cons of each type of release cycle and identify what else is needed for a successful software release.
    2
  • 3. Who Am I? Connie L. Harper
    Product / Project Manager
    Dual Bachelor’s of Science degrees
    Computer Information Systems
    Management
    From: Ferris State University in Michigan
    Over 14 years in Software Development
    4 years as COBOL Developer
    1 ½ years as Database Developer (Oracle)
    9 ½ years as Product / Project Manager
    Pragmatic Marketing Certified
    Member of Association of Product Management and Product Marketing (AIPMM)
    www.linkedin.com/in/connielharper
    3
  • 4. Session Agenda
    Release Plan: Defined
    Release Cycle
    Deciding Factors
    Types
    Building a Successful Release
    Plan
    Communication
    Product Readiness
    Conclusion & References
    4
  • 5. Release Plan: Defined
    Release: A version of a product placed into production.
    Release Cycle: Frequency at which a version of a product is placed into production.
    Release Plan: An overview of the release, identifying the efforts to make it successful.
    5
  • 6. Session Agenda
    Release Plan: Defined
    Release Cycle
    Deciding Factors
    Types
    Building a Successful Release
    Plan
    Communication
    Product Readiness (not feature readiness)
    Conclusion & References
    6
  • 7. Release Cycle: Deciding Factors
    Product complexity
    Regulatory
    Customer absorption
    Installed vs. Hosted
    User Interface changes
    Market seasons (tax, school)
    Training
    Product Roadmap
    Internal
    External
    Customer commitments
    Estimates
    7
  • 8. Release Cycle: Types
    Time Based
    Feature Based
    Market Demand Based
    Combination
    8
  • 9. Release Cycle Type: Time Based
    Calendar Schedule
    Monthly, Bi-monthly
    Quarterly
    Semi-Annually, Annually
    Advantages
    Expected by all parties
    Set schedules (simplified project/resource management)
    Disadvantages
    Too much/little time
    Too few/many features
    Expected release
    9
  • 10. Release Cycle Type: Feature Based
    Feature groups
    Support external technology
    Advantages
    Targeted QA and Training
    Unified set of features
    Disadvantages
    Unknown frequency
    Delay risks
    Increased Project/Release Management
    10
  • 11. Release Cycle Type:Market Demand Based
    Contractual Commitment
    Seasonal
    Competition / Market
    Advantages
    Release as required
    Disadvantages
    Little control
    Little innovation
    Release as required
    11
  • 12. Session Agenda
    Release Plan: Defined
    Release Cycle
    Deciding Factors
    Types
    Building a Successful Release
    Plan
    Communication
    Product Readiness (not feature readiness)
    Conclusion & References
    12
  • 13. Successful Release: Plan
    Goals
    Features
    Key Milestones
    Responsibilities
    Dependencies
    Risks & Mitigations
    13
  • 14. Release Plan
    Goal(s)
    Why are you developing this release?
    Measurable
    Features
    What is included in this release?
    Based on Release Cycle
    Has a date: Select features to fit the date
    Time based
    Market Demand based
    Has specified features: Select date to fit the features
    Feature based
    14
  • 15. Release Plan
    Key Milestones
    Release Date
    Development Milestones:
    Agile: Iteration dates
    Waterfall/Stage-Gate: Key development dates
    QA Milestones
    Responsibilities
    Who is responsible for what items?
    Identify the key items needing ownership
    Identify the owners for each item
    15
  • 16. Release Plan
    Dependencies
    Is the release dependent on anything?
    Risks & Mitigations
    What risks are there and how do we mitigate them?
    16
  • 17. Successful Release: Communication
    Key to success
    Internal communication
    External communication
    Frequency
    Depends on Release Cycle
    Sales & Marketing Launch Plan
    When appropriate
    17
  • 18. Successful Release: Readiness
    Include Planned Features
    Expect to meet Release Goals
    Completion Checklist:
    Documentation
    Training
    QA Approval
    Sales Tools
    Pricing Established
    Marketing Collateral
    Marketing Programs Established
    18
  • 19. Successful Release: Conclusion
    PLAN
    19
  • 20. References
    Agile Excellence™ for Product Managers
    A Guide to Creating Winning Products with Agile Development Teams
    By Greg Cohen
    ISBN: 978-1-60773-074-3
    Expert Product Management
    Advanced Techniques, Tips & Strategies for Product Management and Product Marketing
    By Brian Lawley
    ISBN: 1-60005-079-4
    20