DevOps Enterprise Summit 2018 (DOES18) in Las Vegas was a three-day bonanza of all things DevOps, with conversations spanning the entire DevOps ecosystem, from processes to tools to culture. In my two days at the Broadcast Booth (aka “The Fishbowl”), I had the pleasure of meeting with some very smart people and having some highly insightful conversations, all of which are available for viewing on DevOpsTV.
The second day’s conversations at DOES18 were as interesting as the first day’s, with topics ranging from DevOps culture to managing DevOps in highly regulated environments. Below is a recap of the Day 2 video interviews at DOES18 (Day 1’s recap is available for viewing here):
Organizational Change
Carmen DeArdo of Tasktop and Jon Smart, formerly of Barclays Group, stopped by to discuss tactics in ways to make change efforts possible in the enterprise.
Capital One’s DevOps Update
Jamie Specter, Aimee Bechtle and Abbie Gray of Capital One offered the latest updates from legal, tech leadership and product management in its DevOps journey.
Work Management Systems
Scott Prugh of CSG, Keanen Wold of Delta Airlines and Rosalind Radcliffe of IBM discussed how to break down inefficiencies for enterprise practitioners and management leaders who have multiple work management systems that their teams deal with every day.
Project Management
Laura Fay of TSIA discussed a product-led growth strategy where the buyer and customer journey is actively engineered into the product experience to deliver value and outcomes. She also explained how DevOps can benefit from expanding the definition of lead time from ’code to cloud’ to ‘concept to customer consumption’ and become a more integrated part of the business value flow.
The Importance of Culture
J. Paul Reed of Release Engineering Approaches and Dominica DeGrandis of Tasktop discuss what’s important about culture as part of a DevOps transformation journey, and why a DevOps culture should foster an attitude of open-mindedness, cross-pollination of skills and stepping out of comfort zones.
DevOps in Regulated Industries
Robin Yeman of Lockheed Martin and Ken Moser and Melinda Solomon of the U.S. Citizenship and Immigration Services discussed how DevOps can be applied in highly regulated environments and highlighted industry best practices.
Transformational Leadership – Making Change Happen
Christophe De Boeck of Kiwibank Ltd. and Steve Mayner of Scaled Agile highlighted considerations for the different ways to lead transformation in large enterprises.
DevOps Trends – What Does the Future Hold?
In this forward-looking discussion Eric Robertsonof CollabNet VersionOne, Robert Reeves of Datical and Derek Langone of XebiaLabs chatted about what the future holds for DevOps in the enterprise and what to be on the lookout for in the coming year.
It was 6 a.m. Saturday when the phone rang and awoke the American Express CIO. When the phone rings at 6 a.m., it is never good news. Never. This instance was no different: In this case, a third-party supplier just suffered a breach, and that breach would impact American Express cardholders.
Immediately following that call, the CIO activated the company’s Cyber Crisis Response team. The job of the Cyber Crisis Response team is to help identify impacted cardmembers and prepare to reach out and assist any who have questions or need help regarding the breach.
The need to respond swiftly to customers and provide them with the correct information is essential today, not only to stay on the right side of regulators, but to also help customers avoid fraudulent transactions and identity theft. When it comes to such effective data breach incident response, rarely does DevOps come into play—but the experience American Express shared at the most recent DevOps Enterprise Summit revealed just how better DevOps organizations can be when it comes to effective breach response.
Within hours of the initial call between the CIO and the Cyber Crisis Response team, the primary breach response was divvied into three teams. The first team focused on what data breach bridge teams typically focus on: how to identify impacted customers. The second team was comprised of business and product owners, as well as customer care staff, whose objective was to take the findings from the response investigation and communicate them to American Express customers.
The third team consisted of DBAs and system specialists, who understood all the systems, as well as enterprise architects, who might be able to quickly solve any technical challenges that arose.
Getting to the Right Breach Information
By 3 p.m. that Saturday, the first team determined that it could pull together all of the information it needed to identify affected cardholders. That was the good news. The bad news was that there would be tens of millions of production records that would need to be evaluated to make the final determination.
If the team was to pull those tens of millions of records in production, the demand would start to slow those production systems. “How do we pull these records out of production without impacting our availability? That was the challenge,” said Aimee Cardwell, vice president of Engineering, Consumer Product Development at American Express.
As the day moved forward and the teams worked to find a way to access those production records without impacting availability, one of the engineers on the team pitched an idea that would have been scoffed at in most organizations: Why don’t we clone production? But the novel idea wasn’t immediately rejected. The team on the call began to weigh the pros and cons of cloning production, and concluded that it could, in fact, clone production quickly, and all of the impacted card data could be aggregated without negatively impacting American Express’s servers and associated availability.
After the team successfully cloned the production systems, it worked all night to identify the impacted card members, which required cross-referencing the cloned production system with other data stores, Cardwell explained.
“What was really important here was the comfort level everyone had when it came to bringing up an idea that was really off the wall. And, in the end, they came together to make it happen because together the various teams had a string understanding of the people, technologies, and processes in place necessary to succeed,” said Chad Avery, director, DevOps implementation at American Express.
It was now 6 a.m. Sunday and the teams had worked nonstop since the CIO’s phone rang Saturday morning. The teams managed to evaluate the relevant data from various systems and collected a list of potentially impacted card members. And after a careful analysis, they were able to determine who had been affected by the breach and who hadn’t.
What made this success possible? Both Avery and Cardwell believe that it was the integration of business, product and technical teams. “The fact that we had business, product and technical teams working together in this incident was a huge win for us,” Cardwell said.
Avery contended the ability for an organization to successfully integrate its technical, business and product teams makes the difference. If those teams hadn’t been working together from the beginning, he said, they may not have been able to find a solution and, if they had, it would have taken much more time to do so.
Disclosure Day, and a Final Big Win
It’s a good thing it worked out quickly. By Monday morning, the breached third-party was ready to go public with its data breach disclosure. That announcement would immediately impact not just American Express cardmembers, but those of most other credit card providers as well. Many customers would have pressing questions about whether their accounts were impacted, and, if so, what to do.
Customer service lines had to be ready.
That proved to be the final challenge that needed to be solved: How would customer service representatives know which customers calling were affected? Tight team integration and collaboration proved to be a deciding factor once again.
The engineers on the product team had spent the previous 24 hours building a tool that they shared with American Express customer care professionals. When individuals called the customer care team, the tool could alert the team whether a customer was in the impacted group.
The tool also came equipped with a data collection feature that would enable everyone to learn from the event and even prepare better for next time. “We want everyone to get better. We want ourselves to get better,” Cardwell said. “We want to know what percentage of customers who called were impacted, and what percentage of customers that called were not impacted. We wanted to know our response time on those customers. We wanted to know any other data that would help us to do better next time.”
And it will have been that dedication to collaboration among technical teams, business units, developers, operations and security teams that enabled them to quickly and successfully manage a third-party data breach and prepare themselves to do even better next time. “They all were able to develop a solution quickly. They were able to identify the customer impact, design a solution, build it, test it and get it deployed. And, oh by the way, the teams did it in a weekend,” Avery said.
Despite what you may have heard to the contrary, not everything that happens in Vegas should stay there. Take the DevOps Enterprise Summit 2018 (DOES18), for example: The three-day event attracted the best and brightest in the DevOps world—and me—to discuss all things DevOps. Some of those great conversations were captured in a series of video interviews, which are now available on DevOps TV.
During the two days of interviews in our glass-walled video booth, a variety of folks stopped by to chat about topics ranging from audits and compliance to NextGen Ops and the future of DevOps. Below is a recap of the Day 1 video interviews from DOES18 (Day 2’s recap will post next week):
The Future of DevOps
Wesley Pullen of Electric Cloud, Torsten Volk of EMA and Chris Nowak of FlowStates stopped by to discuss the latest DevOps trends, where DevOps is headed, and understand key emerging practices and technologies that are driving success.
Venture Capital and DevOps
Sid Sijbrandij of GitLab, CJ Napolitano of Electric Cloud and Ubaid Dhiyan of Union Square Advisors chatted about the current state of VC investment into DevOps, how this could evolve in the future and the impact this investment ecosystem has on the global economy.
ITSM/DevOps Crossover
IT Skeptic Rob England and his partner Dr. Cherry Vu discussed what holds ITIL back from more successful transformation of IT work, and how we can help it succeed, as DevOps and ITSM finally converge on each other in the common ground of service operations.
‘Dear Auditor’ — Compliance and DevOps
Sam Guckenheimer of Microsoft, James Wickett of Signal Sciences and Topo Pal of Capital One talked about the current state of DevOps and audit/compliance. They are part of a team that wrote a love letter to auditors from DevOps, in which a promise was made to make life better. They also compiled a list of audit concerns and documented them in a DevOps Risk Control Matrix with lot of details around the controls, practices and evidences that are collected to support the control.
NextGen Ops
Damon Edwards of Rundeck, Cornelia Davis of Pivotal Software and Tom Limoncelli of Stack Overflow chatted about the next generation of IT Ops and what emerging patterns and practices teams should consider for the future of IT.
Workplace Burnout
John Willis (Botchagalupe) is passionate about so many topics around DevOps, cloud and technology. One of the areas he is really passionate about, though, is the topic of burnout and fatigue in the IT field. He and Dr. Christina Maslach discussed the concept of burnout and examined the causes and effects of this problem, and the most promising strategies for dealing effectively with it.
Project to Product
Dr. Mik Kersten, CEO of Tasktop, reviewed the transition from project-based work to product-based workflows—the most optimized and scalable DevOps environment will be a highly prized gem for any business only if the product management team is prioritizing the right capabilities into the DevOps process.
Tech for Tech Leaders
Anders Wallgren of Electric Cloud and Erica Morrison of CSG discussed the technology landscape and what things tech leaders need to not only understand from a tech and architecture perspective, but also what they need to know to help build technology and tech platforms for the future of software delivery.
Banking on DevOps
Mark Howell of Lloyds Banking Group, Shaun Norris of Standard Chartered Bank and John Rzeszotarski of KeyBank reviewed a few of the top DevOps journeys in banking and what other financial institutions should consider along their DevOps journeys.
Well, there ya have it: An entire day’s worth of videos compiled for your viewing pleasure. Be sure to check back next week for a recap of our Day 2 video interviews from DOES18 Las Vegas.
“What happens in Vegas, doesn”t stay in Vegas” … a great quote to end the recent DevOps Enterprise Summit 2018 (DOES18) in Las Vegas, urging attendees to take and share the new insights and knowledge gained. This article is an attempt at sharing my discoveries.
This article contains a summary of the challenges that delegates told me about when visiting the GamingWorks stand at the summit. These closely match our global findings, with more than 400 teams having participated in the Phoenix Project business simulation workshop.
This article also describes highlights from the sessions I had time to attend—highlights mostly in relation to the challenges mentioned above, and biased toward toward people, culture and behavior, as this to me is the No. 1 success or fail factor for the successful adoption of DevOps ways of working.
Challenges
I asked more than 100 people, “What is your top challenge or barrier for your adoption of DevOps ways of working?” I have ordered them based upon the number of times mentioned, highest first. Many of these I captured before the opening of the summit:
Leadership:
Leaders applying the “pointy-fingered” approach. “You are now self-empowered. Make IT happen.‘
Lack of “empowerment” and not “walking-the-talk” to foster the right culture.
Not wanting to let go of a “command and control” management approach and fear of becoming less relevant.
Product Management:
The need to shift from a “feature” focus to more “outcome” and “business value” focus.
Product owners “demand” but don”t share why.
Low focus on “technical debt” and “issues” versus “benefits.”
Need higher-level product management (business decision makers) to balance “innovation” with “risks” (e.g technical debt).
Value Stream:
Poor end-to-end visibility (including business “before” and “after” activities).
A narrow focus on Dev and Ops, mostly a Dev “pipeline.”
No impediment backlog visible for the stream.
Too much local optimization.
Value and Metrics:
Too much focus on internal, proxy metrics.
Need more “value” and “outcome” metrics to gain buy-in to scale up.
End-to-End Communication and Team Collaboration:
“Them” and “Us” – lack of trust.
Poor listening and communication skills to explore and understand.
Lack of end-to-end understanding of the business impact and value we are all working toward.
Poor Management of WIP:
Poor balance between types of work, feature vs technical debt, improvements, training and knowledge-sharing.
Engineer disconnect between “what you are working on and the business impact.”
Continual Learning and Improvement:
Not enough WIP reserved.
Poor team ownership and ability to structure this.
No visible backlog of impediments/improvement.
No prioritization of improvements.
Project to Product:
Projects claiming resources.
Product owner resource conflicts and challenges.
Flip-flopping, context switching work.
Buy-in and Resistance:
Why should we change?
Fear, uncertainty, doubt.
Suspicion of intentions.
Managers not wanting to change and lose “power.”
Certainly not a lot of CI/CD or technology stuff mentioned here!
What were some of my highlights as they relate to these challenges?
DOES18: Introduction and Opening
In his introduction, Gene Kim revealed one of the goals of the summit was a need to “Elevate focus on spanning business/technology divide,” which clearly relates to a high-scoring challenge. Another topic in the intro was the need to “upskill,” announcing a new skills research project to be launched. The challenges above and the highlights from the sessions give a clear indication of some of the skills needed. Considering the challenges above, I sincerely hope the survey also focuses on business skills as well. In the “Lean Coffee” roundtable sessions, one of the announced topics was “Transformational Leadership,” clearly linking to the top scoring challenges mentioned. More about this topic in my closing.
DOES18 Sessions
In a session titled, “Product Management Meets DevOps” a key recommendation was to “build and run teams combined with service ownership,” stressing a need “to connect people to your strategy” and declaring “IT cannot be separate from the business,” and finishing with a need to “manage product value streams, not projects.” (This was the only session in which I heard the word “service”). To me, these highlights clearly make a link back to the challenge teams have in understanding business impact and value. These recommendations will require a changing role for product management to ensure strategic priorities are embedded in the value stream, and a more engaged role of product owners in teams to ensure a shared understanding and focus on “outcomes” and “value” in relation to strategy, rather than on features.
Benefit: Enabling the flow of strategic intent
Mark Schwartz explained that almost all large enterprises are faced with “impediments” that are a barrier to DevOps success, and these are usually people and organizational issues, not technology. He introduced his new “War and Peace and IT” book, and explained an impediment faced by Napoleon in his Russian campaign—Napoleon had “long decision cycles.” By the time he got the right information to make a strategic decision, the fast-changing short decision cycles at the battlefield meant his decision-making was ineffective. The same applies to the way we currently manage IT: long decision-making cycles from idea to business case to program and project resourcing while DevOps teams operate at a fast, agile pace. Mark suggested a need to speed up the “entire lead time from idea to impact” (a topic also explored in Mark Smalley’s latest DASA whitepaper, “The Business Value of DevOps“).
Benefit: Enabling the faster flow of strategic intent
Schwartz went on to suggest three ways to build more agility into the end-to-end value stream and delegate decision-making to a lower level: the “product model,” decentralizing decision to the product team; the “budget model,” decentralizing budget to the team to manage both “innovation” and “keeping the lights on”; and the “objective model,” just give the team the key objectives to be achieved and let them decide how to make it happen anyway they can.
This to me represents a considerable mindset shift from the hierarchical “command and control” management paradigm and requires transformational leadership. In my mind, whatever model is chosen needs to fit with the highlight from the previous session, “Connect people to your strategy.”
Benefit: Enabling faster decision-making around strategic intent
Anders Wallgren‘s session, “Measuring DevOps – The Key Metrics That Matter” was standing room only, with a packed audience taking pictures of all of the slides. I must admit to being surprised, as this is the fifth DOES conference and organizations have had five years to put metrics in place! I can only assume the vast majority were just starting their journey. I was pleased to see not just the traditional metrics often quoted such as “deployment frequency,” “lead time to change,” “mean time to recover (MTTR),” and “change failure rate,” but also business value metrics such as revenue growth; customer value metrics such as customer experience satisfaction; team culture metrics such as education and growth; and the pipeline metrics such as release velocity. This was one of the top-scoring challenges facing delegates who visited our table: “Fhifting from internal metrics to business value metrics.” This focus on business value metrics ties in again to the highlight from the first session above, “Connect people to the strategy,” and the important role product owners have in sharing the strategic intent.
Benefit: Enabling measurement of strategic intent.
Dr. Mik Kersten presented “Project to Product: How Value Steam Networks will transform IT and the Business,” suggesting that project management and traditional cost models are the wrong models, an idea supporting Mark Schwartz’s observations. He went on to add, “Fragmented value streams kill personal productivity,” as well as “impact employee satisfaction.” Silos and proxy metrics not related to business value will also destroy a DevOps transformation. He made some powerful arguments for a complete end-to-end value stream (Not just a DevOps value stream).
These messages were further endorsed by Carmen De Ardo in his session, “Connecting IT to the Business at BMW Group,” during which he also stressed, “Flow time is not just code-to-commit but also, and more importantly, idea-to-value.” Carmen also stressed that the “flow to value” is not just the flow of “features” but also “defects,” “risks” and “debts,” which to me represents a need to manage “value optimization,” a balance of “value creation” and a reduction of “value leakage.”
Benefit: Enabling value optimization of strategic intent.
Damon Edwards, in his session “Operations: The Last Mile,” expanded on the theme of end-to-end value streams, with a powerful case about disruption, context switching, waiting, escalations, lack of trust and employee dissatisfaction—all this because of “four forces that undermine operations” that need to be addressed to empower operations:
Reduction of Toil—non-valued repetitive work that can be automated.
Queues, which disintegrate and obfuscate value streams.
Silos, causing disconnects and mismatches.
Low trust—the need for “psychological safety, the No. 1 predicate for success.”
Benefit: Enabling the removal of behavioral flow barriers and waste.
Dominca Degrandis in her session, “Making Connections Visible: How to Defrag Your ValueStream,” stressed, “The hardest thing we do is communicate across teams,” making a call to make connections visible as well as “how the different types of work enters the system, where they enter and which tools are used.” This touched on a topic I discussed with DeArdo at itSMF Fusion: the information value stream.
Benefit: Enabling the removal of end-to-end information and behavioral flow barriers and waste.
One of the most powerful sessions for me was the presentation from Dr. Steve Spear: “Discovering Your Way to Greatness: How Finding and Fixing Faults is the Path to Perfection.” He suggested, “Design all work to SEE problems.” Make this part of a philosophy: “See, Solve, Spread (Share knowledge).” He suggested, don’t ask “How is it going?” Ask, “What is not working, and what can we do about it?” This ties in nicely with a finding from the latest State Of DevOps report: “Relentless improvement work leads to excellence and high performance.”
Benefit: Enabling the relentless removal of barriers and waste and the optimization of strategic intent.
DOES18: A Customer Case
Mascha Boender and Stefan Groot presented an ABN AMRO case, “Crossing the DevOps Chasm: From Taboo to Enterprise DevOps,” in which they discussed their bottom-up journey of experimentation. They designed their approaches to see problems. They admitted failure, demonstrating their learning and how they made iterative improvements. They stepped away from a maturity model to a capability model, recognizing that one size doesn’t fit all teams. They provided a “Moonshot workshop,” focusing on specific team goals and ambitions and how these aligned to business strategic goals. They provided a DevOps playbook (based on captured team best practices) to help new teams develop practices at their own pace. To develop team “soft skills” such as communication and collaboration, they used the Phoenix Project business simulation workshop. This was done also with more than 30 leaders to create a mindset shift and demonstrate the change of leadership behaviors required to empower the teams and foster an enterprisewide culture change.
Benefit: Enabling bottom-up and top-down “skills” and “culture” and aligning team goals to strategic intent.
The State Of DevOps
Nicole Forsgren and Jez Humble presented, “The Data Behind DevOps: Becoming a High Performer,” in which they shared findings from the latest “State Of DevOps” report. I won’t go into detail. I suggest you read the report, then read it again. Suffice to say their key messaging echoed many of the other sessions above: “Focus on outcomes, not output,” the need to “identify constraints and continually improve,” and for me an important topic: “Influencing culture through leadership and autonomy.”
The ABN case above was an example of how they gave teams autonomy to change and how they helped change leadership behaviors.
DOES18: Final Thoughts
As I stated at the start, culture to me is the No. 1 success or fail factor. The “State of DevOps” report stressed the importance of leadership on culture. Leadership was the top challenge mentioned by delegates visiting our stand. I”d like to share with you an article on devopsy.kinsta.cloud on how to influence leadership behaviors: The article is written through the lens of “communication,” tying back to a comment from Dominica Degrandis: “The hardest thing we do is communicate across teams,” and tying in with the ABN AMRO case about developing communication and collaboration skills.
And finally, getting back to the start of the summit and the need to “upskill,” with the announcement of a skills survey, I’d like to provide some input. Here is a DevOps Agile Skills Association (DASA) article, “DASA Provides Core Skills Key for DevOps Success,” which summarizes the “people and culture” elements from the “State of DevOps” report (this year and previous years) matching these with findings from more than 400 teams having participated in the Phoenix Project DevOps simulation. This I believe can provide input into the survey.
In a recent episode of the Continuous Discussions (#c9d9) podcast, we hosted Gene Kim and several speakers from the upcoming DevOps Enterprise Summit Las Vegas (DOES18) conference. We’re proud Founding Partners of the event and always enjoy having IT thought leaders join us ahead of the show to talk about DevOps, the conference program and more. In this episode, we discussed an emerging conference theme of next-gen operations and infrastructure.
The panel of DOES18 speakers included: Cornelia Davis, senior director of technology at Pivotal; Damon Edwards, co-founder and Chief Product Officer of Rundeck; Mik Kersten, CEO of Tasktop; Tom Limoncelli, SRE at StackOverflow.com; Gene Kim, founder of IT Revolution and co-author of “The DevOps Handbook,” “The Phoenix Project” and “Accelerate”; and Electric Cloud’s Sam Fell and Anders Wallgren.
Continue reading for some of the top takeaways from the discussion!
Next-Generation Operations: Programming and Insights
As we continue to evolve, the best is yet to come for operations teams, per Kim: “If we follow the course of what the development languages and development frameworks have done for development productivity, and extend that to operations, I think the best time for operations and infrastructure and platforms are to come.”
Davis encouraged operations teams to treat their platform like a product instead of infrastructure: “When I speak with the IT operations folks, they’re still largely short order cooks. They’re very reactive, doing things that people need them to do. It’s about being able to apply some of the same principles of continuous delivery to the way that you do ops. At the core of that is this philosophical notion, which is to treat platform just like you treat any other product.”
The way enterprise operations teams do work is unique, per Edwards: “For enterprise operations, you have to fundamentally rethink the conventional wisdom of how you think about, approach and do operations work. DevOps Enterprise Summit started in the early days of the DevOps explosion. This is distinctly an enterprise discussion because it’s all about that history of success that we have to account for.”
Kersten on the different ways development and operations teams measure outcomes: “I so often see the development side of the organization and the infrastructure operations side collecting completely different metrics and telemetry. The development side uses the more familiar telemetry that comes from DevOps. And the operations side is still in a burnup, burndown world. There are no common metrics or languages for what really should be an internal value stream.”
Great operations management advice from Limoncelli: “Get one team to do it well, and let people copy that success. And do it in a way that creates cultural minimums or cultural ways of doing things, so that people are competing to make things better instead of being told you have to make this change.”
Moving away from legacy operations is a dauting challenge especially for the enterprise, explained Wallgren: “The things that we refer to as legacy are the things that keep the lights on and bring the money in. It’s a big leap to move away from that and it’s going to take a lot of work and quite a lot of time. It’s like changing the engine and tires on a car while you’re driving down the highway at speed.”
Functional Programming, SREs and More Musings
Davis on functional programming, something she will be talking in-depth about at DOES18: “Treating function as a first-class citizen is absolutely essential because you start to create these functions very dynamically, and the functions now encapsulate the state. So instead of having state and then having side effects against a state, what we have are these functions encapsulating a sequence of changes that are going to generate a state.”
Kim described an “aha” moment he had during Davis’ talk at DOES18 London about sidecars in Kubernetes: “The ability to liberate developers and address cross-cutting concerns like logging was one of the primary impetuses why people flocked to Spring from orthodox frameworks that were so unsatisfying. And that was, for me, that was one of the biggest aha moments of the conference.”
Edwards discussed the implications of toil work and how to spend more time doing things of value: “Toil work is work that we should have automated, it’s repeatable, and not adding enduring value to what we’re doing. Versus work that requires human ingenuity, the engineering work that adds enduring value to our organization. Set a limit as an organization to not accept more than 50 percent of time being consumed by toil and figure out how to help those organizations where they have too much toil and not enough engineering work.”
Most organizations don’t have $2.5 billion in their back pocket to build a product-oriented value stream, but Kersten said we should take a page from their book: “This is a testament to how invested the tech giants are in their own platform as products. If we don’t at least adopt their thinking around having this connected end to end platform that supports all your products and value streams, you’re just not on the right path.”
Limoncelli on the ability of SRE’s to reach across silos: “In the SRE model, you can reach across silos. I like to think of it as you have the CICD pipeline and the SRE’s stand at the end of the pipeline asking, ‘What are the operational problems that we’re having? What’s the constraint? What’s the bottleneck?’ They fix that by asking how they can collaborate with the other team within our organization. And either sit with them for a week and fix it or collaborate with them to fix the problem.”
Wallgren elaborated on treating pipelines as code: “Treating your pipeline as code is something we’ve been evangelizing. And really, that should be the first thing that you really worry about in some sense, because you’re not going to ship anything unless you have a pipeline.”
The DOES18 Las Vegas agenda is now live! Check out the sessions from Davis, Edwards, Kersten, Limoncelli, Wallgren and dozens more. Tickets to DOES18 are running low, so be sure to register before it’s too late.
It’s hard to believe that DevOps Enterprise Summit London ( DOES18 ) is right around the corner! The conference, which takes place June 25-26 at The InterContinental – O2, is guaranteed to provide two jam-packed days of learning around architecture, next-generation operations, spanning business and technology divides and much more. If you haven’t already registered, there is still time to secure your spot! Receive 20 percent off registration using the Friends of Gene Kim code (FOG20) at checkout. And, if two days of DevOps just isn’t enough, Electric Cloud is hosting post-conference workshops for a full immersion experience:
From New Learner to Executive Leader—Gary Gruver (Electric Cloud strategic advisor, author of “Scaling Agile” and “Leading the Transformation”) and Helen Beal (product owner at the DevOps Institute,) build up your knowledge and transformational leadership potential in this full-day, hands-on workshop geared toward business leaders.
You Build It, You Secure It: DevSecOps Workshop—John Willis (Electric Cloud strategic advisor, co-author of “The DevOps Handbook” and vice president of DevOps and Digital Practices at SJ Technologies) hosts this full-day, hands-on, technical workshop to help build and incrementally improve DevSecOps pipelines.
Prior to DOES18 and upcoming workshops, we caught up with Beal and Gruver to learn a little more about their DevOps background and what attendees can expect during their workshop:
Alan Shimel: First, for those who don’t know you, tell us a little about yourself?
Gruver: Hi, everyone – glad to be here. In my professional career I’ve worn a lot of hats—I’ve been an engineering executive, a coach, an author. My experience in this space come from leading large-scale transformations in big organizations with complex tightly coupled systems. I think this gives me a unique perspective that is valuable to any managing large systems that aren’t in a position to just go and “re-architect everything to microservices in the next few months.”
I started out by leading a group of 800 developers in the HP LaserJet firmware team through a transformation that delivered a 2-3X improvement in productivity. The results were so great that we decided to document the journey in my first book, “A Practical Approach to Large Scale Agile Development.” This book, coincidentally, echoed the same ideas and was finished about the same time that Jez Humble and David Farley published their book, “Continuous Delivery.”
After that, I joined Macy’s.com as the VP of Release, QA and Operations to apply these same concepts to their very large-scale journey to CD. It helped that Jez worked down the street and we could share ideas back and forth over beers. During this period, the term “DevOps” started getting real traction, and I realized I was one of few people actually helping to roll out those practices in large, complex organizations. At the end of that experience, I published my second book, “Leading the Transformation,” where I documented everything I wish I had known to help others avoid the same mistakes I had made.
After my experience at Macy’s, I began coaching executives in other large organizations in order to help them transform their own software development and delivery processes. Each one of these engagements was unique, with very different challenges—although I could definitely see commonalities among them. I compiled that knowledge into my third book, “Starting and Scaling DevOps in the Enterprise,” where I lay out the approach I use in working with these organizations.
Beal: Hi, I’m Helen and I describe myself as a “DevOpsologist”—that is, I study DevOps. I coach, train, write and talk about all aspects of DevOps and help organizations use DevOps principles to deliver value outcomes faster, better and more reliably. I do this at Ranger4 through assessing capabilities, developing improvement roadmaps and then implementing those road maps through workshops, training and facilitating value stream-mapping exercises and games like The Phoenix Project Game. I’ve been working in the software industry for nearly 25 years and have spent most of them specifically focused on helping organizations make improvements in the software delivery life cycle. I also work with the DevOps Institute on content improvement and creation and am a DevOps editor at InfoQ.
Shimel: How did you “get into” DevOps? Why is it so important to you?
Gruver: I didn’t get into DevOps to “do DevOps,” because the term hadn’t yet been invented. Instead, I applied the concepts of what later became known as deployment pipelines to my particular situation because they were the process improvements we found had the biggest impact on our efficiency. The group I managed (at HP) was just starting a complete re-architecture of a 10M line code base when the economy crashed (2008), resulting in me being told I had 30 days to come up with a plan to drop my R&D spending by 50 percent but I still had to deliver the new architecture on time. This transformation was critical to the health of the business, so I took it as a personal mission to get this done so we could maintain staffing levels and keep the jobs of all my friends and co-workers.
Every day I came in and got to work with an amazing group of people that were focused on doing everything possible to help the company survive by improving the efficiency of our software delivery process. We ended up implementing a lot of changes that were later called “DevOps.”
It was such a huge breakthrough for the business that I have spent the next decade of my life trying to help others realize the benefits of these process improvements. And over time I have focused more on DevOps because I think it best represents the process changes that provide the biggest benefits for large organizations.
Beal: Working on the whole software delivery life cycle led to four years closely focused on deployment automation just as DevOps was becoming a “thing.” At Ranger4 we decided to build our business around helping organizations understand how to use DevOps principles and practices to make improvements. At Ranger4 we like to say we are fanatical about making life on earth fantastic and that’s the core of why it’s so important to me—we are trying to take pain away from the work people are doing and make them more successful and their organizations more successful.
Shimel: Tell us about your workshop. Who comes to your workshops? What will people coming to your workshop learn?
Gruver: My workshop is a combination of the “Leading the Transformation” and “Starting and Scaling DevOps in the Enterprise” books. We start helping executives understand their roles in leading a successful transformation and provide a framework for that effort. Next, we deep dive on DevOps, helping executives understand how implementing DevOps in large, tightly coupled organizations can and needs to be different from what you hear about being recommended by the unicorns with loosely coupled architectures. The workshop also shows the executives how to analyze their current deployment pipelines to identify the biggest sources of waste because I strongly believe if you don’t start delivering real business benefits early your transformation will start losing momentum.
This workshop gives people the opportunity to integrate everything they learned at DOES and put it together with an approach they can take back to their organization and start making changes that will improve the effectiveness of their software development and delivery processes.
Beal: My workshop is the DevOps Institute’s “DevOps Essentials,” so kind of what it says on the tin: the fundamentals of DevOps in half a day. So we’ll be covering things like where DevOps has come from, why people are doing it and what they are actually doing; the Three Ways; CALMS; changing culture; the relationship between Agile, Lean and ITSM; and building DevOps toolchains. People that come to my workshop will leave with a solid understand of the core practices and principles and DevOps vocabulary.
Extra insights from Beal:
Shimel: What’s the hottest topic in DevOps for you right now?
I’ve always been particularly interested in the cultural side of DevOps and right now I am most interested in the neuroscience of behaviors.
What did you learn this week?
I learned this thing about pigs and chickens in agile the other day which made me laugh, and also helped make an improvement in a particular team we are working with.
Ready to get your hands on DevOps? Register now to join Beal and Gruver June 27 at The InterContinental London – O2.
If you’re looking for a more technical hands-on experience, register for Willis’ workshop here.
Plus, there is still time to register and save for DOES18! Gene Kim is giving out his “friends of Gene” discount – use code “FOG20” at checkout for 20 percent off the ticket price.
There may be nothing more difficult in a DevOps transformation than aligning the business with its technology organization—and vice versa. Dealing with skills gaps and information gaps, while addressing communication breakdowns and cultural hurdles can keep even the most seasoned practitioners and leaders up at night. How do we align disparate business units accordingly? What practical tips can people take and implement along their journey?
These are topics we immersed ourselves in during a live video podcast ahead of the DevOps Enterprise Summit (#DOES18) in London. I was able to sit down with Carmen DeArdo of Nationwide and Jayne Groll of DevOps Institute to take a deeper dive into the DevOps transformation patterns and practices. This discussion centered on a major theme of DOES18 this year: business and technology alignment for the modern enterprise.
We hit on many important issues that I think we can all learn from and apply in our organizations respectively. One of the things we’ve learned over the course of the years is that, in DevOps, the focus is heavily cultural, but it has to be squarely on nurturing and getting buy-in across the organization. But at the same time, we need to be orchestrating our strategic alignment initiatives between the disparate functions and organizations within the business. That’s a tall task.
Watch the full video replay below, and/or read through the full transcript to see what key points were made and how we can adopt best practices to move our businesses forward.
Carmen and Jayne will both be speaking at DOES18 London this year and I will be leading video panels that you can see exclusively on DevOps TV / devopsy.kinsta.cloud. Hope to see you there!
Alan Shimel: Hey, good day, everyone. Thanks for joining us. This is Alan Shimel of devopsy.kinsta.cloud. And I’m here to talk to you all today with a few friends of mine about the upcoming DevOps Enterprise Summit in London. This will be a live panel discussion ahead of the London DOES event, which, by the way, is June 25th to the 26th at the Intercontinental Hotel, sometimes called The O2. Our panel today, I’m happy to say, are two really good friends of mine. Well, one is one of my business partners at the DevOps Institute: Co-founder and CEO of DevOps Institute Jayne Groll, and a speaker at DevOps Enterprise Summit London. Jayne, welcome to our hangout today.
Jayne Groll: Hi, Alan. Hi, Carmen. Thanks a lot. Really looking forward to it.
Shimel: Okay. So Jayne has already sort of introduced our next guest there, another good friend of mine, a recognized DevOps leader for many years. He really kind of kicked off a lot of the kind of groundbreaking DevOps work that we’ve seen at Nationwide over the years. Also a great Pittsburgh Steelers and Pittsburgh sports fan, Carmen DeArdo. Carmen, welcome.
Carmen DeArdo: Welcome Alan. Welcome. Hi, Jayne. It’s always great talking to you.
Shimel: Thank you. So all kidding aside, both of you are kind of experts and leaders within the DevOps Enterprise community, and you’re both presenting at DOES London this year. You’ve actually both presented at previous DOES events as well. So thank you for coming here. You know what? When you guys first started kind of preaching in the wilderness about DevOps and so forth, it was a bit of the wilderness, but it’s becoming commonplace in businesses and organizations throughout the world now. Our goal on this chat, guys, is to learn about the patterns and practices that leaders have identified for business and technology alignment, and really what we’d hope is just to share your experience and thoughts with our audience so that maybe they can learn something and they could integrate or assimilate that into their own transformational journeys and escapades.
And just again a reminder, this is about DevOps Enterprise Summit London, June 25th to 26th, and you can get more information on the event at events.itrevolution.com. You’ll find on there, by the way, the entire conference agenda, and beyond Carmen and Jayne, it is a gangbuster lineup of speakers. If you’re interested in DevOps and any kind of related type of technologies and frameworks, etc., it’s really a can’t-miss one for those of us, you know, who follow this space, or even for those of us just getting involved in it.
That being said, though, I’ve spoken enough. Let’s get started. I’ve given a little bit of your background, but maybe I haven’t said everything that needs to be said. So, Carmen, since I see your lovely face on the screen ahead of me here, why don’t you go first? Give us your background, your company role, etc., professional accomplishments.
DeArdo: Okay. Thanks, Alan. So I actually spent most of my career in telecom working for Bell Labs. Thought I would retire from Bell Labs like everyone else at the time, and then the telecom bust happened, and we all had to figure out what we were gonna do with the rest of our careers. But it served me well, because I think a lot of those concepts, even though we didn’t call them DevOps, but, you know, certainly, creating high-availability, high-reliability capacity systems, you know, those concepts are still, I think, pertinent obviously today. I moved into Nationwide to really help with trying to get Agile set up about 12 years ago, and then, you know, as I think you see the case with a lot of companies, they start somewhere in their value stream. They may not even think of it at that point like an end-to-end value stream, but they’re starting somewhere. They start with Agile.
You know, we were very successful getting all our work done there, but then realized, okay, that’s only part of the story. The cards getting into the backlog through iterations is great, but we aren’t getting flow of work from the business into the teams, and we certainly aren’t releasing into production frequently. So about, I’d say, five years ago, you know, somewhat in affiliation, some of the work I was doing with, as you know, Rosalind Radcliffe, Hayden Lindsey, you know, started to talk about what’s this DevOps thing. Was lucky enough to end up at the first Gene (Kim) conference speaking with Hayden. Wasn’t sure what I was getting myself into, but it’s been a wonderful experience. You know, got to meet you, Jayne, and lots of great folks from Gene’s community.
In Nationwide, we’re just continuing to work, how do we make that end-to-end flow and lead time, you know, what do we do to make it better? What DevOps practices can we bring? But as you noted at the beginning, how do you get the business more online? How do you get work to flow? And how do you address culture, which we know is probably more important than technology?
Shimel: Excellent, dead on. Jayne, how about you? You have more hair than both Carmen and I. You’re the lovely face we should see on the screen here. Give us a little background and accomplishments.
Groll: So I call myself an accidental technologist. So I started my career, got out of school, ended up in the legal field for about 15 years working on the business side. So I wasn’t a lawyer, but I was one of the early paralegals for a big Wall Street law firm that adopted UNIX a long, long time ago. I don’t even want to say when, but screens were black and green back then. And so everybody had to learn UNIX. And so I was very fortunate to be given an opportunity to accidentally become a technologist, and I know even with my technical skills, I’m a little self-taught. Was able to move up into some senior management roles across several different verticals, leaving the legal space.
And then in 2004, kind of fell on ITIL and really started to see a paradigm shift in IT that technology is important, but your practices, your principles, your processes are important as well. And people, process and technology became a mantra. And so co-founded ITSM Academy with Lisa Schwartz and really saw the growth of maturity in IT. You know, I always say we love our frameworks. IT, we love our frameworks more than any other business unit, and really started to see that percolate. Met Gene and some others through that experience, but really, landing where we are today. In 2012, I was able to attend an early DevOps day, frankly, at Gene’s invitation and really saw something percolating there that was pretty much common sense, but not common practice.
So we started to see, you know, should Dev and Ops collaborate better? Should there be a faster flow? Should there be less silos? Yes. Should we use automation more? Yes. We automate the rest of the world, we don’t automate ourselves as much. And really started to see something grow there, and, Alan, as you know, in 2015, we launched the DevOps Institute primarily because the practices around DevOps unlike other frameworks were really emerging in the wild. You know, you said it before. They were emerging in the wild and making some sense out of that, you know, as it crossed over into the enterprise space was important and requires a lot of research.
So, you know, we don’t have a single body of knowledge in DevOps. Thankfully, we have a collective body of knowledge in DevOps. So for me, I think part of my, you know, pride is my journey has not been a linear path. Really blessed to be, you know, where I am today, and, you know, DevOps Institute right now is, what, 32 countries that are talking about in doing DevOps. I mean, that’s really kind of surprising and remarkable all at the same time.
Shimel: Yep. And just to excuse, I don’t know if you guys can hear. We have a train, the 11-08 Cannonball Express, going via the office here.
DeArdo: Just like my cousin Vinnie here, Alan? Is that like …?
Shimel: That’s “two yutes.” The way I talk, we’re not far off. Anyway, though, guys, let us move along here. You know, one of the things that I’ve learned in my own exploration of DevOps and digital transformation, etc., is that a lot of businesses, large enterprises, they may think they do, but on the whole, they don’t really understand technology. Yeah, some of the guys in IT understand some of it or what have you, but do you think most businesses understand technology? Carmen?
DeArdo: I think it’s … Obviously, people are exposed to technology. In fact, I talk about this all the time, that sometimes we’re still in the book writing business or book production that we still feel like we got to produce manuals of paper material … The disconnect comes as, How we can effectively utilize the technology that we have to meet the business needs? And I think that’s maybe where the disconnect goes. It’s not that, you know, people certainly are … they have Alexas. They have stuff in their home. They may be even, you know, great at programming their home devices, but how are we actually taking advantage of that to serve our customers? And I still think thinking about things kind of in this … you know, Jayne talked about silos, but I actually think the last frontier really of DevOps is in the left part of the value stream, not the right part.
I think they code the cloud. There’s patterns, maybe not everybody’s done it. I know it’s not easy to do. That’s pretty well-defined from a pattern. The front part is not, and I think understanding that, you know, you have to basically be an IT business. We hear this all the time. If you’re not an … consider yourself an IT business, someone who is good at IT is gonna disrupt you. So it’s not that I don’t think they understand technology. They’re certainly capable of it. It’s just, do we really understand how we can use it the best way in order to meet business needs? And, you know, things like the system of engagement. Well, the system of engagement is gonna change. We’ve already seen it change. It changed from web to mobile. It’s going to voice. It’s gonna go to different engagement models.
That’s fine, but you still have to have the back-end technology, and the microservices, and the APIs, and the ability to deliver more quickly, and I think that’s the part of it, the gap we still haven’t bridged. And how can we actually get …? You know, one of the things that Nicole and I are talking about at the conference is the project-to-product model. And I think large companies like ourselves are kind of flailing at what … you know, that makes sense. It makes sense to align around a value stream, but how do you really define what those value streams represent so that you can actually get that flow and then use technology to help get that quick deployment and, you know, feedback? So I think that’s where we see a lot of the gaps, you know, from that perspective.
Shimel: Sure. Jayne, before I have you answer on that, you know, I got an email of pitch. I get a lot of pitches as you can imagine, but I got one the other day that, to me, really nailed the issue. The issue was they pitched me about how great their solutions and their services are, and they said it makes IT costs less. Instead of … so they’re still thinking of the IT department as a cost center instead of a profit generator. And to me, when you say that, that means you really don’t understand technology, you don’t understand the role of IT in the modern enterprise, and you’re just not doing it right. Jayne, your thoughts.
Groll: So I think you’re right. I think, you know, the modern enterprise has a few challenges ahead of it. Carmen, I absolutely agree with you. I think every business knows they need technology and they need to accelerate their use of technology. I think they don’t understand how to apply that, and more importantly, I think the big paradigm shift, and, Carmen, you said it, is that most companies don’t realize that they are now technology companies. It isn’t even just IT does for you, is the core company as a technology company. And those that kind of recognize that, I think, are those that move ahead. Those that are still kind of hanging on to a legacy … Now, you know, I’ll add kind of something into that recipe that’s a little scary.
With the way technology is moving and how fast it’s going, I mean, the acceleration is remarkable, and, you know, Carmen, you said it. It was cloud. It was mobile. Now it’s voice. That it feels like, you know, this kind of moving target that if I’m a business leader, not a technology leader, although Lord knows that, I think, has a plan here, you know, where do you put the dart? You know, do you invest in mobile? Do you invest in voice? Do you invest …? So it’s such a moving target, and it’s going so fast that I think it can be very daunting to figure out, okay, where do we make our play, and, you know, where do we use our technology spend? And I would say something funny, Alan, because you’re right.
You know, in my years in senior IT management, I almost always reported to the CFO, because I was a call center. And so it was nobody understood quite what I was spending money on, but they figured if I reported to the finance guy, that somewhere along the way the cost would be controlled as opposed to let’s optimize the capability. Let’s look at this in investment. So I really think organizations are trying to figure out, first of all, are we a technology company? And I would say unequivocally the answer is yes regardless of what vertical you’re in. And then where do I invest? What technology do I start looking at? And if what I do today is gonna be obsolete tomorrow, how do I make that investment for my company further?
Shimel: Excellent. So, guys, you both have a little bit of a background, more than a little bit, in training and so forth. Do we train people outside of the IT organizations on what technology can do for you? Do we put up sort of Uncle Sam’s “We want you. What can I do for you?” posters? How do we get the business to understand the technology aspects, the technology side of things? Go ahead.
Groll: I mean, you know, the “we want you …” unless you can promote something that says what’s in it for me, me as an organization, me as an individual, me as a leader, I think that’s difficult. You know, doing road shows on here’s what technology can do for you isn’t something that you can tell. I think it’s something that you have to prove. And I think IT sometimes runs into an uphill battle trying to prove that, because it is costly and it does change a lot of the way people perform on a daily basis. I know what I did today, and tomorrow you want me to do something differently, and I may not be as successful as I was yesterday.
So there’s a little bit of a proof of concept usually, you know, done through piloting, whatever, but I think the, “How do we tell them?” I don’t think we tell them. I think we have to show them.
Shimel: Fair enough. Carmen?
DeArdo: Yeah. I mean, I think we’ve gotten a lot of appreciation. I mean, I’ve told … you know, and Cindy Payne and Jim Grafmeyer told the story at the last conference about Hurricane Harvey and how the business was able to respond within a day to what was a wind event and came a rain event with all our flooded cars and how we got the website optimized to handle those, to take the load off of our customer service center. They’re starting to get that, “Gee, having this capability to deliver things more frequently …” We now have some of us who deliver daily whereas before everything was going into a monthly release. So that’s a great accomplishment.
On the other hand, we’re running into the things that, you know, Topos talked about with compliance, with legal, with … and just, you know, how do we … Most of our time now on lead time is going from the idea to the backlog of the team, not from going from the … you know, the team getting the work to deployment. So I think going into, you know, that view of how do we start to think more about, you know, the other things that are getting in our way of lead time, because it’s not just the IT part of it. It’s now the business part of it, and we have a couple areas now who actually have true product owners sitting with their lines and are almost at the point now where they can deliver, you know, stories and storyboard them and move them all the way through production, you know, much more quickly.
So I think that’s an example, and I think that’s what you need. I always talk about you need stories, you need examples of how this can actually be done at your company, because reading about it, hearing about it is great, but then when you see the team next to you doing it, and even if it’s not perfect and even if you know it can be improved, that’s where really you start to change the culture of not just IT but of the business. You want something like that. And then, you know, I think you got something going that you can really build on top of. Jayne.
Groll: Yeah. I mean, I think that conferences like DevOps Enterprise London, Las Vegas, other events, local events, I think, also let individuals and organizations know they’re not alone in this journey. You know, part of the challenge in DevOps right now, I think, is we’re going from what is DevOps to how do we do this. And it’s not finite. It’s not, you know, you open a recipe book and it says, “Start here. Add these ingredients. You know, stir, bake for 350 degrees, and you have DevOps.” It requires a lot of higher-level thinking, requires some experimentation. And so I think that, you know, access to what have other people or organizations done … Carmen, I think you’re absolutely right, what have other teams done, really kind of making it a community of enablement is very, very important in this space, because everybody’s trying to figure out where do they start. And unfortunately or fortunately, the answer is it depends. It depends where you are, it depends what you’re trying to achieve. So I think that’s part of it as well.
Shimel: Yep. So, guys, let me try to tie a bow on this section before we move on. The reason I asked about the technology and technology education issue is I think it’s imperative for organizations to understand that in order for us to get what I call business and tech alignment, and what I mean by business and tech alignment is that we’re all pulling in the same directions for the same reasons with the same goals, and we’re following hopefully a road that we have agreed upon, and we all know the road we’re traveling, because, again, you get back to DevOps, guys. You know, when you guys are out there talking about it and we were covering it at devopsy.kinsta.cloud, what do we always hear? What exactly is DevOps?
There’s no real definition. What does it mean? You know, how do we define DevOps and so forth? And I think one of the things we’ve learned over the course of the years is that, you know, in DevOps, the focus is, you know, heavily cultural, but it has to be squarely on nurturing, buying across the organization for this “DevOps initiatives,” you know, that we’re starting. But at the same time, we need to be orchestrating our strategic alignment initiatives between the disparate functions and organizations within the business. And that to me is business and tech alignment. If you guys don’t agree with that, speak up, but if you do, let’s move on to our next part, but can we wrap up, Carmen, Jayne? Are you fair to say that what we’re really talking about here is business and tech alignment?
Groll: So I’m gonna jump in just for a second, because … So you know I come from the ITIL space. And so in the ITIL space, they were coining the term BITA, business IT alignment. And so for years and years and years, there was a lot of conversation about BITA and its semantics. But alignment means that we’re kind of standing side by side in lanes next to each other. The reality is it isn’t alignment. It’s really unification. It’s really we don’t need to align with the business, we need to become the business. And, again, I know it’s semantics, but that word alignment gets tossed around a lot, and it implies something like, “Well, I’ll drive my car next to yours, and we’ll travel at the same pace, and we’ll get to the same journey,” as opposed to, “Let’s be in the same car.” And so you understand what I’m saying?
Shimel: Yeah.
Groll: And I said the term BITA is sort of falling away a little bit, but it was thrown around a lot during the years when ITIL in particular, you know, was kind of front and center.
Shimel: Yap. Carmen, any thoughts on that before we move on?
DeArdo: No, that was great points. And, you know, I refer back to Mark Schwartz’ last book, “The Seat at the Table,” and where he really talks about IT really should move beyond trying to get a seat at the table and move towards, you know, as Jayne said, you’re actually moving together, and you have to merge really these concepts of what the business wants, you know, has to be very much aligned, more than aligned. It’s part of what IT need to be doing. So that merging has to take a fact, and I think as much as we’ve seen the culture issues in Dev and Ops, that’s gonna be an interesting culture issue. But we’re seeing the companies who are successful are already doing it. They are working together. And, you know, if you walked up to some of the teams I just talked about, you wouldn’t be able to say, “Oh, well, such-and-such is a business person, and, you know, Jayne’s a business person, and John’s an IT person.” No, they’re a team working together to achieve something for the good of the company, and that’s the way it has to be.
Shimel: Yep. Guys, let me broach another subject then, because I think we’ve covered this one. You know, I read an article yesterday about AI, and automation, machine learning, and we’ve all seen these before, and, you know, how it’s changing. But automation really is changing the job market, especially for people younger than the three of us. I mean, we’ve both seen our … all three of us have seen our 21st birthday recently and …
Groll: Just recently.
Shimel: Recently, but really the folks coming up behind us, and we’re talking about our children and so forth, automation and the job market that they’ll grow into is paramount. And one of the reasons is that we have a tremendous skill gap. You know, my background is obviously in infosec, and now we call it cybersecurity. I hate the term. But there’s a tremendous gap in the security space. There’s also a tremendous gap in the DevOps space, obviously, and that’s one of the reasons we see such a high demand, even for people who may not be certified or classically trained in DevOps, I mean, take some sort of DevOps class. If they’ve learned to work Puppet or Chef or Jenkins, you know, they’re in high demand here.
And so with this skills gap, it doesn’t hinder our DevOps transformation. Is it a drag on the entire DevOps industry or community? Jayne, I’m gonna ask you to take first crack at that. I mean, you must see this with DOI stuff.
Groll: I do, and, you know, it’s kind of like good news, bad news. So the great news is, where else do you get to work in an industry or an environment where you are now encouraged to learn something other than what you’re essentially good at? I mean, you’re now encouraged to grow new skills to evolve. Organizations are funding skills modernization programs. So, you know, we groomed … and Carmen referenced that. You know, we groomed an IT based on silos. And in every silo, you were a developer, or you were a QA person, or you were a security person, and you lived in your silo with other people who had the same skills as you did. And now, cross-functional skills and, you know, what they call T-shaped people where you need to still have a specialty but you’re absolutely required to have very large breadth of different skills means that organizations are supporting and funding that.
So the continuous learner is more the norm today than it was before where you will be a developer … experience, and I think it’s a great day to be in technology truthfully, because you are encouraged to think, and learn, and practice, and train, and do, you know, all sorts of other things. And I think companies are starting to see that. I hear the term “skilling” a lot. We not only talk about training, we talk about skilling. We need to skill our force. We need to skill our teams. We need to reskill or upskill. You know, those are really terms that are starting to enter our common vocabulary. And the day of the generic, “I’m a master, I’m an expert, I’m a practitioner,” and I’ve got a few of those credentials as well, those are so ambiguous that now the skills are very, very tangible, and organizations are hiring, I think, hiring and funding individuals to develop not only technical skills but practice and principal skills, too. So we’re all gonna be upskilled, maybe outskilled.
Shimel: Perhaps both. Carmen, how about you on this one?
DeArdo: Yeah. I mean, automation is obviously nothing new. I mean, I’m really dating myself, but I can remember when people didn’t trust the output of compilers. Like, are we sure the compilers are producing the right machine language or assembly language? I don’t know. I can bring the assembly language better than this compiler. I mean, I think automation and learning is just … obviously, you know, if you spent, you know, four decades like I have, and, you know, none of us are spring chickens, but you’ve got to learn a lot and keep learning. Now, I think the great thing, and I agree with you and Jayne, the great thing about Nationwide is they have invested in learning and upskilling their people. We had this thing called Teaching Thursdays where twice a month we have two hours which is set aside for peer-to-peer learning, and it’s really not … and it’s peers teaching people, and people love to be the teacher.
I mean, at the last forum, Jason Cox was talking about … We had a subgroup focused on operations, and Jayne was there. And talk about … you know, he had some folks on his team, that they have to become engineers. They have to become coders. And one of the guys who initially maybe wasn’t so crazy about it, once they became kind of the expert in their area and they were teaching other people, well, you know, they were really engaged then, because, you know, they were involved and they were the one now from a peer-to-peer learning perspective.
So companies, I think, like Nationwide, Disney, other companies that are leaders in this space need obviously to invest in that. And then, you know, it also means that the associate themselves, you know, needs to take advantage of that. I mean, we can offer those capabilities. We know the jobs are gonna change. We can make those skills available, and then folks need to take advantage of them, but yes, I mean, people have to become more broadly skilled and be able to become more of what I would call problem-solving engineering mindset as we move forward.
Shimel: Sure. So, guys, though, you know, so we have skills over here. And on this side, there’s another thing that creates a tension with the skills, and that’s what I call the information gap. So we have a skills gap, and you guys have both addressed that really well, but we also have an information gap. And I alluded to it when I talked about training. If an employer or an organization thinks that someone who can write a recipe in Chef or has heard of Jenkins is a DevOps engineer, if there’s such a thing as a DevOps engineer, or is someone who, you know, is gonna really help build their DevOps team, to me, that’s not a skills gap, that’s an information gap. How do we understand … How do we make organizations … How do we fill that gap on information so that organizations recognize, A, that there may, in fact, be a skills gap, B, how to fill that skills gap and bring the organization up to it?
I mean, this tension, this chicken-and-egg, if you don’t know it, you don’t know. How are you supposed to know? And so I’ll put it to you. What do you think is more important? The information gap, the skills gap? Are they equally important? Do we tackle them concurrently, individually? Carmen, how do you guys do it at Nationwide?
DeArdo: I mean, I think one of the things that IT hasn’t been good at is treating IT as … we’ve been a very bad customer to ourselves. So if you look at our pipeline, we don’t treat it as a product. If you actually want to get faster at delivering a capability from idea through deployment, you need to consider that as a product, not a bunch of different tools. It’s not Jenkins, and New Relic, and UrbanCode or, you know, the AWS. It’s not that. It’s a pipeline that’s gonna enable you, and it doesn’t start at code, it starts at idea to get you all the way through that deployment. So then what … do you have a team? Are you doing thinking across the pipeline? Are you doing architecture? We don’t do things like value stream architecture or architecting the pipeline as a product. We want to buy a bunch of technologies. We can hire people good in those technologies, but as you said, that’s not really gonna get us where we need to go.
So I think the first thing is, do you really treat your product … One of the first things, do you treat your pipeline as a product? Do you have a team that can actually support that product all the way? Do you have a product owner who can drive continuous improvement across that with funding and prioritization? And do you have one of your best architects, if not the best, to actually create the architecture and do value stream architecture, which is something, you know, that Mik Kersten and I have been talking a lot about. I think that’s one side of it that we don’t get, is teams could … if you ask a team, they can kind of figure out, tell you like a Deming quality circle, how they can go faster. And you can experiment, but then if you’re gonna operationalize that, you don’t want 200 teams doing things in 200 different ways. You can then take that and say, “How do I address that as part of my delivery capability?”
And then I think what you need your leadership to do is apply systems thinking, and that’s a whole another subject we could get into, but I don’t think executives and leaders know how to really address the, “How do I optimize this as a whole?” They want to get into the weeds. They want to get into the tool selections. There’s people that can figure that out. You need to really focus on the strategy and how you can optimize all this great information you’re getting to make sure you’re removing barriers and allowing teams, you know, doing the learning, making sure they can be upskilled, investing in their ability, and allowing them, you know, to be able to innovate and improve your delivery capability. And I think that’s what I just said quickly. It’s easier said than done. And I think that’s where I see a lot of the struggles, and I think where we’re trying to address this is how do we start to put some of those pieces in place so it’s not just a bunch of, you know, divergent disparate technologies we’re trying to bring in and hope that that’s gonna make us get better. Because those things and having skills just around those things is not gonna actually get us to where we need to go.
Shimel: Fair enough. Jayne, I’m gonna give you a chance to comment on the DevOps skills versus information gap.
Groll: So I think the two are really related, and I think Carmen brings up some good points. You know, I think it all comes down to silos. So let’s look at our silos. Well, within our silos, we speak the same language. We use the same acronyms. We use the same tools. We live in a common community where everybody kind of understands what’s going on and what’s happening. And then when we leave our silo and we try to talk to a different silo, we don’t speak the same language. We don’t use the same tools. We don’t have the same processes. So I think the skills gap doesn’t fully overcome the issues with the information gap, but, certainly, there’s help there that if we’re looking to share information, we have to share it in a way that everybody kind of has some type of uncommon understanding.
The other thing with information is, you know, information is really interesting to me, because everyone thinks they communicate a lot. People generally think that they communicate well. You know, teams generally think they communicate … like I told you that. You told it to me maybe in language I don’t understand or it wasn’t clear. It was some report that, you know, I don’t even know where it is. So I think, you know, kind of the flow of information and from a vocabulary perspective, from an understanding perspective, from a “Did you understand what I shared?” is something we all need to overcome. And I think, you know, again, they’re so interrelated to each other that if we start to create a broader set of skills, hopefully, that helps to improve the communication. I think the other side of it is we talk a lot about collaboration, and there’s a really fundamental difference between communication and collaboration.
And so information flows through communication, but communication is pretty much one way. I tell you, you tell me, and somewhere along the way. Collaboration is I start to ask your opinion, and that’s a really big, big difference. And so when we’re starting to share information, there’s a respect that comes across the skills gap. There’s a lot of things that go across that that, again, there’s separate gaps, but hopefully, the long term, and as Carmen said, not easy to fix, is by overcoming some of the skills gaps as well.
Shimel: Fair enough. I think we’ve covered that one well. Let’s move on to another area if we can. We have 20 minutes or so. You know, one of the things that really does my heart good is this concept of DevOps everywhere as far as the eye can see, like the meme with Buzz and Woody. We have seen DevOps move from just Dev and Ops to QA, DevSecOps exploding on the scene where, you know, a couple days, the 28th, a day or two after DOES London, John Willis and team are rolling out our second DevSecOps Days, which I’m involved in, and devsecopsdays.com for those interested. But even beyond IT, we’re seeing what I call DevBizOps, where DevOps’ Agile sort of practices are starting to take hold in HR, in sales, in finance, in, you know, accounting, etc.
And let’s be fair. This is not unique. The fact of the matter is a lot of the lean terminology, a lot of the lean stuff that was built into DevOps didn’t come from IT, it came from manufacturing. And so, you know, it’s like pay it forward. Now we’re seeing these kinds of DevOps principles move into other areas of the business. First of all, is that a good thing? I think it is. I can’t imagine it’s not, but I’ll defer to the both of you. And then, secondly, you know, hey, at the end of the day, remember, it’s all about the culture, stupid. And so what human factors, cultural factors should we be thinking of when we talk about a broader DevBizOps opportunity? And, Jayne, you’re on my screen, so I’m gonna tell you to go first on this one if you can.
Groll: You know, it’s business transformation. You know, it’s not really DevOps transformation. Digital transformation is not limited to IT. It’s really business transformation. And so it goes back to, you know, we talked about a little while ago, where, you know, every organization has to recognize that technology is their business, and so some of the practices from the business start to assimilate into IT and beyond. I saw this in service management where there’s now movement towards enterprise service management, where you’re gonna make changes, you do it the same way.
I think when we start to look … I mean, I can tell you from the content perspective, you know, we use tools in content development, even though it’s not software development, that are very, very similar to that. So I think it’s fantastic. I was talking to a gentleman from an organization on the Netherlands recently, and they actually took the Spotify squad model and applied it to their entire business, and not a small company, by the way. And so they applied it to their entire business where their business is now broken into squads. And, you know, some think that that’s only for a tech company, and by the way, this is not a tech company. It’s a large financial organization.
So I think that’s great. I do think there’s some … I think there’s good news, bad news. I think there’s a little bit of risk that, you know, with DevOps and some of DevOps practice is still emerging that it becomes, “This week, we do it this way, and this week, we do it another way.” And, you know, “Oh, that didn’t work because …” You know, fill in the blanks, but I do think that kind of having a one business and getting away from this we love our frameworks and IT, and every year, we have a new framework that supposedly supersedes the other framework, you know, that’s a maturity issue. And I think if the business embraces it … you’re right, Alan. Lean Six Sigma. That was a business initiative that a lot of organizations underwent that weren’t necessarily manufacturing organizations. So, you know, as we get closer to that, I think the unification becomes stronger.
Shimel: Great. Carmen, how about you?
DeArdo: Yeah. So I think of things like … It is a great thing. So I think of things like lean concepts. We have leaders across the company that we have gone through lean education and lean concepts. So when you talk about value streams, when you talk about lead time, when you talk about wait states, people understand those concepts, whether they be on business or IT. I mean, this whole idea that Dominica, I’m sure, would have talked about, about making work visible, Kanbans. I mean, we actually had an explosion of people who wanted to use some of our tools that initially were brought in for work out of management because they wanted … you know, it’s like, “Gee, who knew, you know, this Kanban stuff would work for us and WIP.” WIP limits. And so people certainly want to apply those kind of concepts.
So I do agree that, you know, the basic concepts, you know, really can spread everywhere, and the whole concepts of even the things, like we talked about it, the three ways. The three ways don’t just apply to IT. The three ways apply to anything that you’re trying to do and get better at. I think when it comes to information sometimes, though, you know, it’s kind of like the robot story and the goal. We have lots of KPIs, but are we actually focused on the goal? So the goal is not around keeping this person utilized or that team utilized. The goal is about, can I get faster from one end of my value stream to the other? And do we have data that shows flow? And that’s why I’m excited with some of the things that I’ve been … you know, that Mik’s talking about. You know, he has a book coming out that is gonna show actual flow of work, because up until now, we have not been able to actually see work flow all the way through that delivery pipeline. And so we guess a lot of times. We think, “Oh, well, if we just add more developers. Oh, we’ll add more testers.”
Well, how do we know? We don’t really know, because we’re making maybe educated guesses, but we’re really not all focused on understanding where the work is and those concepts that can shine a light on it. So I think it all does come back to a lot of those concepts that, growing up in Bell Labs, I was lucky enough to experience with Deming, even going back to Shewhart, around doing those experiments, getting better, seeing the entire end-to-end value stream, but these concepts apply. I mean, “The Phoenix Project” is really not a book about IT even though I teach part of it. It’s a book about how do you get better at doing whatever business you’re in and trying to, you know, stay in business and improve what you’re doing for your customer. So I think those concepts will continue to go, and I think, again, as we’ve talked about today, there’s a thread here of everybody needs to be on board with these concepts: legal, compliance, the business, everybody, because they all play a role in allowing you to do a better job, delivering more quickly to your customers.
Shimel: Fair enough. Guys, let me … You know, Carmen, you hit on some great things there. The Kanban board or even here at devopsy.kinsta.cloud, frankly, we run our entire customer engagement, not practice, but now into farming, on Trello cards, which is sort of an electronic Kanban. And it’s a great project manager. I’ll give you another thing. You know, there’s the cultural aspect of this of taking that sort of DevOps culture and expanding it throughout the organization, but there’s also the bits and bytes and tools aspect of it. Kanban’s a great example. I’ll throw another one out at you. Get up. Why does it have to be source code for programs? Why can’t it be source code for contracts or any kind of digital document or, you know, things that we work on?
So I think we’re just starting to scratch the surface on how we can take that DevOps can do or Kanban and, you know, move it out across the entire organization. And we’ll all … I think we’ll have better organizations as a result, but let me now turn it back around. How can we take some of the business culture positives, some of the things that have worked in other parts of our business, and reflect it back into our DevOps and IT processes? How can we enhance our DevOps by adopting broader business principles and practices that seem to work? Carmen, I’ll let you take first crack at that.
DeArdo: So I think, actually, a lot of our test and learn activities started with the business who had actually hypotheses around, “Well, if we offered a policy in a different way or if we made a tweak to something, would we be able to sell more of those things?” So we had people who … and there’s a lot of statistical rigor that you have to bring to that. So we actually had people on the business side who had these ideas about, “I have a hypothesis. You know, is there a way you can allow me to test that hypothesis to see if it, in fact, will yield some positive result in terms of actual policies being sold?” So it was a very scientific-type experiment that they actually wanted to run, and at the time, we really didn’t have a way to support that from an IT perspective. And it kind of forced us to do some things to support, you know, how could we actually get this out and offer it to only a subset of people, which we now might call canary launch or some other terms that are DevOp-ish terms, but really nobody was reading a DevOps book at this point. They were just trying to figure out, “How can we support the business’s need here to try to adapt more quickly and have a high plan around?”
And that started, I think, some of the things that actually were successful that then led into once we started to get into DevOps, like, “Okay, what we actually did there was DevOps.” We didn’t call it DevOps, but those are principles that really we need to support not just in this one’s case, but for all kinds of business hypotheses that we want to get out and turn around real quickly. And doing that really does bring everybody together, because it’s exciting. It’s exciting if you can sit at a business and you can think up, “I have ideas for this product or that capability. You know, how can we more quickly try to see if that would be a good idea?” rather than writing a 12-month business case and trying to do, you know, a protracted study.
So the whole idea of experiments and gain things out quickly, I mean, everybody will resonate and get behind that if you talk about it in that way. If you start talking about Puppet and Chef and things like that, that’s not gonna cut it. But if you talk about it in terms of business and what it can mean for the business, then that resonates and gets a lot of people excited.
Shimel: Excellent. Jayne, how about you?
Groll: I mean, I think Carmen is right on point. And, Carmen, you said something I think that was … you’ve said a lot of very insightful things, but I think in particular that the experiment came down to, “How can we sell more policies? How can we make our business more successful?” And I think if you look at kind of the past in IT, sometimes, we didn’t know how we were contributing to the bottom line. So we were introducing a lot of technology, and we were doing all this cool stuff. But how did that convert into an increase in revenue, an increase in market share, increase in competitive advantage, things like that? And so I think that this unification with the business becomes more significant when IT sees themselves as an enabler of the goal. The goal of every business is to make money. And so sees themselves, and it goes back to information and communication as well, that they understand that what they’re doing is actually helping to sell more policies or increase market share or stand above the herd or anything along those lines.
Now, again, if you’re the CIO, you probably know that. If you’re in senior management, you probably know that. If you’re a developer and you’re one of a few hundred developers, you may not know that. And so I think that it is that kind of bottom-up top-down approach where understanding that what you do every day is contributing in a very, very substantial and tangible way. And then I think the other part of it, and, Carmen, I think you said it really well, is encouraging those experiments where the business and IT work together. And maybe it is that 1 in 100 coder that’s working as part of that team to say, “You know what? I have an idea.” Everything starts with a great idea. It could be from the business. Hopefully, from the business, that says, “I have an idea. Let’s see if we can, you know, bring that to life and what it will do to our bottom line.” And then there’s really a great collaboration between IT and the business.
Shimel: Agreed. Agreed. So, guys, we’re coming up to the top of the hour here, and I guess we need to wrap up. Otherwise, we’ll just be on air all day, and I know Jayne has a show in Vegas and so forth, and Carmen has stuff to do. But first of all, Carmen DeArdo, Jayne Groll, thanks for being our guests here on this hangout as we, you know, continue to build up to DevOps Enterprise London, DevOps Enterprise Summit London. Just a reminder for anyone watching, it is June 25th and 26th in London. There are still some tickets left, I think. I don’t know how many. I wouldn’t wait. You can get updates about the event as well as get tickets at events.itrevolution.com. It’s obviously on the web.
By the way, this year, as in past DevOps summits, devopsy.kinsta.cloud is a media sponsor. We’re partners. We’ve partnered with Gene from the beginning. We will be doing videos again this year at DevOps Enterprise Summit. I think it’s gonna be a little different this year. We’re doing some interesting roundtables. You’ll see them on our YouTube channel, DevOps TV. So stay tuned for that. All right. Guys and lady, or guy and lady, I had a great time today. I’ve learned a whole bunch. I hope our folks listening and watching this have learned as well. You know, you guys have done, not just today, but, Carmen and Jayne, you’ve been instrumental in helping to bring the gospel of DevOps to the world, if you may, or at least maybe not the gospel, but at least some really good learning and understanding.
So thanks again, guys, for being with us. We’re gonna call it a wrap. Carmen, any last word? Three words.
DeArdo: Three words. Project to product.
Shimel: Okay. Jayne? Last words from you.
Groll: Pittsburgh Steelers. I don’t know.
Shimel: We finally got her. Carmen, we converted her.
DeArdo: I should have said, “Let’s go Tens.” That’s three words.
Shimel: Okay. Hey, everyone. I will see you both in London June 25th and 26th. Hope to see many of you listening or watching this in London as well. If you’re there, stop by, say hello. I always like to meet people who have watched us online. But until then, this is Alan Shimel for devopsy.kinsta.cloud and IT Revolution. Thanks for watching, everyone, and hope to see you soon. Bye-bye.
