xChange13, Serena Software’s global user conference from September 16-18, is at the legendary Eden Roc Miami Beach. It sits between Biscayne Bay and the Atlantic Ocean, so attendees will be able to enjoy both a beach-front and bay-front location.
Historically, the Eden Roc has been home to artists and celebrities from all over the world and was completely renovated in 2011. With 600 hotel rooms and a modern, accessible conference center, xChange13 will be the only event happening at the Eden Roc over the week of September 15.
Even sweeter, we have secured a room rate of $159 per night at this iconic resort for the duration of your xChange13 stay, and the resort fee has been waived. The xChange13 special rate of $159 per night ends Friday, August 30. So, if you haven’t registered for the conference, now is the time! After Friday, rooms may not be available and prices will likely be much higher.
Register for xChange13 now! See you in Miami!
See what’s planned for xChange13, Serena’s global user conference from September 16-18 at the Eden Roc Renaissance in Miami Beach!
Hot off the press is the new xChange13 brochure with full agenda and details of all 70 breakout sessions. You’ll find abstracts for the technical sessions, industry trends presentations and customer case studies.
Here are the hot topics that will be discussed during xChange13:
Last week we looked at the crazy things people insist are the lore of Release Management. This week we continue to highlight so called “truths” and debunk them. My goal here is to put you in charge of determining what Release Management is. After all, you’re the one on the hook for making it happen!
5: Not every change needs to go through the release management process – wrong!
Every change needs to go through some process of verification (testing) and approval. However, it doesn’t necessarily mean that every change goes through the same process. Emergency fixes need a fast-track process with minimal stage gates and approvals. Major releases need more rigorous processes and complete stage gates.
4: A release management infrastructure will slow down my project – wrong!
Imagine if there were no air traffic controllers (ATC’s): would the free-for-all that ensues be good for on-time departures and arrivals, would it be safe, would stakeholders be happier, would it be quicker? Of course not. In fact, the point of ATC is to improve the throughput of flights to maximize the use of the runways. The same is true of release management. Without the infrastructure in place, you will never be able to deal with the volume of changes, the complexity of the dependencies between releases and the competing needs of the many stakeholders. With the right release management solution, you can increase the number of releases you deploy, improve control and governance, eliminate errors and downtime and do it with fewer resources.
3: We cannot make our releases any smaller – wrong!
A major reason why release management has become more complex is because the size of the releases has increased to a point now where they are often bigger than the original system they are based upon. This size means that the releases are very difficult to test and the inter-dependencies of other changes in other projects in the release make it nearly impossible to have any confidence in the testing outcome. Many organizations are taking a leaf from the Agile-playbook and moving to smaller, incremental releases more often. By breaking the release into dependent and non-dependent changes, it improves the testability of the code and the deployment is no longer held up waiting for other changes. Also, moving to thematic releases, keeping the changes to a small area of the code base, improves the ability to test and deploy with confidence.
But many more releases cannot be achieved without automated infrastructure in place. One release manager told me that they were moving from 4 releases per year to 3 releases per year because “it is taking too long to test and deploy.” When I asked the business what they wanted, they told me “more stuff sooner.” The answer is not bigger releases less frequently; it is smaller releases more often. And that is only possible through automating release management processes.
2: The business wants us to change things less frequently – wrong!
No they don’t. What they want is that the changes are deployed more successfully. Think about your smart phone: you get updates every day; you have become the release manager on your own device. You now update without caring because you know the changes are small, unlikely to disrupt the functioning of your device and are, in short, safe. We need to get the business to have that same confidence in our releases. Small changes more frequently are easy for users to absorb, have a smaller impact, require little (if any) training, are easier to test and, generally, low risk. The business gets to prioritize the changes they want and constantly adjust those priorities almost up to the point we put things into production.
1: Developers won’t accept not having access to production– wrong!
With the requirement for the “separation of duties” now being the law, the very idea of anyone having access to the production area seems very 20th century. Still, in many organizations, for whatever historic reasons, many people have access to the production areas and they use this privilege wisely and carefully. But the time for this has to stop! Now! As we have seen, the addition of a layer of process automation improves the speed of the release process and improves the audit trail. In an emergency outage situation, the first question anyone asks is “what changed?” Unapproved changes, even those with the best of intentions, are often undocumented changes. Even if they are not the cause of the outage, the inconsistencies they represent hinder and delay the analysis and remediation of the problem. If someone needs access, then ensure there is a process to let them have it, with appropriate approvals and a mechanism to withdraw it when the need has gone away.
I hope you have enjoyed some of these thoughts. Please share your own debunking examples of the “rules” of release management.
Getting home from xChange13, Serena’s global user conference from September 16-18 in Miami, and telling your team that you got a “Douggie” might raise a few eyebrows. So it would be better if you used the official name: “The Serena Innovation Award.” These awards are presented every year to customers who have taken their Serena solutions to new levels of use that far exceeded what the Serena engineering team thought possible.
To win the award we are looking for three things:
This year we are hoping that our founder and inspiration, Doug “Douggie” Troxel, will be presenting the awards.
See you in Miami for a rewarding and awarding time!
At least you can never say Release Management is boring! Wherever we turn today someone is ready to deliver an absolute truth about the subject. The reality is that Release Management cannot be defined in general terms; it cannot be bounded, except by actual practitioners. There is no hard-and-fast rule about any aspect of it. Yet we are all bombarded with strictures commanding us to do, or be, some idealized version of a Release Manager.
Here are my top ten myths (five this week, five next week) that I seem to spend most of my time debunking these days.
10: One process fits all – wrong!
“We need one process for all release management!” is the guiding principle of so many organizations that are trying to implement a modern release management infrastructure. The reality is that there needs to be many processes:
9: You need one repository – wrong!
Apart from the sheer impracticality of the statement, anyone who suggests that you can only do release management if there is one repository is just not trying hard enough. Of course, having one repository is easy to say – it’s just not easy to do. Migrating all your code from the developer’s repository of choice is error-prone and usually results in unwanted compromises over things like how many revisions can be kept. Retraining the team is expensive and re-tooling the team can be prohibitively costly. What you do need is the ability to coordinate the activities of the teams, irrespective of the repository they use. You need to be able to move the code from their repository to the test areas repeatedly and automatically and safely deploy to production. You don’t need to disrupt your development organization and spend money on solutions they will resent using.
8: You need one solution from one vendor – wrong!
No one vendor has the best-in-class solution for all of your release management needs. Who has the best repository technology, the best parallel development capabilities, or the best support for Agile or DevOps? These will always be a matter for conjecture and disagreement, of taste and negotiating skills. The point is that an organization needs to select the best tool for the job and needs to make sure all vendors’ tools work together. But beware; vendor-created, point-to-point, integrations are fragile. Ensure your vendor is exposing their API’s through web-services and that their integrations support your process, not their own.
7: Project status meetings are essential – wrong!
Project meetings are a monstrous waste of time and resources. One customer describes the weekly release meeting as their “million dollar meeting” as it requires 70 members of staff, including several very senior members, to be in attendance for more than 4 hours. Each person gets to speak but it is often little more than “I’m good.” Imagine the time and money that can be saved by eliminating meetings alone through the use of a good process-centric workflow tool that guides everyone on the team through their part of the overall process. Status meetings can now become about exceptions and only involve the stakeholders who are impacted by those exceptions. So, when you get a meeting invitation, we encourage you to just say ‘Decline.’
6 (and a biggy to end this week’s list): Release management is just about deploying the code – wrong!
Well, actually, that is called “deployment.” Release management has many definitions with regards to the scope of the lifecycle that it covers. One useful definition says that release management begins when the release is given a name and ends when the name is no longer used. For example “the fall marketing release” might start in planning long before any code is checked out or worked upon. Nonetheless, it now needs to be tracked, deployment windows identified in the calendar, the resources applied and so on. Whatever your definition of release management, your infrastructure should support your lifecycle from when you define the start point to where you define the end point. Don’t be sucked into some vendor’s definition.
Next week we will look at some more infamous myths about this most critical of topics.
Englebert Humperdinck sang “Please release me, let me go” in 1967. Some might say it is the anthem of xChange13, Serena’s global user conference from September 16-18 in Miami. While Mr. Humperdinck’s iconic silk shirts and Zapata mustache would be at home in Miami Vice, don’t expect to see me emulating his style at xChange13.
I will, however, reprise the refrain from his number one UK hit. Release management is at the heart of what we do every day. We are either preparing for a release, deploying a release or managing the consequences of the release (good or bad). We see numerous customers facing an increasing backlog of releases stacking up and business owners asking for their releases to be, well, released.
So “please release me, let me go” may well be the conference anthem.
On the xChange13 main stage we will hear from a number of important speakers with much to say on the subject:
Perhaps we’ll leave the conference singing Mr. Humperdinck’s 1970 hit, “We made it happen.”
If you promise to register today I promise not to sing in Miami.
In January, our new CEO, Greg Hughes, asked what would be the most significant change we could make to how the company is run. The resounding answer came back: “Focus!” As so, in February, we created the new role of Product Officer in the company. All five product officers will be at xChange13, Serena’s global user conference from September 16-18 in Miami:
Each of us is tasked with making sure all the activities of development, support, marketing, sales, services and education for our product lines are working in the most efficient way possible. We are your champions internally; we drive your ideas and needs into the team and guide and direct them on your behalf.
The Product Officers are taking a keen interest in the breakout sessions at xChange13 and helping shape the content. They will be there to answer your questions and listen to your advice on where the industry is headed and where Serena should follow.
Contact us today if you have questions or if you want to meet up with us in Miami.
I am told that the room block at the hotel is filling fast. So be sure to register soon.
Serena xChange13, global user conference from September 16-18 in Miami, is where you can meet our leadership team and ask the tough questions that have been on your mind. Talk to any or all of the following executives:
In addition, we will have product team leaders in full force, including the Product Officers, Product Managers and Project Leaders for each of the product lines.
We encourage you to sign up for a 1:1 session with Serena experts in the AnswerZone. As you’d expect, Serena technical team members will be there in their white lab coats (we are looking for Miami Vice lab coats with shoulder pads and cut-off sleeves this year). The AnswerZone is the most popular feature of xChange: it is the place where you can work closely with Serena developers, support engineers, pre-sales specialists and consultants on the challenges you face.
To meet with a Serena expert in the AnswerZone do any one of the following:
Registration for this year’s conference is at an all-time high. So, make sure you book soon, as space in the conference hotel is limited.
See you at the beach, South Beach that is.
They say that if you get enough chimpanzees together and give them access to enough computers, eventually they will make a Software Change, Configuration and Release Management solution as good as ChangeMan ZMF. I am not sure I can wait that long and I’ve seen how “Planet of the Apes” turns out. Of course, if you don’t have anyone working on improving your SCCM & RLM solutions, you’ll never keep up with the ever fascinating world of change we all live in. I can assure you that Serena’s development team is very busy.
In fact, they’re even busier in preparation of xChange13, Serena’s global user conference from September 16-18 in Miami. When xChange comes around each year, members of our development team vie for a ticket to attend. It is a very hard competition, indeed. With so much talent, all with some new and exciting technology to show off, selecting the dozen or so to attend is difficult. This year the contest is heating up, with developers eager to be the first to reveal the latest secrets from the Serena labs.
For our mainframe customers, there are some sensational new capabilities and critical advances in the areas you have been pushing for. The mainframe team will be there in force to answer your questions and immerse you in the improvements and progress we’ve made across the product line. Check out the complete list of mainframe breakout sessions.
See you in Miami, with shoulder pads, turned out collars, and a pocket-protector! If you haven’t yet registered for xChange13, do so now before the Early Bird Pricing expires on June 3.
One way or another, we are all involved in building the content of the release, getting the release ready, putting the release out there, and taking care of it when it gets there. The major theme of xChange13, Serena Software’s global user conference from September 16-18 in Miami, is all about what it takes to be a world-class software release organization.
We are going to have expert speakers from the world of DevOps and IT service management, including Pink Elephant EVP George Spalding (Twitter: @gspalding11). We’ll take a deep dive into the best practices we can glean from ITIL’s Service Transition with one of the best speakers you will ever hear. And we will hear from your peers and colleagues that have implemented Serena Release Management solutions in their organizations and delivered massive benefits and success.
From the R&D side, our development teams will be showing off their latest innovations that will take release management to the next level on every platform from the mainframe to mobile and from the data center to the cloud.
As always, we will be acknowledging our customers for their innovation and excellence. If you have a good story to tell and want to receive recognition (and bragging rights back at your office), please give me a call (+1-650-224-1691 Pacific Time) or write to me at email@example.com (any time!).
See you in Miami! If you haven’t registered yet, there’s still time to take advantage of the Early-Bird Pricing. Register now!