DevOps is unique for each organization but the 3 key areas that are common to almost all DevOps methods are asset management, CI/CD and monitoring. Below you will find a 3 Point Health Checklist for DevOps practices complied from our years in working in multiple industries/sectors including healthcare, finance, and more!
So you’ve got the Atlassian Suite up and running. Jira, Confluence, and maybe some other products too, like Bitbucket and Bamboo. Life is great!
Or is it?
Unfortunately, we often hear from customers that their Agile Lifecycle Management (ALM) suite hasn’t turned out to be the utopia they expected when they first installed it. This isn’t a problem limited solely to Atlassian products, of course - others, such as Version One and Rally can also prove troublesome to organizations. But today, we’ll talk about some of the problems commonly found with the Atlassian suite of products, and how we address them.
It’s not all about the team.
For Agile to work in a large program or a large organization, the cross-team issues are even more important than how well teams function individually. This is a common phenomenon in the world: that relationships between things are even more important than the things.
Teams are not constrained by how much they can learn. They are constrained by how much they are allowed to try, as well as by how much they don’t know what they don’t know.
When Agile adoption struggles in a large organization, it is almost always because managers are in the way—that is, teams are blocked by rules or upper level decisions—as well as because teams don’t know that there are better ways than what they are accustomed to doing. Those are the two predominant kinds of constraint on performance that one tends to see.
Rules exist for a reason: to manage risk. It is therefore unreasonable to expect that managers will just say “Do whatever you think is best”. To say that would be to abdicate their responsibility to manage risk for the organization. Doing that would also lead to chaos: each team would invent its own methods, and so the organization would cease to be one: it would devolve into a collection of tiny tribes.
There is a trend today that I find troubling: non-technical release train engineers, Agile coaches, or others in Agile leadership roles who are non-technical, leading the way for Agile ceremony planning without including technical thought leaders who know the technical side of Agile (which today is CI/CD).
Technical practices are the backbone of Agile. It is the technical practices that make Agile possible. If you don’t center discussions around technical enabling practices, you are wasting your time.
Don’t get me wrong: there are non-technical things about Agile. Things like a Lean Portfolio, retrospective, and backlog grooming. But if you want to improve those processes, you have to include a discussion of the technical enablers that make improvement possible.
In the third and final episode of our Agile Coaching Intensive series - Ken Fritz (Director of Software Delivery) overviews the agile coaching roadmap and key agile mindset shifts that come along with agile coaching. Watch this episode to unpack the career path and impact of an agile coach.
In the second episode of our Agile Coaching Intensive series - Ken Fritz (Director of Software Delivery) overviews the who, what, when, where and why of an Agile Team Facilitator. Watch this episode to unpack the evolution of an agile team facilitator in career path of agile coaching.
In the first episode of our Agile Coaching Intensive series - Ken Fritz (Director of Software Delivery) overviews the four main pathways of an agile coach's career and how the agile coach interacts with the rest of the organization.
In order for an organization to be successful with Continuous Business Value Delivery® the organization has to set a new destination and has to create a “new” route to reach this destination. This means, we have to REVERSE ENGINEER the entire delivery process to maximize value creation at a rapid pace.
The three key areas that need to be lean and automated, the foundations of a Release Oriented organization are 3 major process areas:
There are many considerations on how to make the move from Project Orientation to Release Orientation. Probably more than any other, the key is a belief in moving your organization’s mindset to the new of way of thinking and recognizing that the value of the old project container has vanished in an agile delivery model.