REPLAY OF EXPERT VIRTUAL PANEL

CPrime hosted virtual panel with top SAFe/DevOps leaders in the industry: Zubin Irani, CEO of cPrime; Ken France, CEO of Blue Agility; Brandon Cipes, VP of DevOps at cPrime, & Dr. Steve Mayner, SPCT & Senior Consultant at Scaled Agile. Wednesday, Aug 16 at 2 pm ET.

Scaled Agile recently announced a more formal integration and stronger focus on DevOps and Continuous Delivery in the most recent 4.5 release of the SAFe framework – more specifically a “CALMR” approach to DevOps. C – Culture. A – Automation. L – Lean Flow. M – Measurement. R-Recovery. Is it just another acronym I need to learn? Is it any different from the way I develop and deliver? What does it really mean in real-world implementations?

In this Web Event, you will learn: The underlying value of the acronym! How our partners define and implement each one of the values; the successes and challenges they’ve encountered in real-life; and opportunities stemming from DevOps & Continuous delivery when done right.


If you’re looking to amp up your flow of value delivery to your end customer via DevOps strategy and continuous delivery, join us Thu Jul 13 @1ET – with Dean Leffingwell and Ken France.

REGISTER HERE

The recently announced SAFe 4.5 introduced and refreshed many capabilities and represents a major milestone for this proven and successful framework.

Two of the major focus areas are DevOps and Continuous Delivery. These crucial capabilities ensure that your organization delivers “the last mile”, the working software to the business, in an efficient, cost-effective & repeatable way.

Join us for this Web Seminar to hear Dean Leffingwell, co-founder and chief methodologist at Scaled Agile, Inc., and Ken France, CEO at Blue Agility, explore some of these enhanced capabilities and share some real-life examples of how DevOps enables the organization to continuously define and deliver solution elements to the end user that ultimately lead to superior business performance.

If developing at scale is something you are considering and you want to learn how DevOps can accelerate time to value to your customers, or if you’re already an experienced SAFe practitioner and want to come up to speed on these enhanced developments to the Framework, we would love to have you join us.

REGISTER HERE

PRESENTERS


Dean LeffingwellDean Leffingwell
Co-founder and Chief Methodologist
Scaled Agile, Inc.

Dean Leffingwell, a 40-year software industry veteran, has spent his career helping software teams achieve their goals. A renowned methodologist, author, multi-entrepreneur, consultant and executive, he has founded multiple software companies.

His current project is the Scaled Agile Framework, a public-facing knowledge base of proven best practices that bring the benefits of software agility to the largest software enterprises. He currently serves as both an independent consultant and Chief Methodologist at Scaled Agile, Inc., which he cofounded in 2011.

Ken France

Ken France
CEO
Blue Agility

Ken France has more than 22 years’ experience helping large-scale organizations adopt iterative and incremental development practices such as RUP and Agile. As CEO of Blue Agility, he helps develop and implement corporate strategy, provides executive level coaching for our clients, and works with and across all Blue Agility departments to ensure overall Client Success.

Much of his career has been spent directly coaching Agile teams and their management chain on how to drive the change necessary to become successful at the enterprise level, while recognizing the uniqueness of each environment and what trade offs need to be made to achieve that success. He is also the first US minted SAFe SPCT.

 


The As-Is DevOps Value Stream Mapping

Value Stream Mapping is a crucial step in assessing an organization’s DevOps capability. The objective of mapping a DevOps value stream is to eliminate wasteful waiting and improve the completeness and accuracy of all activities in the value stream. We create a value stream map of the software development lifecycle early in any DevOps engagement.

To understand and expose those wastes and inaccuracies, the first step is, naturally, to map the as-is state of your organization’s software development and operations.  Such mapping typically starts with a two-day session involving business and IT staff to capture the major activities involved in software development and operations.  The figure below shows an example of a value stream map (VSM) of as-is DevOps activities.

Legend:
%C/A: For a given VSM step, this is the percent of Complete/Accurate work items received from the previous step in the VSM.
LT: Lead Time for a given VSM step, i.e. from the instance a work item leaves the previous step to the instance it leaves this step towards the next step.  LT includes both idle time as well as time during which the item is being productively processed.
VA: Value Added Time, which is only the time during which the item is being productively processed.
Determining the above metrics in the as-is map will guide the desired improvements later when mapping the to-be DevOps process.

The following are the type of questions that would help a group of business and IT staff convene to produce an as-is DevOps VSM. The questions are not meant to be walked-through in strict order, but can be navigated back-and-forth in the session of drawing the as-is VSM.

  1. What are the main steps involved in the current process of software development and operations? We need to look at the factors that determine the boundaries between those steps, including handoffs, queues, and organizational stipulation.
  2. Who performs each step? Include role names and names of some of the specific people who perform the step.
  3. What is the %C/A for each step? For each step in the Value Stream Map, capture the percentage of work items that arrive at the step being complete and accurate. To get a realistically representative value of this metric, you may have to capture an average of it over several weeks, or even several months.
  4. What is the LT for each step? As with all metrics of Value Stream Mapping, to get a realistically representative value of this metric, you may have to capture an average of it over several weeks, or even several months.
  5. What is the VA time for each step? The VA excludes waiting time (e.g. being on a queue) or any other non-productive time experienced by the work item.
  6. What tools do you currently use for each step? Answering this question would help uncover manual steps that can be automated, determine opportunities for integrating various tools, and improve efficiency and accuracy of automated steps.

The To-Be DevOps VSM

Once you have the as-is DevOps VSM mapped, the to-be DevOps VSM is driven by the following:

  • How can we significantly increase the %C/A for each activity in our as-is VSM?
  • How can we dramatically reduce, or even eliminate the non-productive time in the LT of each as-is activity?
  • How can we improve the performance of the VA in each as-is activity?

Answering the above questions can lead to drawing a new, to-be VSM with realistic, but sufficiently challenging, new targets for each of the above three metrics: %C/A, LT, and VA for each activity in the new, to-be VSM.  Such to-be VSM will usually encompass activities that do not correspond 1-to-1 with the activities on the as-is VSM.  The following is an example of such to-be DevOps VSM:

Mapping Your DevOps Value Stream

Our Blue Agility DevOps coaches can help your organization with:

  • Guidance for detailed answers of the above listed questions for drawing the as-is DevOps VSM.
  • Templates for capturing comprehensive information for each as-is / to-be activity.
  • Assessment to determine which of the activities shown in the above to-be example VSM are suitable for your organization.

_________________________________________________________
Ali is a senior consultant at Blue Agility. He performs strategic services to key customers in order to accelerate achievement of business goals by leveraging the benefits of process mentoring and automation through tight integration with business critical processes. He works with customers to identify the Key Performance Indicators (KPIs) that are critical to business success. He is SPC4 certified. 


In this blog post, I would like to discuss how DevOps and SAFe work together and are in sync to address the “Three Ways” introduced in the book “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.”

The Three Ways consist of:

  • First Way helps us understand how to create fast flow of work as it moves from Business Vision, to Development, through Operations to the Customer.
  • Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework.
  • Third Way shows us how to create a culture that simultaneously foster experimentation, learning from failure and understanding that repetition and practice are the prerequisites to mastery.

In the Phoenix project, the CFO of the company is asked what exactly is your role?  His answer, “I own planning and operations across the entire organization.”  He is then asked “what are your goals objectives and measurements for this year?”  He replies with a list that he looks at every day.  What if you could have that conversation with your senior executive and what would you ask?

In DevOps, the voice of the customer is used to help set the vision for the company.  That vision is in turn used to set priorities within the business areas.  These priorities are then used to establish Epics and Stories to be worked on by the team ensuring alignment and synchronization.

SAFe is a proven public facing framework for applying lean in agile practices at an enterprise scale.  It is comprised of a Portfolio, Program and Team level.  At the portfolio level, strategic themes connect each software portfolio to the enterprise business strategy.  This is a way to ensure the priorities of the senior executives and the work of all teams are in line.

Both DevOps and SAFe align with the First Way.

The First Way

In line with the Second Way, DevOps stresses the importance of Feedback Loops throughout the entire Software Delivery life cycle.  Not only in development but as code is released to production, receiving feedback from the operations area, with proper monitoring, is critical.

SAFe also introduces Feedback Loops across the three levels of Portfolio, Program and Team.  At the Portfolio level, a Kanban system drives feedback amongst the key stakeholders for Epics.  At the Program level, a Kanban system is used to provide a planning cadence for feedback, alignment, synchronization and assessment for Features.  At the Team level, the Kanban system is used to provide feedback, prioritization and alignment for Stories.  The team will use those Stories to discuss, collaborate and use feedback to determine the tasks needed to complete the work within plan sprints.

As you can see, the Second Way is a crucial piece of both DevOps and SAFe.

 

Second WayAnd finally, in the Third Way, both DevOps and SAFe strive to create a culture of experimentation, learning/gaining knowledge for trail and error and understanding repetition/cadence in order to master the art of software delivery.

In DevOps principles of Lean are present.  Understanding the ability to Shift Left via Continuous Testing, Service Virtualization and Continuous Integration provides earlier identification/addressing of defects that lowers cost and reduces cycle time.  This in turn eliminates waste which saves money.  These techniques allow software to be developed to a high standard, easily packaged and deployed to test environments.  Resulting in the ability to rapidly, reliably and repeatedly push out enhancements/bug fixes to customers at low risk and with minimal manual overhead.

In SAFe the House of Lean, is based on the foundation of Leadership.  A key component in this foundation is: a leaders ability to develop people because people develop solution.  To be a leader that is a developer of people is to increase engagement, motivation and produce high higher quality solutions.  Leader must also take a Systems view.  They should look to optimize the whole system and not the parts.  If the Leaders, can’t change the system, who can?  Finally, building a learning organization that emphasizes lifelong learning and fosters decentralized decision-making is crucial to be aligned with the Third Way.

Third Way

I ask each of you to look into these two Software Delivery methodologies and see the synergy that they can create to help you improve your software delivery successes!


Are you challenged with collaboration in your organization?

Collaboration

Whether you are dealing with teams collaborating in the same location or virtual teams across multiple locations, see how leveraging DevOps can help.

Virtual team collaboration is the collaboration of teams that are not located in the same physical location. These teams could be either on-site, near-shore, offshore or a combination of the three types.

DevOps focuses on improving the principles of collaboration including:

  • Voice of the Customer
  • Just in Time Requirements
  • Refinement
  • Social Interaction
  • Transparency
  • Demonstration
  • Fast Feedback

“Coming together is a beginning; keeping together is progress
working together is success – Henry Ford”

So how do you effectively collaborate with DevOps?

The key is to enable effective collaboration at the three following layers:

Team Collaboration: DevOps builds on the concept of small teams working together to do great things!

Team Collaboration

Team of Teams Collaboration: A group of teams working in cadence and synchronizing often.

Collaboration

Intent/Idea Collaboration: Alignment to ideas/concepts that have been identified, analyzed and approved for delivery.

With the challenges of collaboration, tooling to support them is critical!

Whichever tool you choose, it must have the ability to deliver collaboration for all of the three layers described above to truly deliver across your entire delivery life cycle.

Would you share with us what tools you have used to deliver collaboration across your entire delivery lifecycle?

 


We’ve all heard the latest trends regarding DevOps and SAFeTM, but what’s in it for IT Operations Directors/Managers?

Technical Debt

Let’s say you’re an Operations Director or Manager, with several Production Support teams. You know your organization has Technical Debt in production, but how do you address this?

Technical Debt can be caused by a production solution that has not been maintained (i.e. patches applied) and has become unstable or requiring high levels of support. In some cases, this technical debt could result in frequent reoccurring incidents causing outages and/or reputational risk.

You can’t be in debt and win. It doesn’t work.” David Ramsey

Another cause of Technical Debt is a solution that has reached end of life, and for which no additional investment has been approved. Although a new architecture pattern exists to support the solution, how do you address the challenge of having your organization migrate to the new pattern with the shortest lead time?

The answer can be found in the Scaled Agile Framework (SAFeTM), which leverages the benefits of DevOps!

SAFeBigPictureblog-300x231SAFeTM consists of three levels: Portfolio, Program and Team.

These three levels provide transparency and traceability for Technical Debt:

Portfolio Level

Technical Debt can be identified and analyzed at the Portfolio level by establishing an Architecture Epic.

Portfolio Level

© 2011-2015 Scaled Agile, Inc. All rights reserved.

Program Level

Technical Debt can be forecast for implementation at a Program level (via a Program Roadmap) within an Agile Release Train leveraging DevOps teams.

SAFe Program Level

© 2011-2014 Scaled Agile, Inc. All rights reserved.

Team Level

New solutions can be delivered by Agile Teams within their Sprints.

Team Level

© 2011-2015 Scaled Agile, Inc. All rights reserved.

As the Operations Director/Manager, you know where your organization’s Technical Debt lies. By leveraging Architecture Epics within the SAFeTM Framework and DevOps, you can finally address Technical Debt with the support of Agile Teams!

Food for thought!