Everybody is using Agile/Scrum in one way or other. But at times this in on paper in agreements. Do you think if a new process is need in this new age. Do we need to sketch out new framework.
Agile/Scrum is one of those things that are impossible to criticise. You can come up with a well-reasoned critique of a particular scrum deficiency and there's always some Scrum Expert that pops up to tell you that you're not doing "real scrum" and, therefore, your experience is invalid.
At the same time, I have now done software engineering for over a decade, in many roles and teams, and I have never seen Agile or Scrum to lead to the development of a good piece of software. I guess we were using it wrong.
Yes, but the problem is that the organisations will only listen to McKinsey and they have a motivation to not solve the problem but to merely adapt it and bill the client again.
Agile is one of the few significant shifts in business where the board members are unaware of the creators and don't hire them in to consult authentically. I think only Kent Beck was hired by Facebook at a somewhat senior level, and Ken Schwaber spoke at Google a couple of times for mega money. It really should be a thing where every manifesto signatory is a consultant to big business at board level.
- If you want to make sense of "original Agile", read "The Agile manifesto" (2001), it's 2 short pages, we can wait for you to get back.
- Criticisms of modern "agile" are actually the same as the problems that spawned that agile movement in the first place. It has become what it reacted against.
- There are practitioners of OG Agile still around and talking / Writing. Dave Farley for one.
- The scientific method does not need to be replaced, hard no. An experimental, incremental, iterative, learning framework is the way forward. The specific rituals of Jira-based scrum, those could go and not much of value would be lost.
If you're looking for a new framework, are you familiar with the Accelerate book? How about Team Topologies ? The Goal ?
Dave Farley is a good guy and the real deal not just a talking head - I worked with him at LMAX which is where he was working when he was writing the Continuous Delivery book and that place had agility and the highest standards of engineering I've ever seen as first class concerns in the business (I was the agile guy and Dave was Head of Development both reporting into the CTO, Martin Thompson of Disruptor fame).
LeSS from Craig Larman and Bas Vodde is definitely worth a look too.
I am currently working through Mr Farley's recent book Modern Software Engineering. I'm not finding many surprises in there, I might already have passing familiarity with what he's talking about. But my comment above about scientific method is based on what I have read so far.
Taking a note from an answer up above, "the thing that needs to be revisited is implementation of agile processes / scrum in companies/projects".
Coming to another answer, where we see the management itself lacks interest in the process and rather asks to complete the task asap, it does raise question about the process.
I need to familiarize with Team Topolgies. I googled and found Martin Fowler has an article on it. Need to read that. Will check out Accelerate.
When you say, "It has become what it reacted against.", does it mean it has come full circle. A shift to new idea might be interesting here.
Yeah, that's the usual thing is: Short term hurry, unwillingness to invest in the process get long-term gains. Ship bugs today and fix it later, instead of methodically shipping well-tested software.
> When you say, "It has become what it reacted against.", does it mean it has come full circle.
Indeed: "meet the new boss, same as the old boss".
> A shift to new idea might be interesting here.
Oh sure, if there are new ideas. But I do not think that there are better ways than a scientific method i.e.: trying out and evaluating evaluating new ideas against reality. The Accelerate book is all about evidence based suggestions on what high-performing looks like.
OK, let me ask you: Can you clearly articulate the "old ideas" that don't work any more? Can you read through the Agile manifesto, and see if it matches these "old ideas", or does it contain ideas that might help with that?
Looking at most comments, you have people on one side accepting the Agile/Scrum to keep the project moving forward, not dwelling into to much details of the process while accepting delivery is most important.
On the other side, you have people calling the original Agile manifesto accurate theoretically.
My take on this right now is: yes, we have come long way with Agile/Scrum/(or any process), built incredible software, billed the customers and always accommodated customer changes.
We have come from daily standups to online sitdowns(something I just coined or was it there already :) ). People are hearing more voices then seeing faces. Literally, everyone is screaming AI in every enterprise.
Given so much data that exists about Agile/Scrum implementations and we have ways to measure it, I believe if someone comes up with a new idea which keeps the core idea of efficiently delivering new software to customers then I am ready to follow that. Just for a change.
Personal experience is that although agile and scrum are widely used, most organisations use these as frameworks to build a custom approach. Biggest problem I always find is lack of accounting and governance transformation to support agile, these two are always typically waterfall, so then you end up with agile technologists versus waterfall business = waterfall with sprints. For agile to really work, every part of a business needs to adopt it, from board down.
Ha! "waterfall with sprints" indeed. Just spent about 14 months operating that way. Manager wanted a demo every 2 weeks, fair enough in itself, but expected monotonic improvement. Two months into that, we really needed to rip it apart and fix some of the less than optimal early decisions, but the pressure to keep "checking off features" meant we just kept finding ways to tack new things on.
"waterfall with sprints"!
This question of mine sprang into existence when a senior manager mentioned he is a water fall guy and still sees it good.
Well, we are stuck with people preaching Agile and people following Waterfall.
The Waterfall horror stories as told by Agile/Scrum people are tailored to support their narrative.
That kind of Pure/Classical Waterfall maybe happend at government or public sector projects, not in the tech companies.
What most people mean by "waterfall" is anything with Upfront Design phase. I never encountered pure wtarfall at tech companies, the closest was RUP (Rational Unified Process), but it has overlapping phases and iterations. It's modern iteration are various mini-waterfall SDLCs (e.g. Event Modeling, Shape Up).
The only real problem with the waterfall model is that the original book didn't mention iteration. the author thought that it was too obvious to mention. Obviously once your customers have version one of your product, you are going to collect detailed feedback from them and use that to inform the design of cersion two. He probably didn't envision companies making a prototype in two weeks and making version one available to the whole world a month or two later, but that is not a flaw in the model.
BTW, the original Royce' waterfall paper didn't promoted it, but instead presented it as an anti-pattern. But even it shown feedback loops (i.e. going backward to the previous phases), which are kind of iterations.
in my experience, agile/scrum is great - in theory.
in "the wild"/in practices its mostly implemented in a way, which "pleases lower & upper mgmt" but doesn't take into account the features necessary for the team(s) to be able to work smoothly.
so: not agile/scrum need to be revisited, but the implementation of agile processes / scrum in companies/projects etc...
cheers,
t.
ps.: and lots of companies want to do "scrum" with far to few people / small projects - mostly situations, where imho. kanban with a backlog would be sufficient and especially more effective.
Implementation of agile/scrum process does need some refining.
You did mention the point of "pleases lower & upper mgmt" which translates into reports and metrics that things are moving forward. But the effectiveness of using a process by the actual people working matters. I feel it locks aways some amount of potential in the ceremonies/rituals which are given more importance.
At the same time, I have now done software engineering for over a decade, in many roles and teams, and I have never seen Agile or Scrum to lead to the development of a good piece of software. I guess we were using it wrong.