The Implications of DevOps for Traditional Project Managers. Q: What is the minimum number of days/weeks between releases?

Transcription

1 PMI Webinar Q&A: The Implications of DevOps for Traditional Project Managers Q: What is the minimum number of days/weeks between releases? A: There is not a minimum number of days between releases. Moreover, there are many release strategies that may apply in different situations: 1. Release on the program cadence. The simplest case is when an enterprise can release on the Program Increment (PI) boundaries. All release dates are known in advance and PI planning, releasing, and Inspect and Adapt (I&A) are coordinated by the same cadence and calendar dates 2. Releasing less frequently. In many cases, however, releasing on a fast PI cadence may not be possible, or even desirable. Even if the customer would like to have the new software, the service level and license agreements may be prohibitive. And then there is the overhead and disruption of installation. In these cases, releasing on a PI cadence may not be practical, and the planning and releasing activities may be completely decoupled. 3. Releasing more frequently. For many, the goal is simply to release as frequently as possible hourly, daily, weekly, etc. Achieving that requires the right DevOps capability, an effective Continuous Delivery Pipeline, and an architecture that supports incremental releases. 4. Release on demand. Big systems are not homogeneous. They contain different types of components and subsystems, each of which may leverage its own release model. In that case, the most general model is: Release whatever you want, and whenever it makes sense within the governance and business model of the enterprise. Read more at: Q: Is there value in implementing DevOps into an industry that is typically resistant to change and likes one release a year (e.g. banking or air travel)? A: Yes. Any industry, including airlines and banking, are vulnerable to digital disruption and should begin a Lean-Agile journey that includes DevOps. It's critical that these efforts are started now. There are still benefits to implementing the foundation for DevOps, such as Built-In Quality practices, becoming Lean-Agile, automation for testing, building infrastructure, deploying and releasing new value.

2 Moreover, releasing should not be a monolithic, all-or-none process. If so, the release strategy would be limited. Fortunately, that s not the usual case. In fact, even fairly simple solutions will have multiple release elements, each operating on different release strategies, as Figure 3 illustrates in this article: Q: How do you implement DevOps in situations where you have multiple upstream and downstream impacts? Often times I find projects I'm on are delayed even for a small change, because we're waiting on another technology group to be ready. A: Waiting is expensive as well as wasteful. We use good architecture to ensure dependencies are minimized. When that can't be avoided, we will use tools such as feature flags and mocking frameworks to ensure the value continues to flow through the pipeline without external dependencies. This is quite common for large enterprises where the dependencies might be spread across teams, time zones, and continents. As such, the continuous delivery pipeline must implement good DevOps practices and good architecture to ensure seamless integration of new code and hardware without injecting a delay or disturbing the flow. There should never be a pause in the continuous delivery pipeline due to a dependency. Refer to the webinar recording for additional information. Q: How do you recommend changing the organizational culture, such as in a large Government Agency, in order to eventually implement SAFe? A: I would suggest referring to the SAFe Implementation Roadmap, which consists of an overview graphic and a 12-article series that describes a strategy and an ordered set of activities that have proven to be effective in successfully implementing SAFe. It's also proven to be effective for Government Agencies. Read more at:

3 Q: If value stream teams persist over project boundaries and are focused on delivering product increments as fast as possible, is it not true that the Agile Project Manager does not really exist? A: In SAFe, we don't have projects, as they are not a continuous flow construct. Projects are a start-stop-start-stop paradigm. The closest thing we have in SAFe is an Epic. Epics can and generally do cross value streams, which are managed within the SAFe construct by ARTs or Solution trains. In SAFe, there is no role called Agile Project Manager. Nor is this role called out in the Scrum Guide. However, project management as a task, and those same skills (especially soft skills), are still used throughout most (if not all) Agile frameworks. Q: Can you give an example of telemetry for stakeholders? A: A/B testing is an example of telemetry for business stakeholders. For example, it compares two versions of a web page to see which one performs better. You compare two web pages by showing the two variants (let s call them A and B) to similar visitors at the same time. The design that provides a better conversion rate, wins. Other examples include: adoption patterns when new features are deployed, is the feature visible and discoverable, performance of the new features, or impact to current performance. How customers are engaging with your app How successful and engaging are the various features What s going on when crashes happen or non-crashing errors such as failed HTTP requests, failed syncs, and timeouts. Q: How do we implement SAFe for a customer who has a hybrid Agile (Agile with Waterfall) framework? How do you introduce lean in this? A: While not a recommended approach, please refer to the SAFe guidance article on mixing Waterfall and Agile at scale: Q: I missed out on the first session, it is my understanding that DevOps is a new and simple approach used to move from the traditional approaches. In this regard, how can we get to use the new applications effectively?

4 A: It depends on your definition of new. It is a phrase that was [first] publicly mentioned in The approach is indeed simple, however implementation is often difficult due to the change in mindset required. In our talk, we showed a very detailed slide about moving from traditional methods to Lean-Agile methods featuring DevOps. The application of DevOps starts with the mindset shift with an emphasis on quality and smaller batch sizes. From a team level, we would encourage the use of extreme Programming (XP) principles and implementation. From a system perspective, it would be a good idea to model the flow of value delivery through the pipeline (i.e. dev.-test-stage-prod.), measure the lead time (we displayed a Cumulative Flow Diagram), and work on reducing the lead time through the pipeline. Most tools that enable and measure this flow are free. Q: What if the changes that you're trying to implement are dependent on a specific upgrade? If your user stories/requirements were written when you were assuming a specific version of the application you're using, by the time those upgrades are released several times, your requirements may no longer be relevant. How can you avoid that? A: This is a quite common scenario. It should not be avoided, as change in general is a good thing. It means the customer is getting what they want, instead of what was written some time ago. SAFe has many mechanisms for monitoring risks/dependencies and adapting to changes. Events such as the ART Sync and tools such as the Program Board help us monitor and adapt to changes in requirements, markets, technology, etc. We design our trains to reduce dependency among the teams. When that cannot be avoided we make sure that we are actively monitoring those dependencies. In addition, using DevOps, tools, and good architecture design, we can minimize the impact of changes due to dependencies. Q: What are the top three challenges in implementing SAFe as observed in all the industries? A: The top three challenges are: 1. Cultural change 2. Leadership engagement (not just buy-in) 3. Managing portfolio work in progress (WIP)

5 Q: How can budget approval and change management processes help support SAFe and DevOps? A: DevOps focuses on enabling Agile-Lean frameworks (and vice-versa). Small batch sizes flowing through the system enable quick adaptation to change. Lean-Agile budgeting in SAFe is done by funding Value Streams, not projects or ARTs. Thus, we fund a constant flow of value and deliver small units of tested and integrated value. For example, if we were building a solution that consisted of a car, we might have a braking system Value Stream. We would continue to fund the braking system and deliver features until the braking system was no longer needed. That prevents us from having to constantly approve funding, as we will continue to produce braking system features for the foreseeable future.