The "Craziest Things" with Methods and Frameworks ...feedback and comments
PLEASE, JOIN OUR NEW GROUP "THE CRAZIEST THINGS IN WORKING WITH METHODS AND FRAMEWORKS" https://lnkd.in/dmQwXys,
Hi,?this follows on from?my June article?which sparked a lively and constructive conversation on the?'Craziest Things in Working with Methods and Frameworks'.??
As of today, the article has received a stunning 278 reactions, and 143 comments. Positively, lots of the comments are lengthy discussions. Almost everyone agreed with the core of the “crazy things”, and that we collectively must work to eliminate them. Many prominent members from the software industry, including @Jeff Sutherland (Scrum and?Scrum@Scale), Scott W. Ambler (Disciplined Agile) and Joakim?Sundén?(the Spotify Model) have reacted positively.?
This is a wonderful start. However, there is dramatically much more we all can do together to eliminate “crazy things”. Essence is not a silver bullet; however, it should be enough to show that there are solutions to be found.?
Let’s:?
1. Work together to address “crazy things”, not just the ones identified in the article but many more that you have experienced. If you are?interested?please join our?new LinkedIn community group, “The Craziest Things in Working with Methods and Frameworks”, to discuss all this and more. Alternatively, contact me:?[email protected]?.?
2. Discuss them openly and professionally. I have gone through all substantial comments?on my original?article,?and?make them available for further discussion. You can find them further down: "Comments from the community viewing the LinkedIn article". Many of these comments deserve to be discussed separately. Authors, please trigger such discussions.
Moreover, please, tell everyone you know. Thus far,?just less than 2,500 people have viewed the article.?
3. "Meet” and debate them. The ‘Essence for Agility’?MeetUp?group (https://www.meetup.com/essence-for-agility/) plans regular meetings with top industry speakers such as Jeff Sutherland, Scott Ambler, Joakim?Sundén and many more. This is a great opportunity to debate the subjects related to the future of software engineering and have your voice heard.?
Come along and do something?really meaningful?for our developers and others concerned with methods and frameworks.?
Cheers?
--Ivar?
Comments from the community viewing the LinkedIn article.
June 1, 2021 I wrote the LinkedIn article ’Some of the Craziest Things in Working with Methods and Frameworks’ and today July 5, we have got 278 reactions, 143 comments most of them substantial, but only 2,700+ views. Imagine we had received say 10 times as many views, would we have received 10 times more reactions and comments?
I have gone through all comments and classified them. The full analysis is here. To give you an idea of what kind of feedback we have got, I will first make an extract of all comments.
I have identified the following kind of comments:
1.????Unhesitating agreement and support
2.????Full agreement but with a twist.
3.????Not in disagreement, but discusses a related issue. Many of these comments are very interesting and deserve separate discussion. This would be most welcome within our group.
4.????Skeptical at first but after some counter argument, seemingly in agreement. More discussion within our group very welcome.
5.????From well-established method experts (Scott Ambler-Disciplined Agile, Jeff Sutherland – Scrum and Scrum@Scale, Joakim Sundén-Spotify)
There were no direct disagreements with the article, but some comments discussed a related issue and could be viewed as being opposing opinions.
Many people have asked where they can learn more about Essence. They can do it here.
1. An extract of all comments
Unhesitating agreement and support
25 comments were of this nature. Here, please find some examples:
I agree on your list of crazy things. I'm looking at ways on how to overcome them, but it ain't easy. How can we help our workforce to adopt the methodology and don't fallback on their gut feeling, how can we prevent that Achilles heel to happen which you describe.
As you mention, coaching is not enough, we see this in practice. I do co-creation/collaborative methodology development with end-users and stakeholders. That seems to be working to some extend. It does not come over as the theoretical methodology but as something they build themselves. Of course trade-offs have to be made, but it is easier for the analysts to understand the reasonings behind them.
Ivar: Stijn, the best response I can give is a reference to another article I wrote titles "Curing the Achilles' Heel of Method Adoptions" https://www.dhirubhai.net/pulse/curing-achilles-heel-method-adoption-ivar-jacobson/.
Simply beautiful - thank you for sharing this food for the troubled Agile Landscape mind ;-)
Could not agree more with you after experiencing the "War" throughout my career.
Spot on, mister Ivar Jacobson. One of the most striking things to me is the fact that some frameworks tend to "adopt" certain practices, change them slightly to make them their own, only patting the shoulder of original inventor, but nothing more. When the last major version of a certain framework for agile in a scaled context got announced, some of the "sect members" were cheering, because a certain business concept got introduced. I was like: "Oh no! What's next?" Sometimes things get too big. And the companies implementing these frameworks need to be very cautious not to step into the pitfall of "it is in the book so we have to do it this way", or "it is not in the book, so we cannot do this".
How to deal with the impediments you mention? Maybe it is time for a next level agile manifesto, that focuses on the common ground and interchangeability of practices?
Ivar: Actually, in 2009 SEMAT wrote a "call for action" which is similar to a manifesto with the purpose you suggest: https://semat.org/call-for-action
What is needed now, is that more people engage in discussing and implementing the vision.
Hi Ivar, thanks for sharing your thoughts and your list. Because you asked: I agree with your list. And I am in to do something about it. ?? ??
?
Full agreement but with a twist.
11 comments were identified to be like this. Interesting group so I have kept 6 here in the extract.
Ivar - great article and I totally agree with the crazy things list. The question now is what to do about it. For example if we want to end the language wars, which language do we adopt as the one ‘common language’ and how do we do that without at the same time creating yet another method by another name? The goal, I believe, is to learn from them all, and use the mix of approaches that fits the particular situation without letting any brand allegiance get in the way. So I think it’s this attitude more than developing a single lexicon across frameworks. I share the desire for a commonly understood language (it was behind my strong support for uml), but my fear is that the quest for a textual one may end up following the fate of Esperanto. Any thoughts on how to avoid that?
Ivar: Let's first say a few words on UML. UML could have been great, but it became too big. It had no kernel of basic stuff that everyone could agree upon. On top of that kernel we could then add special packages of language constructs that were needed in more advanced cases. I have many times said that 20% of UML would be enough for 80% of all applications. See my paper The Road ahead for UML published in Dr Dobb's Journal.
Thus, it is different. There is a common ground, a kernel, for all methods and frameworks called Essence. It has gone through a long process to become accepted as a standard. It includes only things that everone easily could agree upon...that is why ít could become a standard. On top of this standard many methods are now described. The practices are liberated from their methods, free to be used by anyone to create their own method.
We are not far off from getting rid of the craziest things in our world.
Howard: Thanks, Ivar. I've only begun to learn about Essence through your presentations. I'm excited to learn more.
I agree it is a shame much if this comes down to “religion wars” but I think most organizations want a set of practices that function well together (e.g. framework) to start with, one they can trust has come from expert experience, and then when they gain a level of fluency, want to be able to do some tailoring without breaking the essential elements of the practices in the framework (without unraveling the tapestry so to speak). It’s this tailoring part that I think has been overlooked a lot as one size really doesn’t fit all. Essence is an approach that could help with both - understand a framework starting point, truly understand the essentials of the cohesive practices in it, and then help users tailor without breaking.
Ivar: It is good to have a starting point, but why have to use a framework that has no common ground with other frameworks. Why not use a framework created from an ecosystem of practices which you can mix and match practices from. Now, you have to select a framework which has nothing in common with other frameworks. That is the crazy part of it.?
Jeff: Agree. Just saying I think people will always want packages to start with where they feel there are support and available resources to get started and then move to more personalization. Ideally all the practices and frameworks could be modeled in Essence so people can get started with a package they believe suits their need initially and then use the models to tailor, mix/match, etc with more confidence.
Methodology wars - that's what I call them - have been around at least since the '80s, and as you point out, we do not seem to have made progress. I strongly suspect that the reason for this is threefold:
1. There is lots of money in software development and IT consulting - The "Agile Hustle" is on, with people supporting one or the other methodology, without understanding the basics (what you refer to as common ground). In short, overall folks are too invested in the process (how) instead of the outcome (what). After all, all those certifications qualify them as "gurus"
2. Experience is hard to find and even harder to attract and the overall tech industry has consolidated. Whereas 30 years ago I had the opportunity to work on operating system development, Smalltalk compilers, and software utilities, the market has changed and consolidated. The result is that few experienced folks either are working for the mega players like FB, Amazon, MS, while all others work in "IT" - yes, there is a difference between software engineering and IT, and I suspect that IT projects fail at a higher rate
3. Experience is not valued any longer due the fast pace. Every company has to do software now, but few really want to. And the ones that really don't want to do software hire less experienced folks - or look exclusively at the labor rate.
All this results in just as many projects still failing despite the fact that good Agile practices are available.
My basic principle is to focus on business value, while method is not a goal on its own. Having said that, organizations should explain better to their co-workers the sensegiving of a method: why is it needed and what is in it for them? On the other side organizations can make method adoption compulsory to some extent through gatings, QA and personal objectives, while providing proper method support. E.g. fit for purpose method documentation, personal learning/growth plans, high quality trainings giving by inspiring trainers, a method tailoring mechanism, well trained and sufficient coaches and mentors, method adoption workshops, active & fun communities for knowledge sharing. Apply system thinking and root cause analysis to poor method adoption to find your improvement actions in method adoption.??
Ivar: Great list, but the biggest challenge is what I call the "Achilles' Heel of Method Adoptions" https://www.dhirubhai.net/pulse/curing-achilles-heel-method-adoption-ivar-jacobson/. There are not enough "well trained and sufficient coaches and mentors".
Great great article- so many of the principles and practices in all the methods are based on a common sense approach to real problems. The challenge is when time is not taken to understand the intent behind the concepts and the problems they are trying to solve. Rather there is a desire to plug and play and expect it all to work magically. So many major organisations spend gazillions on transformations looking for a plug and play approach because maybe it worked elsewhere in some guise, but not understanding the problems of that organisations and the actual journey they went on. Snake oil salesman and silver bullets are so prevalent - method wars and what you call the prisons are a large part of that.
Method war - absolutely mind boggling. One method is usually purported to be better than the other usually without any empirical evidence.
Why can’t we have a goal, use a method, try to meet the goal, reflect on why it did or did not work, and collect context specific evidence, improve ... repeat.
?
Not in disagreement, but discusses a related issue
17 comments of this nature. I kept 7 to demonstrate what people think off.
Maybe I am completely off-topic, but I will share an experience. For more than 25 years, I worked with many methods (including briefly OOSE :) in the software and IT services industry. And what saved me was knowing exactly what kind of software I wanted to build.
When UML was born, I was in the first France UML user group, and this was for me an historical milestone because the modeling language could be separated from the methodology! The modeling language was enabling me to think about the software, and the methodology - almost always dictated by managers that wanted to be "trendy" - was the way to build it. With time, I adapted to all methods by putting architecture and design first.
SAFe is no exception. This is the trendy method of the day, soon overcome by another method. I don't like this method because it pushes many organization not to think about the softwares they need, but to hyper-focus on a complex error prone methodology. This is aggravated when you don't have a precise idea of what you want to do.
But, if you know precisely what you want, you can adapt SAFe, and any other method, to fit your purpose. So, for me, the method is just a set of common practices that will be the common set of rules of the project and that cannot prevent you from doing what you intended to do from the beginning.
That will probably always be like that as long as methods will be at the core of "IT trends". We live in a very marketing inspired industry, and methodology is continuously instrumented by vendors to sell projects to non-IT people.
For sure, I would like the industry to progress to a core set of common practices (I remember a French initiative named Puma a long time ago) that could be adapted to the exact challenges of the software to build. But, I am not sure the IT world is evolving in that direction...
Link on Puma: https://www.entreprise-agile.com/en/Puma-en.htm and https://www.entreprise-agile.com/en/SolutionModelEN.htm . The creator of the method was Jean-Pierre Vickoff .
Ivar: Maybe you would like Essence?
‘Learn more about Essence’?https://www.dhirubhai.net/pulse/learn-more-essence-ivar-jacobson/
I did search in this article, how many times customer was mentioned? Zero. IMHO the craziest is that we focus too much on methods and frameworks. I believe in what was written in the agile manifesto: "Individuals and interactions over processes and tools". In order to "beat these abnormalities of our discipline" I help others to see "value in the items on the right, but value the items on the left more".
Ivar: Every method or framework must have great practices to deal with customers. And all the successful frameworks pay significant attention to customers. Otherwise, they wouldn't be successful. They most likely do it in different ways, and that is fine. However, the way they do it, is not easily reusable by anyone else. It is hard to learn from others. The practices are in method prisons.
I did a parody presentation for the Agile Lean Ireland 2020 conference on methods such as described as above. https://www.youtube.com/watch?v=VNUlBcRB7mo
The anti-patterns of Guru-led, Borg style absorption of others methods with no real deep understanding of them, and the general idea of selling the results of individual organisations successess to others by mimicking and without undergoing similar journeys, are all rife in the methodologist space.
However, I am not sure methodologists are the answer to this. Defining a "common language" will just lead to another cage with different gurus. RUP/SAFe keep reinventing after experiments. But the experiments are being carried out on peoples careers and companies. This is not right.
Methodologism should die, and in it's place be replaced with simpler "micro-methods" and practices, and safe-to-fail experiment-led self-discovery.
Ivar: "Defining a "common language" will just lead to another cage with different gurus." Not necessarily. The "common language" or "common ground" must be simple. It must be a standard so there is nothing controversial in it. Essence is such a a common ground. It is owned by a standard organ OMG, so no guru controls it.
Essence can also be described as an implementation of "Methodologism should die, and in it's place be replaced with simpler "micro-methods" and practices, and safe-to-fail experiment-led self-discovery." TRY IT!
i am not sure that a practice is comparable to a mini method. A practice is more guided by the heuristic of its outcome in my mind, and therefore more flexible to be adapted into its context. A method is more rigid regardless of the context. (only my opinion).
I also think that the method discussion is highly motivated by the need for rapid satisfaction. We are living a culture of instant gratification and Enterprises are no different: "We'll make a big investment for the problem to go away". When the challenges are systemic, organisational, leadership and human ... you don't configure People like software. The "outcomes" become long forgotten too. People focus on the "means" and become quickly lost in transformation.
Lastly, somebody helping to implement some methods is a trainer, consultant or at best a Mentor. Coaching has to do with the "Being", not the "Doing". "Agile coach" is an oxymoron. A lot more genuine coaching work should be done because it is fundamentally about behaviours rather than methods. But it does not help when coaching has been completely cannibalised as a term.
Ivar: Very interesting feedback deserving more discussion than as a reply to your comment.
1) "A practice is more guided by the heuristic of its outcome..." Practices can be defined on different levels of details...and methods too.
2) "The "outcomes" become long forgotten too. People focus on the "means" and become quickly lost in transformation". A focus on the essentials and with a great user experience including attention to the Achilles' Heel of method adoptions are a big step forward.
3) "Coaching has to do with the "Being", not the "Doing"." One of my "crazy things" is the reliance on consulting to bridge the gap between Learning and Delivering. https://www.dhirubhai.net/pulse/curing-achilles-heel-method-adoption-ivar-jacobson/
Ivar, my sense is that their exists an incentive to define the "One true way to success", the reality however is that the solution (as you articulate) is an amagamation of ideas from multiple sources. The solution then is dependent on the situation, the problem being that no single solution can fit the scope of all presented problems. In simple terms, one might observe there are two forms of insanity - great certainty and great uncertainty. The solution (arguably) lies in the center, where one is able to take aspects of various frameworks and apply them to the customer presented problem. Stay safe and well.
Good karam flying your way. Glad to see you are still creating thoughtful prose and problems.
Craziest? All the immature organisations that roll-out tools without training/coaching in methods:
Ivar: Absolutely with the addition, good teachers and coaches are hard to find. Simplify by Curing the Achilles' Heel of method adoptions https://www.dhirubhai.net/pulse/curing-achilles-heel-method-adoption-ivar-jacobson/
Method prison has both pros and cons, more pros and cons if u ask me. They create opportunities and roadmaps in nascent stages of learning for communities. IMHO, we should tread on this whole path a bit more cautiously. TX.
Ivar: The meaning of the term 'method prison' as used in the article is different. Practices are locked into methods (methods are prisons for practices) because practices are not simple to reuse by other methods. Hard to see that that can be good?
Skeptical at first but after some counter argument, seemingly in agreement
I classified 5 comments to this group, and I kept 3.
Let's not conflate 'industry' and 'discipline;' and I would argue methods are not theory but an application of poorly described theory. "Our industry" as used in the article seems to refer to those whose fame and fortune depend on promoting (individual or bundled) methods. This is where we have a legitimately competitive marketplace of those who "war" for their own method. The "discipline" of software engineering (SE, in that larger sense of the term as a subset of engineering) is, or ought to be (per Maslow's vectorial facts), based on a pragmatic epistemology. Method evolutions (by refactoring or practice adoption, adaptation, and pruning) tends to reflect this and seems to occur when 'crazy things' experts encounter practical needs of those organizations which employ their own industry (e.g. education, insurance, 'widget' manufacturing) methods. [Optimally, methods engineered within and for those industries learn from SE as well.]
Where we are shallow, I believe, is in appreciating and leveraging both 'hard' and 'soft' sciences behind effective SE. Let's distinguish between methods and methodology, regarding the latter as a science based in psychology, economics, logic (beyond Boole), operations research and other realms of discovery. Let's apply the learning from those who spend time understanding why a given practice succeeds or fails. Science, engineering, discipline, and industry require alignment; I believe methodologists need contribute more science -- theories and falsifiable hypotheses -- in the interest of freeing method prisoners and negotiating peace treaties on method war battlefields. My own goal, as time and the good Lord permit, is to contribute research on interdisciplinary bases of contemporary practice so we are better able to focus on why than what.
Ivar: Skip, I don’t disagree with anything you say. In my article I talked about the union of industry and software engineering to simplify. I also agree that there should be a competitive marketplace. However, it could be much better if we removed the crazy things.
Agree also that we could improve both soft and hard practices and patterns.
However, these points are not addressed by my article.
Skip: Long been a fan of your work, Ivar. Years ago taught RUP. Like any language, UML "trained my brain" to leverage a perspective and that perspective (if not the diagrams) continues to be helpful today. I think SEMAT reflected a disappointment similar to what you've expressed here, and value your standing aside from the methods fray to recognize its craziness. Essence was/is an attempt to bridge communities; my hope is to continue considering those theoretical aspects by looking across academic disciplines.
Ivar: Yes, Essence attracts not just software engineers, but people in any engineering discipline. With minor changes, just some generalization, it seems to work well with many other engineering disciplines. We have seen it being applied in system engineering as well as hardware engineering. Also as a platform for innovation practices.
However, my personal priority is software engineering, but I am open to later enlarge the domain.
Why on Earth would you want to standardise across methodologies?
Are we at that point whereby we have finally reached the zenith of our learning and developed 'THE WAY' to deliver?
Is there no further improvement which can be made to our practices?
Are there to be no further advances in physical or virtual tooling which might unlock new ways of working and necessitate new methodologies?
Let's face it, the reason why there are multiple methodologies which have all seemed to appear in a relatively short space of time is because industries have been going through an exceptionally turbulent and volatile time these past few decades. They've tried to adapt to the advances in technology and tooling to make best use of it all and stay relevant. This hasn't spawned from a single font of knowledge, it's emerged from a global consciousness in geographically dispersed locales. That's not going to stop anytime soon.
Just like the English language (now complete with emojis) methods of delivering best practise are constantly evolving. Like it or not, Methodology is the language of delivery. To standardise is to stay still and perish. The only constant really is change, and it is that which should be explored and exploited wherever possible.
Ivar: Now, there is no suggestion to standardise methods and frameworks (or methodologies for that matter). On the contrary, we would like to see many more such things than we see today.
Neil: Ivar Jacobson, except to say that it is "crazy" that they do not share the same common ground and taxonomy?
Now I certainly don't disagree with you from the point of view that it is certainly crazy for companies to overlook or reject a job applicant because they are not 'certified' in a particular method despite being certified in many similar ones. At the end of the day the act of software delivery isn't really that different across the industry.
Admittedly it does require different skills to manage as it scales up to bigger initiatives which require hundreds of developers. However these are skills in forecasting and aligning delivery and containing the activity rather than actually performing that action of developing (which remains mostly consistent)
Ivar: From what you say, Essence and its use cases seems to be a perfect match
So, you're guilty.
All the professionals are guilty because of not interventing, right?
All those which are complaining but earning their money same time with these crazy things, don't know what to say about that.
Ivar: Of course, I am also guilty. I could have shouted more, but would that have helped?
And a cure takes time to develop. I could have starved too, but would that have helped. On the contrary. What I try to do is to help all the good frameworks out there to get rid of the crazy things. This has already happened to Scum Essentials and Scrum@Scale Essentials and to some extent to Disciplined Agile.
Moreover, without working with several of these intrinsically good frameworks, how could I have any practical solution to the craziness?
Wolfgang: I'm sure you can/will do that.
My point: yes, we see the craziness, know that's craziness, but don't do enough to show that's craziness.
We wait till the young engineers also get the "experience", because we're to lazy to fight with the poser - who is earning money with phrases - or earning ourself.
So the "good old ones" are guilty for this, or?
From well-established method experts
We have 3 comments here and I kept them all.
Scott W. Ambler
Mark Lines, Al Shalloway and myself and others have been working diligently for years to put the multitude of practices and strategies into context for years. We believe in helping people to choose a way of working (WoW) that is fit for purpose for their context. This is why Disciplined Agile is a tool kit, a collection of contextualized strategies, which guides you in choosing your WoW. We view frameworks as method prisons too, and like SEMAT we help provide the skills for people to escape from those prisons. Where SEMAT's scope is software engineering, which desperately needs something like SEMAT to provide context and guidance, DA's scope is bigger in that we focus on enterprise agility. Similar ideas, different scopes.
I would argue that you're missing something from your list of crazy things: Most people don't realize they're in jail AND if they did a large percentage of them would be happy anyway (free room and board after all).
Ivar: Disciplined Agile and Essence (with its use cases) are certainly complementary. They share that people can select their own way of workings from let's say an eco-system of practices. They complement one another in many different ways, too many to discuss here. However, Essence, could help DA to be seen as different, I should say significantly different, than most other method frameworks, because if Essence had been applied, DA could be described on top of a common ground which is an international standard instead of on top of a homegrown platform. Scott and Mark, I appreciate you have started this process and hope you will progress well.
Scott, regarding scope I am sure there are some differences, but it may be worth knowing that Essence is now applied for all kinds of things, not just software. It is applied for systems as well as hardware, yes, in fact also for an innovation framework.
Finally, your sixth crazy thing is most welcome. Completely agree.
What matters is that teams delight customers by delivering better products faster. 58% of "Agile" teams fail at this. And the U.S. Dept of Defense Innovation Board had to write a document entitled "How to Detect Agile BS". 53% of Agile Transformations fail according to the latest Forbes survey. Thousands of companies are going bankrupt. There is objective evidence that most "methods" do not work and we should be focused on why.
This text comes from a discussion on https://www.dhirubhai.net/in/joakimsunden/
I agree with Ivar's view, it resonates a lot with the pragmatic stance we took at Spotify and is one of the reasons behind growing our own "model". The irony is of course that our "model" ended up being copied by hundreds of organizations...
2. All comments
I have ignored some comments which were just humorous, or which had no direct relation to the subject.
Unhesitating agreement and support
I could not agree more Ivar; so true & so well put.
Thanks a lot for that - and PLEASE keep it up
-> your sane voice in the only "medium-semi-sane" ;) methods realm
Ivar: I believe many people agree, but I wish more people would take action. ??
Gerd:
??
Please try to see that as positively as possible though:
Agreeing is / could be a (necessary!?) great first step.....on a journey to then take action hopefully too eventually......when the timing - on a personal & systemic level - is "right" for those affected....based on all their different individual & collective circumstances/boundary conditions.
Great and very reflexive article, Ivar Jacobson and Jeff Sutherland. I also had the same feeling abouth this crazy confusion caused by this myriad of methods, frameworks, methodologies, you name it. We definetelly need to focus on what really brings customer value to the table. I share my piece of thoughts on this article below, we are definetely on the same page.
Scott W. Ambler Mark Lines regarding method prison well described in #DisciplinedAgile. Nice article from Ivar Jacobson that expresses my perception and corroborates with my article above.
Mark Lines: Thanks. Ivar Jacobson, Scott W. Ambler and I are long time friends and have the same philosophy regarding this topic. We all believe in agnostic, pragmatic, fit-for-context, and "choice is good" approaches. I have learned a lot over the years from Ivar and he has been a great inspiration for me. As part of Rational, and later IBM, I taught UML, Use Cases, and RUP for many years.
Ivar: Thanks Mark...so true!
Overall I agree. with the author's crazy list for the method prison. Here are my two cents: First of all methodoligists SHALL go deeper than a pattern only stage; if they can go further to the depth of at least meta model stage or even further to the mathematics aspects, they would have more common grounds.?
Secondly, I agree with the author: putting methods into practice is important. The art of software and the emotions for software are less discussed by most methodoligists. How to represent the art of software? Will the software have emotions or even life like human beings?
In order to answer the above questions, we need to forfeit the method prisons, and go back to the basic concepts stage to re-define the concept representations. For example, maybe the traditional three categories of flows(Mass flow, energy flow, and information flow) are NOT enough to represent the emotions and life of future intelligent products and services. Thus original concepts are much more important than methodogies... ?
Ivar: The Essence Language, though very simple and small, is defined using denotational semantics. Moreover, OMG as the standards body, enforces the use of a well-defined platform MOF. Agree that the original concepts are important. See definition of alphas, work products, practices, patterns, etc.
Zhang: Ivar Jacobson, where is a good place to find the definition for alpha and patterns? also where to study the Essence language? Thanks for sharing the information. Instead of emphasizing software engineering only, we should emphasize the significance of system engineering more, especially model based system engineering MBSE
Ivar: You can download the standard from OMG here: https://www.omg.org/spec/Essence/1.2/PDF. However, it is not an easy read. Good luck!
A better reference is the my LinkedIn article 'Learn more about Essence' https://www.dhirubhai.net/pulse/learn-more-essence-ivar-jacobson/?trackingId=CQD0GAPI0jdl%2FXTa74rz0Q%3D%3D.
Rémy Fannander: It's hard to understand how gigantic specs full of ambiguous and circular definitions can find any audience among engineers ...
Instead, one should use compact sets of axioms, none pretending to detain the truth, but all easily understood, assessed, and improved.
Zhang: Thanks for the information. Agree with the minimal set of concepts ideas
Ivar Jacobson Thanks for the reference. I am recently reading some philosophy books about some basic concepts. Will try my best to read the OMG article, and then share with the community. Thanks again.
Of course system thinking and system science are not getting the deserved respects.
I agree on your list of crazy things. I'm looking at ways on how to overcome them, but it ain't easy. How can we help our workforce to adopt the methodology and don't fallback on their gut feeling, how can we prevent that Achilles heel to happen which you describe.
As you mention, coaching is not enough, we see this in practice. I do co-creation/collaborative methodology development with end-users and stakeholders. That seems to be working to some extend. It does not come over as the theoretical methodology but as something they build themselves. Of course trade-offs have to be made, but it is easier for the analysts to understand the reasonings behind them.
Remy: Common sense, any overhead should be balanced by clear and present benefits, smooth learning curve.
Ivar: Stijn, the best response I can give is a reference to another article I wrote titles "Curing the Achilles' Heel of Method Adoptions" https://www.dhirubhai.net/pulse/curing-achilles-heel-method-adoption-ivar-jacobson/. Feel free to come back with more comments
Thank you Ivar Jacobson for raising ‘Craziest Things’ up. Its always interesting to see how the simple business demand for more transparency and predictability from development side ends-up with chasing rituals and pretending we are adopting something which?will answer on all of our business questions.
+1 to your Craziest Things list from me: never ending transition from one method to another trying to get answer on a simple business questions without proper plan and metrics in tangible units of measurement.
Ivar, between the believers with their “one true god” and software practitioners micro-refining their current method to eek a bit more time and money, you have taken on a tough issue. I am not in a position to help in your effort but would encourage others to so by “promising” great enlightenment through the effort.
Simply beautiful - thank you for sharing this food for the troubled Agile Landscape mind ;-)
All methods or practictioner based are out of job. However, industry pays salary for technology based solution architect. But then what is an “architect”.
“””However, I also felt that having gurus in a science-based industry, social and technical sciences, was unworthy of our discipline. I felt it was nothing less than foolish.
Over the years I have identified many other similar phenomena that have caught my interest. Instead of attempting to create a better method, I have focused on recognizing and addressing the weakness in how we work with methods.
Here is a list of some of my findings:
1.????We are in a methods war for more than 50 years
2.????Practices are locked in method prisons
3.????Method prisons are controlled by gurus
4.????Methods have a lot in common, but there is no common ground
5.????Methods are theory only; they have poor support for putting them into practice: the Achilles’ Heel of method adoptions.”””
Very interesting. I left a comment on the article:
Hi Ivar, A colleague recently pointed me toward your article with the question: What is the Agile Fluenc? Model perspective on this? Since?James Shore?and I developed our model out of a similar frustration, I'm always pleased to see others who recognize this dynamic in the "method wars." From the beginning it has surprised me that a manifesto built on ideas of collaboration, interactions, and transparency headed in the direction of siloed methods and very little collaboration across them. To the point that folks talk about "fragile," "dark agile/scrum," etc. Perhaps it's the curse of Mammon. Once the perception "there is money to be made here" enters the space, ideas of competition over collaboration enters as well. And, our devotion to our values and our integrity seems to get lost in the stampede to revenue. James and I tried a re-set with our model. Let's look at what is best for the business and how to enable teams to produce that. Let's do it in a way that creates productive, humane, and sustainable workplaces (to borrow a phrase from the 2010 Agile Alliance board vision). Let's scan across methods to discern practices that work and create what we've called "fluency" in service of the work to do. I'll stop here and say, thanks for your post and I look forward to what's coming next. Also, I'm happy to have a conversation about why I think Agile Fluency Model sits outside of the "method wars," and how we hope to keep it that way.
Could not agree more with you after experiencing the "War" throughout my career.
Spot on, Ivar! A good reminder of identifying the problem and applying the best solution, is the best approach.
I agree completely and I appreciate your interest in improving our profession.
Spot on, mister Ivar Jacobson. One of the most striking things to me is the fact that some frameworks tend to "adopt" certain practices, change them slightly to make them their own, only patting the shoulder of original inventor, but nothing more. When the last major version of a certain framework for agile in a scaled context got announced, some of the "sect members" were cheering, because a certain business concept got introduced. I was like: "Oh no! What's next?" Sometimes things get too big. And the companies implementing these frameworks need to be very cautious not to step into the pitfall of "it is in the book so we have to do it this way", or "it is not in the book, so we cannot do this".
How to deal with the impediments you mention? Maybe it is time for a next level agile manifesto, that focuses on the common ground and interchangeability of practices?
?
Ivar: Actually, in 2009 SEMAT wrote a "call for action" which is similar to a manifesto with the purpose you suggest: https://semat.org/call-for-action
What is needed now, is that more people engage in discussing and implementing the vision.
I agree Mr. Ivar Jacobson, we must be IT eclectic, because I consider that extremisms in any area of life are not benefits.
Great article! Globally true! One thing I would like to add, any method or framework is not something that fails, its the gurus and the buyers who fail it. Also, the more we go in practices, methods, we tend to get more and more prescriptive, and we forget that the same medication can’t cure all the ailments!
领英推荐
Method frameworks provide direction, but a lot depends on truly understanding intent. In building and executing to a framework, both intent and directions need to be evaluated from start to finish. Flexible effective method frameworks allow for both - how and why.?
Ivar: Agree wholeheartedly...This is one of the key ideas behind Essence
Hi Ivar, thanks for sharing your thoughts and your list. Because you asked: I agree with your list. And I am in to do something about it. ?? ??
Mads this is an interesting and reflexive article about metods and agile frameworks, which might be useful for you if you haven’t read it ??
Thanks for tip Christian ??
The article is spot on, in regards to my experiences with implementing methods, and it underlines exactly the purpose my position at Jabra ????
Methods become religions complete with sects, gurus, and totally devoid of systems thought.
Wonderful topic! We somehow become captive to certain methods and the bridging isn't easy or even possible.
I like the point on Achilles' heel of method adoption!
Gurus are important, but they need to be the right gurus - not methodology evangelists, but gurus like yourself Ivar who tell complex truths in terms that most people can relate to.
Thanks for writing! So true.
Definitely a method war. In my bird’s eye view on the agile forest I collected 100 different ones. https://hennyportman.wordpress.com/2021/02/10/a-new-new-birds-eye-view-on-the-agile-forest-the-final-version/
?
Full agreement but with a twist.
Ivar - great article and I totally agree with the crazy things list. The question now is what to do about it. For example if we want to end the language wars, which language do we adopt as the one ‘common language’ and how do we do that without at the same time creating yet another method by another name? The goal, I believe, is to learn from them all, and use the mix of approaches that fits the particular situation without letting any brand allegiance get in the way. So I think it’s this attitude more than developing a single lexicon across frameworks. I share the desire for a commonly understood language (it was behind my strong support for uml), but my fear is that the quest for a textual one may end up following the fate of Esperanto. Any thoughts on how to avoid that?
Ivar: Let's first say a few words on UML. UML could have been great, but it became too big. It had no kernel of basic stuff that everyone could agree upon. On top of that kernel we could then add special packages of language constructs that were needed in more advanced cases. I have many times said that 20% of UML would be enough for 80% of all applications. See my paper The Road ahead for UML published in Dr Dobb's Journal.
Thus, it is different. There is a common ground, a kernel, for all methods and frameworks called Essence. It has gone through a long process to become accepted as a standard. It includes only things that everone easily could agree upon...that is why ít could become a standard. On top of this standard many methods are now described. The practices are liberated from their methods, free to be used by anyone to create their own method.
We are not far off from getting rid of the craziest things in our world.
Howard: Thanks, Ivar. I've only begun to learn about Essence through your presentations. I'm excited to learn more.
Thanks Ivar Jacobson ... Unfortunately just like 'Agile' the word 'guru' has lost its meaning. But in Indian philosophy it has a very distinct and important role.
Inspired by your work on Essance, I'm working on some ideas for representating behaviours in frameworks (doing and being).
Very valid points. One of the reason for people not to speak for/against is commercial interest. ( Like R&D in pharma company Vs research done in university).
Ivar:?You said: "One of the reasons for people not to speak for/against is commercial interest". I have no evidence for that but let's ask Dave West Jeff Sutherland Scott W. Ambler Dean Leffingwell Mike Cohn Craig Larman and whoever you would like to let us know. It would be very interesting.
Raghavendra: I was wondering about the use (abuse ?) of the term ‘guru’ in agile and software circles . Is it time to retire the term due to cultural (in)sensitivit
.. Thanks. I have read the original paper in the ACM journal about 3 years back. I have used some of those ideas in my consulting work. I have some thoughts, and I wanted to develop them independently without getting influenced and now it is almost done (first draft). I will share with the community for feedback.
I will go through the links and study them in detail.
Howard Podeswa I don't think so :) ... maybe can try to communicate the origin and real meaning of these words.
Raghavendra: Ivar Jacobson another dimension is IP issues (Intellectual Property).
I agree it is a shame much if this comes down to “religion wars” but I think most organizations want a set of practices that function well together (e.g. framework) to start with, one they can trust has come from expert experience, and then when they gain a level of fluency, want to be able to do some tailoring without breaking the essential elements of the practices in the framework (without unraveling the tapestry so to speak). It’s this tailoring part that I think has been overlooked a lot as one size really doesn’t fit all. Essence is an approach that could help with both - understand a framework starting point, truly understand the essentials of the cohesive practices in it, and then help users tailor without breaking.
Ivar: It is good to have a starting point, but why have to use a framework that has no common ground with other frameworks. Why not use a framework created from an ecosystem of practices which you can mix and match practices from. Now, you have to select a framework which has nothing in common with other frameworks. That is the crazy part of it.
Jeff: Agree. Just saying I think people will always want packages to start with where they feel there are support and available resources to get started and then move to more personalization. Ideally all the practices and frameworks could be modeled in Essence so people can get started with a package they believe suits their need initially and then use the models to tailor, mix/match, etc with more confidence.
For me methods are sort of ??templates??shaping the way people are working together. But there’s no magic behind, just humans trying to do their best with their understandind of what should be a ??good?? way to follow a method. Considering a method is not a science, you have to accept there will be a lot of different interpretations and applications of it. But maybe it’s the most interesting part : we have to deal with our imperfections, trying to improve every day. We’re not robots after all ;-)?
Ivar: Yes, I will go as far as saying, let every team create their own method, as the Spotify Model suggests (teams being squads), but they should have a common ground and the way they select their method should be smart with reuse of proven ideas. That is the Essence way of doing it.
Good summary! Unfortunately software development is not alone as many other fields share similar situation. For example in management there are far more ”methods” (TQM, JIT, 6 Sigma, Lean etc.). The key is to identify which fit to the situation your company/team is facing and which you can adapt as the situation is likely to change.
Ivar: Juha-Pekka, You are absolutely right, but that is not the problem addressed. Each one of these "methods" include a set of practices. These practices are in method prisons because a practice included in one method can't easily be reused by another method. All five crazy things presented in my article are relevant in the methods you listed as well. That is the point!
Thought provoking !
Our chosen field (IT) is challenging:
We must understand “the business” components intimately and the structure as a whole.
We need to be up to date on latest technologies and how they might be applied to solve problems (that might not yet be defined).
We have to lead people through change. Our own teams and colleagues inside and outside our discipline.
And we should be masters of “methods” many of which are interchangeable. I think this alphabet soup often obscures “common sense” and excuses us from thinking. “We followed the method perfectly and the results were poor…. Direct the blame outwards…”.
How should we learn to think ? How can we express and share the insights ? How do we codify creativity ? We must reconcile the artist with the engineer… and amazing things will emerge !
Methodology wars - that's what I call them - have been around at least since the '80s, and as you point out, we do not seem to have made progress. I strongly suspect that the reason for this is threefold:
1. There is lots of money in software development and IT consulting - The "Agile Hustle" is on, with people supporting one or the other methodology, without understanding the basics (what you refer to as common ground). In short, overall folks are too invested in the process (how) instead of the outcome (what). After all, all those certifications qualify them as "gurus"
2. Experience is hard to find and even harder to attract and the overall tech industry has consolidated. Whereas 30 years ago I had the opportunity to work on operating system development, Smalltalk compilers, and software utilities, the market has changed and consolidated. The result is that few experienced folks either are working for the mega players like FB, Amazon, MS, while all others work in "IT" - yes, there is a difference between software engineering and IT, and I suspect that IT projects fail at a higher rate
3. Experience is not valued any longer due the fast pace. Every company has to do software now, but few really want to. And the ones that really don't want to do software hire less experienced folks - or look exclusively at the labor rate.
All this results in just as many projects still failing despite the fact that good Agile practices are available.
Thanks Ivar, good reminder that we are free from self-built prisons.
Wanted to share for a while already on next step what to mix in specific situation in more reasonable way "right tool for right problem".
There is similar approach in system thinking/changes/engineering where methodologies and approaches are sometimes in conflict with each other. Michael C Jackson from Hull University run multiyears work on how it is possible to step out from such situations.
His latest book "Critical Systems Thinking and the Management of Complexity, 2019" goes into details, worth to read, but in summary that is important for this post:
- as methods of work are part of social life, it is important to consider social theories as foundation for explanations
- there is usually specific worldview of gurus/creators/practitioners behind methodology that is coherent with methods
- different worldviews and social theories related to it can be incompatible
- some worldviews also might not fitting specific situations (we can talk about cynefin slicing, or Ackoff or deeper)
- that also restricts what you can mix and when
- pragmatic" approach to mix whatever works is not optimal comparing to knowing above points to avoid such mixes
- it makes difficult to step out from the "prison" and build "own home". But it is possible :)
My basic principle is to focus on business value, while method is not a goal on its own. Having said that, organizations should explain better to their co-workers the sensegiving of a method: why is it needed and what is in it for them? On the other side organizations can make method adoption compulsory to some extent through gatings, QA and personal objectives, while providing proper method support. E.g. fit for purpose method documentation, personal learning/growth plans, high quality trainings giving by inspiring trainers, a method tailoring mechanism, well trained and sufficient coaches and mentors, method adoption workshops, active & fun communities for knowledge sharing. Apply system thinking and root cause analysis to poor method adoption to find your improvement actions in method adoption.?
Ivar: Great list, but the biggest challenge is what I call the "Achilles' Heel of Method Adoptions" https://www.dhirubhai.net/pulse/curing-achilles-heel-method-adoption-ivar-jacobson/. There are not enough "well trained and sufficient coaches and mentors".
Great great article- so many of the principles and practices in all the methods are based on a common sense approach to real problems. The challenge is when time is not taken to understand the intent behind the concepts and the problems they are trying to solve. Rather there is a desire to plug and play and expect it all to work magically. So many major organisations spend gazillions on transformations looking for a plug and play approach because maybe it worked elsewhere in some guise, but not understanding the problems of that organisations and the actual journey they went on. Snake oil salesman and silver bullets are so prevalent - method wars and what you call the prisons are a large part of that.
Method war - absolutely mind boggling. One method is usually purported to be better than the other usually without any empirical evidence.
Why can’t we have a goal, use a method, try to meet the goal, reflect on why it did or did not work, and collect context specific evidence, improve ... repeat.
?
Not in disagreement, but discusses a related issue
Maybe I am completely off-topic, but I will share an experience. For more than 25 years, I worked with many methods (including briefly OOSE :) in the software and IT services industry. And what saved me was knowing exactly what kind of software I wanted to build.
When UML was born, I was in the first France UML user group, and this was for me an historical milestone because the modeling language could be separated from the methodology! The modeling language was enabling me to think about the software, and the methodology - almost always dictated by managers that wanted to be "trendy" - was the way to build it. With time, I adapted to all methods by putting architecture and design first.
SAFe is no exception. This is the trendy method of the day, soon overcome by another method. I don't like this method because it pushes many organization not to think about the softwares they need, but to hyper-focus on a complex error prone methodology. This is aggravated when you don't have a precise idea of what you want to do.
But, if you know precisely what you want, you can adapt SAFe, and any other method, to fit your purpose. So, for me, the method is just a set of common practices that will be the common set of rules of the project and that cannot prevent you from doing what you intended to do from the beginning.
That will probably always be like that as long as methods will be at the core of "IT trends". We live in a very marketing inspired industry, and methodology is continuously instrumented by vendors to sell projects to non-IT people.
For sure, I would like the industry to progress to a core set of common practices (I remember a French initiative named Puma a long time ago) that could be adapted to the exact challenges of the software to build. But, I am not sure the IT world is evolving in that direction...
Link on Puma: https://www.entreprise-agile.com/en/Puma-en.htm and https://www.entreprise-agile.com/en/SolutionModelEN.htm . The creator of the method was Jean-Pierre Vickoff .
Ivar: Maybe you would like Essence?
‘Learn more about Essence’?https://www.dhirubhai.net/pulse/learn-more-essence-ivar-jacobson/
Most are boutiques, not prisons ...
Ivar: If boutiques, not widely popular and not prisons ??
I did search in this article, how many times customer was mentioned? Zero. IMHO the craziest is that we focus too much on methods and frameworks. I believe in what was written in the agile manifesto: "Individuals and interactions over processes and tools". In order to "beat these abnormalities of our discipline" I help others to see "value in the items on the right, but value the items on the left more".?
Ivar: Every method or framework must have great practices to deal with customers. And all the successful frameworks pay significant attention to customers. Otherwise, they wouldn't be successful. They most likely do it in different ways, and that is fine. However, the way they do it, is not easily reusable by anyone else. It is hard to learn from others. The practices are in method prisons.
"No common ground"....the reason why professionals comply with industry standards, whilst ignoring the ritualistic WebDev/IT malpractices that have blighted many sectors:
Ivar: Fabulous article Martin!
I also see this scenario where we have methodologies struggling to occupy space in the market and moving away from their purpose, which would be to facilitate the process of creating and managing software.
In the end, they all have the same good ideas but expressed in different ways that often don't communicate.
I understand that one methodology should not invalidate another and that teams should choose which practices best suit their realities.
An overview of the main components of each methodology would be interesting. Not that we would follow for standardization, but for a consensus on certain practices that have already been consolidated in the software industry. We could even promote the reuse of these components in various methodologies.
Rémy: As far as practices are concerned, their value depends on the expertise of the gurus and teams supporting method boutiques. As for principles and standards, their number and variety would suggest evidence and irrelevance, respectively.
The world beyond software
A short reading list
1. What's wrong?
3. Advice
4. A few tools
I did a parody presentation for the Agile Lean Ireland 2020 conference on methods such as described as above. https://www.youtube.com/watch?v=VNUlBcRB7mo
The anti-patterns of Guru-led, Borg style absorption of others methods with no real deep understanding of them, and the general idea of selling the results of individual organisations successess to others by mimicking and without undergoing similar journeys, are all rife in the methodologist space.
However, I am not sure methodologists are the answer to this. Defining a "common language" will just lead to another cage with different gurus. RUP/SAFe keep reinventing after experiments. But the experiments are being carried out on peoples careers and companies. This is not right.
Methodologism should die, and in it's place be replaced with simpler "micro-methods" and practices, and safe-to-fail experiment-led self-discovery.
Ivar: "Defining a "common language" will just lead to another cage with different gurus." Not necessarily. The "common language" or "common ground" must be simple. It must be a standard so there is nothing controversial in it. Essence is such a a common ground. It is owned by a standard organ OMG, so no guru controls it.
Essence can also be described as an implementation of "Methodologism should die, and in it's place be replaced with simpler "micro-methods" and practices, and safe-to-fail experiment-led self-discovery." TRY IT!
i am not sure that a practice is comparable to a mini method. A practice is more guided by the heuristic of its outcome in my mind, and therefore more flexible to be adapted into its context. A method is more rigid regardless of the context. (only my opinion).
I also think that the method discussion is highly motivated by the need for rapid satisfaction. We are living a culture of instant gratification and Enterprises are no different: "We'll make a big investment for the problem to go away". When the challenges are systemic, organisational, leadership and human ... you don't configure People like software. The "outcomes" become long forgotten too. People focus on the "means" and become quickly lost in transformation.
Lastly, somebody helping to implement some methods is a trainer, consultant or at best a Mentor. Coaching has to do with the "Being", not the "Doing". "Agile coach" is an oxymoron. A lot more genuine coaching work should be done because it is fundamentally about behaviours rather than methods. But it does not help when coaching has been completely cannibalised as a term.
Ivar: Very interesting feedback deserving more discussion than as a reply to your comment.
1) "A practice is more guided by the heuristic of its outcome..." Practices can be defined on different levels of details...and methods too.
2) "The "outcomes" become long forgotten too. People focus on the "means" and become quickly lost in transformation". A focus on the essentials and with a great user experience including attention to the Achilles' Heel of method adoptions are a big step forward.
3) "Coaching has to do with the "Being", not the "Doing"." One of my "crazy things" is the reliance on consulting to bridge the gap between Learning and Delivering. https://www.dhirubhai.net/pulse/curing-achilles-heel-method-adoption-ivar-jacobson/
Hello Ivar, I think the major challenge isn't methodology, but the responsibilities of the people implementing it. Check out this article https://steveblank.com/2021/06/04/you-dont-need-permission/ If you are personally responsible, you can take ownership and implement methodologies whichever way you want and define interfaces to other teams with the clear organisational contract, if you are not, then no amount of communications will get you buy-in. As Steve wrote in his article "Having real data turns conversations from faith-based to evidence-based". On the topic of experts and their opinion, there is a great book by Vikram Mansharamani https://www.mansharamani.com/ "Think for yourself".
Ivar, my sense is that their exists an incentive to define the "One true way to success", the reality however is that the solution (as you articulate) is an amagamation of ideas from multiple sources. The solution then is dependent on the situation, the problem being that no single solution can fit the scope of all presented problems. In simple terms, one might observe there are two forms of insanity - great certainty and great uncertainty. The solution (arguably) lies in the center, where one is able to take aspects of various frameworks and apply them to the customer presented problem. Stay safe and well.
Good karam flying your way. Glad to see you are still creating thoughtful prose and problems.
I really liked Dov Dori's response, but I can't find it here now? And the references to Dr Mike C Jackson OBE below.
I would say that the practical problem could be seen as deriving from an incentive problem, which creates individual behaviours - an aspect I would like to focus on more in my 'four quadrants of thinking threats'. The incentives are all aligned to take one of the corner positions - with pay-offs for the individual and impacts for the field - whereas you and Dov and Mike and others (including the SCiO - Systems and Complexity in Organisation board, with whom the four quadrants was developed) are all interested in helping people stay in the middle space:
Many many of these failing Agile initiatives are an imposed way of working upon the people that we say are the MOST valuable “resource”! This mandated process technique has a known failure mechanisms- it disengages the work force. Once that starts it snowballs. A disengaged workforce will never adopt a new innovate process.
A solution may be found in this pattern - try inverting the disengaged work force.
Try Engagement!
Craziest? All the immature organisations that roll-out tools without training/coaching in methods:
Ivar: Absolutely with the addition, good teachers and coaches are hard to find. Simplify by Curing the Achilles' Heel of method adoptions https://www.dhirubhai.net/pulse/curing-achilles-heel-method-adoption-ivar-jacobson/
Ivar/Jeff,
When are requirements "Requirements" ?
I ask because of the timing problem we face today.
its as if the Universe itself has tuned out. And creation has backflowed in result.
(Which is to say that we've opened this up to everyone out there !) - And its become a guessing game.
Ivar: In Essence Requirements have states: 'Conceived' 'Bounded' 'Coherent' 'Acceptable' 'Addressed' 'Fulfilled'. For each state there is a checklist based on real outcomes.
Sounds like you're saying the process improvement services industry as morphed into a confusopoly. I suppose that's inevitable when commoditization compels producers (service providers) to engage in facile differentiation.
Frameworks in real life are all about the same, but so selfish that can’t even realized it. :)
Method prison has both pros and cons, more pros and cons if u ask me. They create opportunities and roadmaps in nascent stages of learning for communities. IMHO, we should tread on this whole path a bit more cautiously. TX.
Ivar: The meaning of the term 'method prison' as used in the article is different. Practices are locked into methods (methods are prisons for practices) because practices are not simple to reuse by other methods. Hard to see that that can be good??
Skeptical at first but after some counter argument, seemingly in agreement
Let's not conflate 'industry' and 'discipline;' and I would argue methods are not theory but an application of poorly described theory. "Our industry" as used in the article seems to refer to those whose fame and fortune depend on promoting (individual or bundled) methods. This is where we have a legitimately competitive marketplace of those who "war" for their own method. The "discipline" of software engineering (SE, in that larger sense of the term as a subset of engineering) is, or ought to be (per Maslow's vectorial facts), based on a pragmatic epistemology. Method evolutions (by refactoring or practice adoption, adaptation, and pruning) tends to reflect this and seems to occur when 'crazy things' experts encounter practical needs of those organizations which employ their own industry (e.g. education, insurance, 'widget' manufacturing) methods. [Optimally, methods engineered within and for those industries learn from SE as well.]
Where we are shallow, I believe, is in appreciating and leveraging both 'hard' and 'soft' sciences behind effective SE. Let's distinguish between methods and methodology, regarding the latter as a science based in psychology, economics, logic (beyond Boole), operations research and other realms of discovery. Let's apply the learning from those who spend time understanding why a given practice succeeds or fails. Science, engineering, discipline, and industry require alignment; I believe methodologists need contribute more science -- theories and falsifiable hypotheses -- in the interest of freeing method prisoners and negotiating peace treaties on method war battlefields. My own goal, as time and the good Lord permit, is to contribute research on interdisciplinary bases of contemporary practice so we are better able to focus on why than what.
Ivar: Skip, I don’t disagree with anything you say. In my article I talked about the union of industry and software engineering to simplify. I also agree that there should be a competitive marketplace. However, it could be much better if we removed the crazy things.
Agree also that we could improve both soft and hard practices and patterns.
However, these points are not addressed by my article.
Skip: Long been a fan of your work, Ivar. Years ago taught RUP. Like any language, UML "trained my brain" to leverage a perspective and that perspective (if not the diagrams) continues to be helpful today. I think SEMAT reflected a disappointment similar to what you've expressed here, and value your standing aside from the methods fray to recognize its craziness. Essence was/is an attempt to bridge communities; my hope is to continue considering those theoretical aspects by looking across academic disciplines.
Ivar: Yes, Essence attracts not just software engineers, but people in any engineering discipline. With minor changes, just some generalization, it seems to work well with many other engineering disciplines. We have seen it being applied in system engineering as well as hardware engineering. Also as a platform for innovation practices.
However, my personal priority is software engineering, but I am open to later enlarge the domain.
Why on Earth would you want to standardise across methodologies?
Are we at that point whereby we have finally reached the zenith of our learning and developed 'THE WAY' to deliver?
Is there no further improvement which can be made to our practices?
Are there to be no further advances in physical or virtual tooling which might unlock new ways of working and necessitate new methodologies?
Let's face it, the reason why there are multiple methodologies which have all seemed to appear in a relatively short space of time is because industries have been going through an exceptionally turbulent and volatile time these past few decades. They've tried to adapt to the advances in technology and tooling to make best use of it all and stay relevant. This hasn't spawned from a single font of knowledge, it's emerged from a global consciousness in geographically dispersed locales. That's not going to stop anytime soon.
Just like the English language (now complete with emojis) methods of delivering best practise are constantly evolving. Like it or not, Methodology is the language of delivery. To standardise is to stay still and perish. The only constant really is change, and it is that which should be explored and exploited wherever possible.
Ivar: Now, there is no suggestion to standardise methods and frameworks (or methodologies for that matter). On the contrary, we would like to see many more such things than we see today.
Neil: Ivar Jacobson except to say that it is "crazy" that they do not share the same common ground and taxonomy?
Now I certainly don't disagree with you from the point of view that it is certainly crazy for companies to overlook or reject a job applicant because they are not 'certified' in a particular method despite being certified in many similar ones. At the end of the day the act of software delivery isn't really that different across the industry.
Admittedly it does require different skills to manage as it scales up to bigger initiatives which require hundreds of developers. However these are skills in forecasting and aligning delivery and containing the activity rather than actually performing that action of developing (which remains mostly consistent)
Ivar: From what you say, Essence and its use cases seems to be a perfect match
So, you're guilty.
All the professionals are guilty because of not interventing, right?
All those which are complaining but earning their money same time with these crazy things, don't know what to say about that.
Ivar: Of course, I am also guilty. I could have shouted more, but would that have helped?
And a cure takes time to develop. I could have starved too, but would that have helped. On the contrary. What I try to do is to help all the good frameworks out there to get rid of the crazy things. This has already happened to Scum Essentials and Scrum@Scale Essentials and to some extent to Disciplined Agile.
Moreover, without working with several of these intrinsically good frameworks, how could I have any practical solution to the craziness?
Wolfgang: I'm sure you can/will do that.
My point: yes, we see the craziness, know that's craziness, but don't do enough to show that's craziness.
We wait till the young engineers also get the "experience", because we're to lazy to fight with the poser - who is earning money with phrases - or earning ourself.
So the "good old ones" are guilty for this, or?
I believe one issue behind this is human need to feel safety. Individual developers are safe as long as they can refer to following a certain method. Higher psychological safety could be one possible cure.?
Ivar: True, and there is no reason why they shouldn’t be able to point at one particular method.
Tuomas: Ivar Jacobson?true. I guess from company perspective having one method or chosen set of methods makes communication easier and supports control. On the other hand, I feel companies could benefit from identifying exceptions where tweaks to methods are needed. Method war sounds like waste of energy, perhaps we could learn to understand better the benefits of each method family? One thing to take into account too, is lot of people have already invested lot in learning certain methods and there is path dependence.?
Ivar: Maybe Essence is what you are looking for?
We should objectively measure the results of the methods / practices implementation in similar environments to compare them and get more accurate implementation guidelines on that. The most objective metrics known by now are defect density (number of errors per size of the product / increment) for quality and productivity (size of the product / increment per effort in man hours). The problem is measuring size is not popular, it is more and more negated by the IT community, probably just to hide that the productivity and quality degrade.??
From well-established method experts
Scott W. Ambler
Mark Lines, Al Shalloway, myself and others have been working diligently for years to put the multitude of practices and strategies into context for years. We believe in helping people to choose a way of working (WoW) that is fit for purpose for their context. This is why Disciplined Agile is a tool kit, a collection of contextualized strategies, which guides you in choosing your WoW. We view frameworks as method prisons too, and like SEMAT we help provide the skills for people to escape from those prisons. Where SEMAT's scope is software engineering, which desperately needs something like SEMAT to provide context and guidance, DA's scope is bigger in that we focus on enterprise agility. Similar ideas, different scopes.
I would argue that you're missing something from your list of crazy things: Most people don't realize they're in jail AND if they did a large percentage of them would be happy anyway (free room and board after all).
Ivar: Disciplined Agile and Essence (with its use cases) are certainly complementary. They share that people can select their own way of workings from let's say an eco-system of practices. They complement one another in many different ways, too many to discuss here. However, Essence, could help DA to be seen as different, I should say significantly different, than most other method frameworks, because if Essence had been applied, DA could be described on top of a common ground which is an international standard instead of on top of a homegrown platform. Scott and Mark, I appreciate you have started this process and hope you will progress well.
Scott, regarding scope I am sure there are some differences, but it may be worth knowing that Essence is now applied for all kinds of things, not just software. It is applied for systems as well as hardware, yes, in fact also for an innovation framework.
Finally, your sixth crazy thing is most welcome. Completely agree.
What matters is that teams delight customers by delivering better products faster. 58% of "Agile" teams fail at this. And the U.S. Dept of Defense Innovation Board had to write a document entitled "How to Detect Agile BS". 53% of Agile Transformations fail according to the latest Forbes survey. Thousands of companies are going bankrupt. There is objective evidence that most "methods" do not work and we should be focused on why.
Pete: Jeff, you defined an elegant and simple system. For me at least the problem is not with what you proposed rather it is in the implementation of what you proposed. The hard part (in my view) is maintaining the simplicity of the original intent. It is very easy to take an elegant proposal and add complexity via tools or through human process - the hard part is maintaining the simplicity. It was ever thus - chuckle. Stay safe and well.
Gopal: Absolutely agree with Jeff. Too much energy being spent on "How" by customizing complex frameworks rather than "Why".
Janet: I would say that the “why” is comfort in the status quo and fear of deviating from that comfort! Many times when I propose using the Scrum framework, I am met with hostility. Can you believe that? I’m sure you can. So many people would rather vent about the drawbacks they perceive (which truly do not exist on this framework), than try it out. These folks will continue to flail, and will never deliver on a suitable timeline.
Fernando: I agree with Jeff Sutherland. What matters is the impact that teams have.
To quote him: "What matters is that teams delight customers by delivering better products faster."
Just in case the point is not obvious: I think the article can be misleading because "The Achilles’ Heel of method adoptions" implies that the right method and the right adoption will solve the problems. Nope.
It is not about the capacity to implement the right method in the right way, but about the capacity to build enough awareness (transparency), to see the results (inspect) and to act accordingly (adapt).
This is how continuous improvement takes place. Remember: getting better beats being perfect.
Ivar: No, "The Achilles’ Heel of method adoptions" DOESN'T imply that the right method and the right adoption will solve the problems.?It implies our developers only get support in learning what someone think they should do, not in doing what makes sense to do.
Ivar: Yes, our world is very complex, so we have to simplify. Having a common ground to stand upon when discussing these complexities is an important start. Take a look at Essence, the OMG standard.
This text comes from a discussion on https://www.dhirubhai.net/in/joakimsunden/
I agree with Ivar's view, it resonates a lot with the pragmatic stance we took at Spotify and is one of the reasons behind growing our own "model". The irony is of course that our "model" ended up being copied by hundreds of organizations...
Stefan Malich: Joakim, thank you for your feedback. Well, I think that currently there are some very interesting movements related to the Spotify Model... When I heard about it the first time, I wondered why any other organization would like to _reuse_ the model because one thing is for sure: Any other organization isn't Spotify. ?? Furthermore, as I learned, there is no distinct Spotify model because the way-of-working at Spotify is in a constant state of flux, aiming at continuous performance improvement and a true learning organization.
When you say that the model is copied by a lot of organizations, do you mean that organization are copying the idea of constant change and continuous performance improvement (therefore I would argue the get _inspired_ by the Spotify Model) or do you mean that organizations are copying the Spotify Model one-to-one (whatever the master model is)?
Joakim: In my experience it can be both. Some organizations are inspired by Spotify and maybe already share the learning mindset but have to get started with something, e.g., the "Spotify model" structures. Others seem more interested in copying the structures and terminology to borrow some of the "halo" to help with buy-in and communication in their organizational change. Calling teams "squads", departments "tribes", and so on.
Architecte SI @ Nickel @ BNP Paribas
3 年Proud that my comment was retained ??
APAC Initiatives Lead Agency Trading Technology, ????????????????????????????????????????????????
3 年It is critical for agile teams to be able to improve the way they deliver, this needs to include adapting methods or framework they use. Great to see this initiative is now here to help teams do exactly that, count me in!