As we discussed in the last post, most of DevOps today focuses on the process blocks that mostly impact engineering or technical aspects of a product rather than the design aspect. Even though DesOps was primarily born out of the primary need of how to design at scale, the factors that shaped it are of a similar nature to the factors that shaped DevOps.
With recent software delivery processes, for example, the Agile process and Continuous Integration (CI) and Continuous Deployment (CD)of code, the DevOps approach provided a faster highway to ensure faster delivery with low risks. So the earlier SDLC model got redefined over time with Agile and then with DevOps to its current shape.
However, because design is an integral part of any product delivered, there is a need to ensure that gaps are bridged between the traditional design lifecycle and the fast track of the DevOps development lifecycle. DesOps and DevOps both are complementary to each other. The design delivery process improvements try to optimize the overall delivery process and thereby contribute to DevOps, for example, in aspects such as testing of the product that involves design aspects, usability, accessibility, etc.
The need for tighter integration between the design team and the engineering team became a necessity to ensure to design at scale. During the past two to three years, the top five big companies have made heavy investments in this area that have paved the way for other organizations and design communities to be more explorative in this area.
Continue reading “DesOps is “DevOps 2.0””
DesOps, aka. DesignOps, refers to an approach to design that is inspired by the culture of DevOps. In this and the following posts, we will explore, the practical approaches for
- How to prepare for the next wave in design that compliments the DevOps concepts of a cultural shift, collaboration, and automation.
- We will also see what solutions are available today that contribute to bringing the full circle of design in the context of the software development lifecycle.
Today, design as a discipline is getting more and more recognition across the entrepreneur world and many industry efforts, such as IBM‘s Enterprise Design Thinking framework, Red Hat‘s Open Studio and similar ones, are at a large scale, trying to create a synergy between the Agile approach to the software development lifecycle and the Design Thinking. It is an interesting crossroad where the next big thing in product delivery is to bring scalability as well as automation to the creative process.
In the context of the software industry, I always see “design” as an intersection between creativity and technology where both shape each other—with help from user needs—and blend the results into successful products.
Any typical software product that is delivered involves many complex as well as divergent technologies, processes, people, and visions. Though software delivery mostly happens with team members segmented into two major groups—developers and designers—ultimately, the best outcome always depends on how the two teams communicate with each other and how efficiently their thoughts and ideas are shared, propagated, and translated.
Continue reading “DesOps – The Next Wave in Design”
This article is the final in a series taking readers on a journey to peek inside life in a Red Hat Open Innovation Labs residency.
This is the top-tier experience for any customer*, exposing them to open collaboration, open technologies, and fast agile application delivery methods.
This experience often escapes organizations attempting digital transformation, so through submersion in an Open Innovation Labs residency, Red Hat shares its experience in managing, developing, and delivering solutions with communities, open technologies, and open collaboration.
Join me as I share experiences from inside a real-life residency, watching Red Hat work intimately with a customer, exposing new ways of working, leveraging open technologies using fast, agile application delivery methods and open collaboration.
In the first part, I shared what’s in a Red Hat Open Innovation Labs residency. Then in part two, I looked at what I encountered as the residency progressed towards delivery. All that’s left now is to share the delivery week, known as Demo Day.
Continue reading “Inside a Red Hat Open Innovation Labs Residency (Part 3)”
This series (see Part 1) takes the reader on a journey, taking a peek inside a Red Hat Open Innovation Labs Residency. A top tier experience for any customer*, a residency exposes them to open collaboration, open technologies, and fast agile application delivery methods.
This experience often escapes organizations attempting digital transformation. Through submersion in an Open Innovation Labs residency, Red Hat shares its experience in managing, developing, and delivering solutions. This is about successfully achieving organizational goals using open communities, open technologies, and open collaboration.
Join me as I share experiences from inside a real life residency. Watch how Red Hat engages intimately with a customer by exposing them to new ways of working. It is demonstrated by leveraging open technologies using fast and agile application delivery methods with open collaboration.
Continue reading “Inside a Red Hat Open Innovation Labs Residency (Part 2)”
During Red Hat Summit, I was part of what we called Birds of a Feather session; this is the type of session where you place a bunch of people in a room to talk about a topic with no agenda or solidified content. The topic for the session was “Agile Software Development – the Red Hat Way.” The panel consisted of engineers, product managers, customer support reps and program managers who work on our product line using the agile methodology. The focus was to have an open conversation about how we work at Red Hat.
Continue reading “Agile Software Development – The Red Hat Way”
So, my first programming job was part of the Duke Basketball IT department, while I was enrolled as an undergraduate. To be fair, it wasn’t really a programming job, mostly just churning out scouting reports and videos, but it was a lot of fun. I really liked basketball back then. I wasn’t any good at it but I enjoyed playing all the same, and I had a lot of fun watching it. And as most people know, the culmination of the college basketball season is a 68-team single elimination tournament called March Madness. And it is just that, Madness; employee productivity plummets, players, coaches, and spectators spend thousands of dollars traveling all over the country with a single day’s notice, and a lot of scouting reports get generated. Most people look forward to it, both the participants and the fans, but due to a series of mistakes and poor decisions, I have grown to dread March Madness…
Continue reading “A Post Mortem on Madness, or Why Process Matters”
Intel Developer Forum 2016 (IDF) produced quite a few announcements this year, including the Joule, a powerful IoT dev kit. Although targeted at makers, Intel and partners spoke about how this Joule can be used for industrial IoT use cases — cases like augmented reality safety glasses for manufacturing environments from PivotHead.
Continue reading Intel Joule Debate: A maker platform ready for widespread IoT use?
Deeper In the Engine Room
Fundamentally changing how people work isn’t easy. When you’re midstream on a large strategic integration initiative, it’s even more difficult. (See here to get up to speed on how far we’ve come). Due to these challenges, there are a couple of things we kept in mind as we progressed as well as learning a few additional things. So we wanted to dive a bit deeper in the engine room and share with you two of the biggest lessons: how to operate with globally distributed teams (I’ll follow the sun) and keeping in mind what really matters (the Importance of being Earnest).
Continue reading “Pivoting at Speed to Scaled Agile and DevOps – Chapter 3b”
In the current world of DevOps, Continuous Delivery, Microservices, and PaaS many organizations want to know how Software Governance practices and requirements fit. Some of this comes from a regulatory perspective, ensuring compliance (e.g HIPAA/PHI, SOX, PCI) and auditing requirements are met. Another perspective focuses on existing technology standards, design practices, and application architecture. At the same time developers and teams are being told to be more agile, adaptable, and self-directed. How do we achieve the latter while mitigating the risks associated with the former?
I would argue that a “Descriptive” approach to Software Governance is required. In my perfect world, Solution Architectures are monitored for exception as they progress through the delivery process. The technical underpinnings of systems, in terms of infrastructure and software, are “described” in code and configuration that can be easily audited against established policies. The runtime implementation of a particular solution is then transparent to all interested parties. In many ways, this is just an extension of Open Source practices to the delivered solutions and systems themselves.
Continue reading “Shouldn’t Software Governance Practices be more Descriptive than Prescriptive?”
Chapter 3 – In the Engine Room
The old idiom “the devil’s in the details” couldn’t apply more to our initiative. We have six global development teams that were executing in waterfall that we’ve essentially restructured and told them to do agile. To catch up on how we got here see Chapter 1 and Chapter 2.
Sound like a recipe for disaster? It could very well be, but seeing that we’re at a position where we can only improve, the gamble may just pay off.
Coal Power before Steam
Remember the Integrated Delivery Teams from last time? We now have six IDTs each having their own set of outcomes to achieve. The outcomes are the discrete business capabilities from end-to-end potentially spanning multiple systems. This alone is a huge benefit in that we’ve removed the artificial barriers to cross-team communication and, at the same time, given a group of people a common mission that if they meet, will demonstrate complete business capability and value. But how do we actually get to a state where we can execute?
Continue reading “Pivoting at Speed to Scaled Agile and DevOps – Chapter 3”