Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
SAFe® has always been a controversial topic within the agile community. Therefore, back in 2017, I ran a first survey on the Net Promoter Score® of the Scaled Agile Framework SAFe®. The result back then was -52.
Four and a half years later, I reran the poll: SAFe® has been through several iterations, and many more agile practitioners have experienced working with it. However, the question still is: Would you recommend SAFe ®?
A few years ago, when companies started embracing Agile, they would bring in a consultancy firm to help come up with a strategy for the shift. They would hire some Scrum Masters, provide basic training to their teams, and proudly declare: “We are Agile now.”
But that statement couldn’t be further from the truth. More than a methodology, Agile is a philosophy, and adopting it means that everyone involved should get on board with a complete and profound transformation. A transformation that, oftentimes, fails.
Let us glance into the below Principles of Agile
When we would like to implement all the principles for the Agile team, how satisfied it would be when a team gets some natural technology booster?
In this highly engaging speaker session from the Agile Camp Berlin 2021, Scott Weiner shares a case study on how to master an agile transition by creating agile resistant teams based on common sense, team autonomy, and the psychology of metrics.
Agile teams don’t begin as Agile teams. They begin as a group of people with a purpose. Sometimes those teams want to embrace Agile approaches because they believe they understand the benefits and see a path forward. Often times that path is more difficult than they thought because they misunderstood the subtlety and importance of various aspects of the agile mindset and various methods. Often the team will ignore or misunderstand the significance of the external environment on their ability to be successful and will fight the wrong battles and become frustrated and even feel defeated sometimes. Other times agility is (ironically) mandated by the larger organization looking for perceived benefits or just looking for a level of standardization of methodology and approach.
In this highly engaging speaker session from the Agile Camp Berlin 2021, Viktor Cessan shares lessons learned as an Agile coach when working with systems, resulting in evidence-based interventions.
When we, as managers or coaches, are asked to work with a system, there’s always more to a situation than meets the eye. In this presentation, I take you through common requests I’ve gotten as an Agile coach, and I contrast the initial request and understanding with what we discovered was actually going on, and what we did. I also share some tips for anyone working with systems in their day-to-day work.
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. When Scrum becomes an element of an agile transformation, the following three common essential agile failure patterns prove to be an exceptionally tough nut to crack for any Scrum Master.
Join me and explore the consequences of foreseeable failure patterns and what you can do about them in a little more than seven minutes.
Johari window as a concept comes from the study done by psychologists Joseph Luft (1916–2014) and Harrington Ingham (1916–1995) in 1955 and is used primarily in self-help groups and corporate settings as a heuristic exercise.
[Announcer] This is Mike Cottmeyer’s talk from AgileIndy, 2021 on “Why Agile Transformation Fails.”
– Okay, so we’re gonna talk about today is this thing I call “Executives Guide to Why Agile Transformations Fail.” And if you’ve been following my stuff, there’s really kind of a fascinating evolution of this story. So I got involved with agile back in like 2003 and I was working in this company called CheckFree. We were doing like large online banking bill payment kinds of things. And so my indoctrination to agile was never ever in the small. It was always large-scale agile stuff. And I was working for this VP that was like really super cool, is very into agile and we were coming up with really creative things for like team formation strategies and agile governance, all stuff. And this was like way before the days Dean Leffingwell hadn’t even written his first book on scaling. None of the stuff on scaling was out there. So we’re inventing scaling models and really trying to bring this. It was like these four or 500 people, this organization through an Agile Transformation. And so I started writing about multi-tier models and different teaming strategies and things like that and then I went to go work for version one for a couple of years. You guys remember them? It feels like I talk about them and I don’t even think they exist as a thing anymore. Version one CollabNet or something, I guess I call them now. So anyway, kind of a different company, but worked there probably about 10, 12 years ago and was going into a bunch of different organizations that were trying to adopt agile. And then the process developed a point of view around kind of why companies were jacking it up. And so I did talk on the three things and then we came up with this talk. It was just why agile fails. And the hypothesis behind that rev of why agile fails was largely about people trying to adopt practices of agile, and whether it’d be Scrum or extreme programming or now SAFe or LeSS or disciplined agile delivery, something like that, trying to adopt the practices of agile without the words I would use now, but I wouldn’t use them, the business architecture necessary for those practices to work.
One of the challenges I faced in my Agile coaching journey was to identify and determine the right coaching strategy based on the team dynamics at play. As we all are aware, each individual in our teams has got a unique set of emotions, priorities and they exhibit unique behavior patterns and personalities. As an Agile coach, it is important for me to identify these patterns and come up with a coaching strategy for implementation and execution.
Based on the numerous coaching sessions and experiences, I have come up with an interesting tool leveraging the gamification way. This involves using a standard deck of playing cards.
When asked by the editor of the online science and technology magazine Edge.org to share one brilliant but overlooked concept or idea that he believes everyone should know, the Nobel laureate Richard H. Thaler, father of behavioural economics, former president of the American Economic Association and an intellectual giant of our time, did not hesitate. “The Pre-mortem!”, he said.
The idea of the pre-mortem is deceptively simple: before a major decision is made or a large project or initiative is undertaken, those involved in the effort get together to engage in what might seem like an oddly counterintuitive activity: imagining that they’re at some time in the future where the decision/project/initiative has been implemented and the results were a catastrophic failure, then writing a brief history of that failure - we failed, what could possibly be the reason?
Large scale change initiatives (Lean, Agile, etc.) have a worryingly high failure rate. A chief reason for which is that serious risks are not identified early. One way to create the safety needed for everyone to speak openly about the risks they see is by running a pre-mortem workshop. Pre-mortems leverage a psychological technique called ‘prospective hindsight’ – imagining that the transformation had already failed, and walking backward from there to investigate what led to the failure.
When asked by the editor of the online science and technology magazine Edge.org to share one brilliant but overlooked concept or idea that he believes everyone should know, the Nobel laureate Richard H. Thaler, father of behavioral economics, former president of the American Economic Association, and an intellectual giant of our time did not hesitate. “The Pre-mortem!”[1], he said.
There exist several software development life-cycle (SDLC) models giving different trade-offs between implementation complexity and speed, scalability, software quality, cost, and adaptability. Addressing controllability and predictability in large software products, the waterfall model was introduced [1]. Similar to the evolution of societies using bureaucratic models, software development’s evolution has been affected by the bureaucratic nature of the waterfall model since the 60’s.
In a waterfall SDLC, requirements gathering, analysis and planning are performed as an initial phase. Architectural design is then followed by software development and testing whilst deployment is the last phase. Large planning and documentation efforts are usually necessary upfront, in order that all deliverables achieve the expected quality at predefined milestones. Requirements are key to the success of waterfall software development. Clear requirements at an early stage should be available with little or no changes at a late stage. The problem is that there are customers that realize what software products suit their needs only after using several draft versions, making clear requirements at an early stage impossible. Even if the requirements are clearly defined, a customer’s major change request at the release phase may result in redesigning the software product from the beginning.
From my experience and observations, my concern is weak understanding that the Evidence-Based Management (EBM) framework is empirical. It requires transparency, frequent inspection, and adaptation. Some organizations proceed with the initial evaluation and then drop the idea. Measuring once and making some decisions is not enough! No promises that this would work.
Measuring often, regularly, making decisions, adapting frequently towards a meaningful goal. This is the secret ingredient of the powerful framework. Like Scrum, EBM is simple to understand, difficult to master. Once you experience it, implement it in your organization, you should see significant results.
Let me start by stating a simple fact: Information Technology is a key capability that must be mastered if you want your company to be leading within your industry. You do not have to take my word for it, Didier Bonnet and associates said it best in their “Leading Digital”:
We discovered all kinds of companies, both those struggling and those succeeding in the great challenge of becoming digital. [...] the companies that are succeeding — and they range across industries and sectors — we’re calling Digital Masters. And Digital Masters outperform their peers. Our work indicates that the masters are 26 percent more profitable than their average industry competitors. They generate 9 percent more revenue with their existing physical capacity and drive more efficiency in their existing products and processes.
The road to a successful Agile transformation is not an easy one. As the number of organizations deciding to embark on an Agile journey increases, how many of them are successful? VersionOne’s 13th Annual State of Agile Report states that 97 percent of respondents surveyed practice agile to some degree within their organization. However, only practicing the methodology to some degree, is one of the most detrimental mistakes organizations make, hindering the chances of a genuinely successful transformation.
The number of obstacles that stand in the way of organizations achieving desired results is exponentially higher than those faced by start-ups. Some challenges, like size, are beyond their control. However, there are common challenges that enterprises can avoid if they know what to look for.
How to make Scrum work? Read on to learn more about my top three objectives for Scrum Masters striving to achieve Scrum Mastery.
You may also like: Scrum 101: Everything You Need To Know
The Agile movement that took off with its formal journey around the turn of this century is turning 20 soon! Millions of IT professionals, consultants and academicians have read about, written about and practiced the Agile values and principles in the last couple of decades. That is testimony to how solid those principles are and how they are valid in the dynamic, ever-changing business and technology trends.
You may also like: Explore the Scrum Values Workshop
If you have worked in the technology industry during the last few decades, you have heard the term "Agile" more times than you can count.
Agile, DevOps–the industry tosses these buzzwords around like free candy. But how can companies become agile in today’s technology sector?