This isn't an ordinary Thanksgiving and the beginning of the holiday period. Looking back to my post last year on 5 reasons for CIO to be thankful for this Thanksgiving, I reflect on how much the world has changed since then. I look back even further to my 2013 post, a CIO top ten guide to preparing a Thanksgiving feast, and it's like staring at the green screen of a legacy system.
I rebranded this blog as Social, Agile, and Transformation over ten years ago, an instinctive change based on three fundamental changes I was sensing in the nature of business.
At the time, I led and witnessed a fundamental shift in how companies interacted with customers, the collaborative practices required to drive competitive advantage with data and technology, and how all organizations had to start digitally transforming their business models.
Let's stop bickering about technical debt and start doing something about it!
Here's why. In this week's episode of 5 Minutes with @NYIke, I share the differences between debt (including technical debt, data debt, and operational debt), legacy systems and practices, and a burning platform. You can watch the episode below where I share the types, impacts, causes, and remediations that characterize the differences between tech debt, legacy systems, and burning platforms.
In the episode, you'll see that while technical debt often impacts the people supporting technology or process, legacy systems impact the actual users (which can be customers), and burning platforms the business and brand. In many situations, what starts as debt, often progresses to legacy and sometimes to a burning platform.
Developing CI/CD pipelines, deploying infrastructure as code, leveraging git to manage source code, and choosing between containers, PaaS, and serverless infrastructure are established devops best practices.
And most IT organizations seek ways to align the development team's mission on deploying capabilities faster with their operational responsibilities in ensuring reliable, secure, and scalable infrastructure. Many organizations are shifting left security, automating testing, and deploying AIOps solutions as practices to cement this collaboration.
I have a very low tolerance for buggy software. And an even lower tolerance when the customer and technical service that follows it is horrid.
I'm empathetic to the business pressure to release capabilities and features, reduce technical debt, and improve integrations. Heck, I advise companies that digital transformation requires companies to experiment and deliver faster.
StarCIO's mission is guiding organizations on smarter, faster, safer, and innovative transformations that deliver results. Releasing buggy, broken, or unstable user experiences is not smarter, safer, or innovative. It just frustrates customers.
Product owners, tech leads, and scrum masters are three common roles you find on scrum teams. I've written about their key responsibilities such as product owners prioritizing backlogs, tech leads overseeing estimating, and scrum masters ensuring team collaboration and cohesion.
But how should these three leaders collaborate? How can they help agile teams successfully release quality products on schedule and delight customers, end-users, employees, and stakeholders?
I give a fast answer to this question in Episode 16 of 5 Minutes with @NYIke. Successful teams exhibit several behaviors that drive results. They do many of the following:
I cover the nuts and bolts in the video below. You may also want to check out my recent articles published on InfoWorld on How to mandate agility in software development, operations, and data science (hint - you can't) and 5 things CIOs want from app developers.
Let's call a spade a spade. We can call many processes "agile," and teams can claim that they are practicing scrum. Still, there are sizable steps going from following basic agile ceremonies to agile methodologies or cultures.
Specifically, teams are not agile if all they are doing is
