OKR. OKR. OKR. If you’re like me, you’ve seen this acronym everywhere. OKRs, or Objectives and Key Results, are the latest craze in Enterprise and Strategy management. They sound simple and straightforward enough, but writing an effective OKR can be much more challenging than it seems.
We’ve heard the message of DevOps: Automate Everything.
Automate code testing. Automate workflows. Automate infrastructure. Create the no-touch deploy. Empower the application developer to deploy directly into production. Sounds simple enough, right?
As your organization begins its DevOps transformation, you may become preoccupied with automation, forgetting that there are other DevOps concepts to address in your environment. The Scaled Agile Framework® references CALMR (Culture, Automation, Lean Flow, Metrics, Risk & Recovery) to highlight the importance of more than automation in DevOps. In this article, we’ll address the other concepts to keep in mind while on the DevOps journey.
DevOps is a market buzzword, with nearly every enterprise trying to implement DevOps to remain relevant in their industry. When I was first introduced to DevOps, I was skeptical—over 40 deployments in a day and 200x shorter lead times? I was extremely concerned about the security and robustness of these builds being deployed, as the only artifacts to support this were from smaller companies. There was nothing to prove that DevOps worked in large enterprises.
How does a Scaled Agile Framework® (SAFe) Transformation stick and sustain? An important key to success is having communicative leaders who commit to organizational culture change. While this commitment is best obtained from the C-suite or VPs early in the sales cycle, it is also the hardest. SAFe Transformations tend to start and stop in the IT department, where the primary goal is to produce a faster software development lifecycle.
Agile is disciplined; not reckless.
“That’s not how we do things here.”
“That will never work for us.”
“That’s not our culture.”
Sound familiar? Maybe you’ve heard or even said one of these phrases before. If so, you might be trudging through a Scaled Agile Framework® (SAFe) Transformation.
If you think that your SAFe Transformation is doomed to fail because your organization is unique—so unique that industry best practices couldn’t possibly apply to you—then let’s dispel that myth right now. That's not why SAFe Transformations fail. Sure, context matters, but at the end of the day, large enterprises across all industries have the same problems.
...Because the world is moving too fast not to be Agile!
At the XP 2002 Conference, The Standish Group showcased their study of how often features were used in a typical system. According to the results, features were used “often” or “always” only 20% of the time. 15 years later in 2017, after the software development world had largely embraced incremental delivery methods, the Standish Group conducted the same study again. The result? Still only 20% of features were used “often." There was little to no significant change.
If you’re a newly minted SAFe Program Consultant (SPC), then congratulations! After all your agile/project/program management experience and diligent studying to pass a difficult exam, you deserve a sense of accomplishment. However, as you may already suspect, your journey has only just begun. To be an effective SPC for years to come, more will be required.
Today’s topic is near and dear to my heart. I’ve had the opportunity to work with and observe several great SPCs during the last five years, and I’ve learned nuances and success patterns for the multifaceted endeavor of becoming a great SPC.
Have you ever said a word to someone, let’s say “puppy,” and got a positive reaction from one person, and a negative reaction from someone else? Why is that? It’s the same word! It turns out there are two types of meanings to words, and it’s the second type that makes all the difference in the world.
A colleague suggested I write this article, and I quickly agreed, thinking to myself, “No sweat! There are so many little things that can make a big difference. I can type this out in no time.”
Now pause. Go back and review that last thought. Do you see a flaw in my logic here? “There are so many little things...I can type this out in no time.” Did I really think a long list of things would make this task any easier? That it would make the writing process fly by?
As a leader, how do you create an environment that is nimble enough to thrive in an era of digital disruption?
Certainly not through “Command and Control,” which has been the prevailing management model for decades. Nothing limits creativity or the growth of new leadership quite like an “I know best” attitude. So what’s a better alternative?