On January 12th, I co-presented a webinar entitled “Industrializing Agile Software Delivery with ALM 2.0+.” I presented alongside Dave West, Vice President and Research Director, Forrester Research and Michael Loetzsch, Chief IT Expert, Deutsche Post DHL. In the session, Dave discussed why ALM 2.0+ is vital for implementing agile software delivery and DevOps, and the differences from the traditional ALM approaches and ALM 2.0+. I described some big shifts and trends we are seeing in the market towards i) agile/mixed process development, ii) the integration of the development and operations IT processes and organizations (i.e., DevOps), and iii) the move towards hybrid cloud development and deployment. I also described a practical tool and process “blueprint” based on years of work with our clients that enterprises can employ to drive global agile software delivery across their company. I finished by stating how this blueprint has been utilized by our enterprise clients to realize some pretty incredible IT return. The following gains are our clients value feedback, not ours…
- Reduce IT ops budget 20 – 50%
- Decrease TTM by up to 70%
- Improve dev productivity up to 20%
- Achieve enterprise compliance
- Migrate projects in minutes/hours
Michael wrapped up the presentation and shared key factors on how teams like yours can gain faster time to market and IT operations cost returns by implementing DevOps utilizing hybrid development and deployment tools and clouds similar to those techniques Michael and his team employed at Deutsche Post DHL. You can learn more about Deutsche Post DHL’s experience by reading the casestudy.
During the webinar, we encouraged our attendees to interact with us by participating in polls and by entering questions for the live Q&A session that we had at the end of the presentation. We received many questions that we just couldn’t get to during the live event. So instead, we’ve provided answers to the audience’s questions at the end of this blog.
If you missed the session live, you can watch the recording and download the slides Dave, Michael and I used. For more information about this topic, please visit our website where you can access additional webinars, informative assets, and free product downloads. CollabNet offers multiple webinars a month that cover a variety of topics related to software development. We invite you to visit the prior recorded sessions as well as to join and participate in our upcoming webinars.
As always, thanks for participating, and I look forward to your continued feedback. In the meantime, as promised, here’s the follow up to the live audience questions.
Q: How common are daily releases into production? Any recommendations on types of applications especially well (or poorly) suited for frequent releases?
It really is a function of a variety of factors. You must consider your business goals and objectives. Do your users need daily releases and will it help you drive your top line and user satisfaction or is this just simply a technique you want to employ pre full scale production to accelerate schedules and quality? What’s your application deployment target – packaged, web, server, embedded? Are you targeting an internal or an external cloud and what’s the surrounding infrastructure and management environment? How experienced is your team – have they done this before? How mature are your team management, development processes, and tool chain – do you even have the team and processes to practice this kind of cutting edge agile development? Interestingly enough, 48% of the webinar attendees polled cited that they would be employing continuous delivery by the end of 2012. In my experience, it’s clear that most of the applications that are utilizing continuous delivery are web apps that utilize automated build, test and release practices, often times with automatic rollback. There’s many reasons why these applications are leading the way. For instance, as opposed to paged software, there is unfiltered visibility into the app by the dev/ops team, there is only one version of the app to maintain, users are used to more frequent updates, etc.).
Q: We are struggling to come to a conclusion as to who should “own” bridging business with IT. Should that be a the business analyst, or the project manager? Somebody else?
Typically that should be a dedicated person, somebody like a “product manager / product owner”. A product manager owner needs to assume responsibility for the actual delivery of useful applications. They would be responsible with working with business analysts and end users to understand the requirements, help prioritize release requirements for each iteration, and drive towards productization. As part of that, close collaboration is essential with all parts of the organization, including business, engineering and operations.
Q: On one of the slides you mentioned Git. Does TeamForge now support Git?
Absolutely. Since 2011, TeamForge has supported Git, a fast growing distributed version control system. TeamForge enables enterprises to harvest all of the benefits that Git has to offer such as the ability to leverage WAN speeds, peer-to-peer release models, and other features that the Git community enjoys. However, enterprises are concerned about Git as it tends to drive a development model whereby each Git repo owns its own version of the release. As a result, at the enterprise level, used in a standalone manner outside of the governance framework of TeamForge, Git can compromise IP governance, traceability, security, and long-term / cross-team productivity. The TeamForge management features and centralization allow for individual development teams to utilize Git, but then provides the ability to integrate decentralized Git repos back to a main Git repo to centralize administration, governance, release automation, etc. As a result our enterprise clients are rapidly integrating their Git repositories into TeamForge. If you are interested in learning more, click here.
Q: Great presentation! Question on “community architecture”. How should we approach commercial communities differently (if at all) from open source communities?
Software development is by definition a social activity, highly leveraging interaction within a community. A main principle and practice of open-source software development is peer production by bartering and collaboration As such, there is lots of learning that can be applied from open source communities. Effective collaboration around software is critical – so the common access to shared assets (software, artifacts, discussions boards, wikis etc.) is imperative. The primary key difference between open source communities and commercial communities is that of security and control. Commercial communities generally are more strictly gated against external access. CollabNet TeamForge has embodied these community collaboration features since our inception in 1999, but we’ve also understood the need for “private” projects/communities and “shared” projects/communities as well. As a result, we built a rich set of roles-based-access-controls into TeamForge that enable individual projects or groups of projects to select the right level of access appropriate for their specific business and community goals and objectives.
Q: At Deutsche Post, did you “start small” or roll that out immediately to the entire company?
An initial pilot project lasting nine months and covering five key projects demonstrated that TeamForge had the right mix of individual team enablement (e.g., allowed teams to integrate in many of their favorite point tools into the platform, allowed them to implement a specific type of agile process, etc.) while at the same time providing enterprise wide oversight and governance (e.g., enabled the “right set” of agile processes to be codified into TeamForge “templates” that could be instantly provisioned and used by the on boarded teams, which further led to enterprise wide level consistent metrics, and IP sharing.) This blend of development team empowerment and executive governance/reuse convinced DP senior management to implement TeamForge as the standard ALM platform across Deutsche Post’s MAIL division. With that foundation in place, DP could now migrate in new teams in minutes and hours, which quickly grew to an enterprise implementation in which thousands of engineers at >100 companies were collaborating on 100s of interconnected applications.
Q: At DP, besides Amazon, do you use other hosting / cloud providers? How did you go about choosing them? Can CollabNet host TeamForge?
Per the diagram below, our Deutsche Post DHL team implemented a hybrid development and deployment cloud approach. For instance, Deutsche Post utilized TeamForge build tools to elastically provision Amazon EC2 test and build servers, while also utilizing a combination of TeamForge / HP Server Automation and T-systems to perform release automation and promotion of production applications. The DP strategy is to let the development teams select the right development process and target clouds for that business and technology needs at each step of the application lifecycle. Regarding the hosting part of your question, CollabNet does host TeamForge, ranging from instant-on SaaS provisioning in minutes to enterprise wide installations with 10′s of thousands of users in a single tenant architecture. Instead of hosting TeamForge in CollabNet’s data center or on-premise in Deutsche Post’s data center, Deutsche Port instead decided to host TeamForge within the T-Systems data center.