Release Management: Successful Software Releases Start with a Plan

Editor's Notes

• #3: 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.
• #6: 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
• #8: 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
• #9: Maintenance Release is generally included in either Time Based or Feature Based Cycles
• #10: 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.
• #11: 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.
• #12: 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
• #13: 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…
• #14: In some organizations, this could be considered the project charter
• #15: 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
• #16: 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
• #17: 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
• #18: 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.
• #19: 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.
• #20: Doesn’t matter what frequency you release your product, as long as you plan, it can be successful.