It still amazes me how, after all the time and effort spent trying to figure out how to manage and execute technology projects, that some fundamental issues still remain. The foremost of these is: did we achieve the business value (when and for how much we said we would). Waterfall wasn’t great at this, Agile got better, now it’s on to DevOps. The problem is that most of us can provide examples where each of these approaches has failed and...
So here's are deal: We've created what we're calling "PaaS-Containers" in our IT production environment. It consists of core technologies like RHEL Atomic Host, Kubernetes, and Docker along with supporting CI/CD components like Jenkins together as part of an offering that supports the end-to-end automated deployments of applications from a code-commit event through automated testing and roll-out through multiple environments (dev, QA, stage, prod). Oh, did I mention that it's also integrated with our enterprise logging and monitoring as well...
Imagine this: deploy an application from code-commit to qa, validate through automated testing, and then push the same image into production with no manual intervention, no outage, no configuration changes, and with full audibility through change records. A month-and-a-half ago, we formed a tiger team and gave them less than 90 days to do it. How? Build an end-to-end CI/CD environment leveraging RHEL Atomic 7.1 as the core platform and integrating with key technologies like git, Jenkins, packer.io , in...
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...
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...
Chapter 2 - Turning on a Dime Being able to respond quickly to a changing environment is what businesses aspire to but also something that is ingrained in our humanity. Having a large program that needs to adjust course in order to avoid disaster is easier said than done. Last time we fixed the radar and realized that without changing course, we were likely headed for just that disaster. Of course, knowing you need to do something and actually doing...
Chapter 1 Typically, the two biggest impediments to scaled agile and DevOps are over planning (including over thinking) and dogmatism. Which projects should we “pilot” for scaled agile, how long should the pilot run, what are the details of how we will implement, etc., etc. Of course, this over-thinking ultimately impedes the type of progress that scaled agile hopes to achieve in driving business results. But what if you don't over think and intentionally decide to be agile about being...
From Barry Manilow to Kiss, to Mary J. Blige and everyone in-between, people have been singing Talk to me for decades. And is it any wonder? Often we don't feel heard or feel that we don't understand what people are trying to say or do. In the fast pace of today's business, effective communication to get everyone on the same page quickly is essential. Needless to say, this isn't always easy. Given that we have to communicate effectively and the...
Article
