Ever since John Allspaw’s “10+ Deploys a Day” and Patrick Debois coining of the term “DevOps” in 2008, DevOps has been transforming businesses in terms of software development and deployment. The DevOps culture has enabled teams from the software development and IT operations to collaborate and develop more reliable products, as well as respond to customer needs, to achieve business goals.
The increasing number of businesses utilizing DevOps platforms to enhance business operations has fuelled demand for advanced IT transformations. In fact, according to PR Newswire, the global DevOps market is projected to be valued at over $23 billion by 2027, with the U.S and Canada as major contributors.
The last decade has seen a lot of companies accelerating their digital transformations to improve software delivery. To keep up with the demands of a rapidly evolving business and technology landscape post-pandemic, the DevOps community continues to improve its practices to i...
enever there is a product for a customer, there is a value stream. Wh
-John Shook and Mark Rother, Learning to See
Creating more value for customers is a core business strategy. With more technologies being developed, companies have been optimizing their software delivery to get the best value out of their products or services. Instead of focusing on individual functions, companies are now developing an interest in the end-to-end value chain. Software development is no longer just the business of IT departments. Company leaders and management are taking an active role in making sure that the software delivery process is driving value to the business. In a way, every organization has become a software company.
Unfortunately, even after investing considerable time and resources on IT transformations, companies still experience misalignment in business vision, strategies, and goals. While they may have implemented new ways of working, such as Agile and DevOps, there is often a disconnect bet...
In previous posts, we discussed what you can learn about your team from tracking a minimum of data. We introduced throughput as the most meaningful metric you can get from only the completion time of a work item. In a subsequent post, we explained how you can calculate cycle time and work in progress by tracking the start time of a work item. In this post, we focus solely on how to calculate failure demand and what it tells you about the true delivery capacity of your team.
Introducing organizational change is a tricky business, especially when it involves new technology. Even seemingly innocuous changes to technology can have a far-reaching impact on your organization, disrupting the ways you work. Your initial vision of a smooth implementation, rapid adoption, and a high return on investment is easy to say, not so easy to achieve. For example, it is widely discussed that 70% of transformations fail.
Following on from my blog post covering the first two ideals from the Unicorn Project here, I’d like to continue discussing the next two of the five ideals from the book.
The next two ideals from the Unicorn project focus on two important factors of the improving flow in your organization:
Continuous improvement of work
Part of the continuous improvement of work talks to the importance of challenging the status quo, something that can be difficult without psychological safety. Both are necessary to deliver better outcomes from working together.
Let’s delve into these two ideals.
As we introduce technology into our organizations and transform the way they deliver value, bureaucracy is often cited as a common barrier. So why have it at all?
As organizations grow, the “side of desk” style of management eventually starts to fail. Communication becomes more complex as you add more people and more teams. For the company to continue delivering high-quality value, they put standards into place. Governance exists to support the continued delivery of business as usual and the satisfaction of regulatory requirements. However, too much management feels bureaucratic. What would be great would be to have just enough to support your governance needs without hindering innovation.
So how do you create your Minimum Viable Bureaucracy (MVB)?
Today I want to talk about a common digital transformation topic I get asked about, application modernization. More specifically, how everyone is doing it but so few successfully. Typically the conversation starts with one of the following:
“I need to move off my legacy system, how can I use containers to do this?”
“How do we move to a cloud-native microservice architecture?”
“We’ve been told to move everything to the cloud, how do we do that with thousands of applications?”
Often, my initial answer is another question: “Out of curiosity, how did you get to this as your solution?”
Strangely, at that point, it often falls off the rails.
I’ll answer these questions in more specifically at the end, today though I want to talk about complexity and the need to experiment.
One of the biggest problems here is that these are all solutions looking for a problem. While we hope they may be appropriate solutions, hope is not a strategy. On their own, there is not enough information to provide guidance an...