I have been in a similar situation (in a retail bank), with consultants offering what they call 'enterprise Agile'. The result was waterfall and highly problematic.
The consultancies are typically very good at lobbying support (especially with the executive). So it can be a challenge to call them out.
I would recommend to your Agile coach that they do the ...
There is nothing agile about the consultant's approach and certainly not use of the Scrum framework. That is waterfall with some modern software development terms being misused.
Allowing an internal team to learn through controlled experimentation is a good mentality; permitting a consultant to waste money for any length of time is ludicrous.
"Agile" isn't a methodology; it's a set of principles espoused by the Agile Manifesto. SDLC is an ambiguous term that can refer to a specific, waterfall-like methodology or a generic lifecycle. Either way, frameworks like Scrum or Kanban are more usefully classified as project management methodologies rather than lifecycles.
Frameworks Aren't ...
System Development Life Cycle (SDLC) isn't methodology. It is...life cycle :-)
Each system (product) goes through several phases during it life. This always happens and is not dependent on methodology.
These phases could be mixed in different ways (Waterfall vs Iterative and Incremental approach). But all of them are present.
Some methodology may or may ...
What if the majority are wrong
It can happen of course. I would expect any issues that arise from a wrong decision to be raised and discussed at retrospectives. Hopefully the team would then recognise the error it had made and adjust.
Why chose technical correctness over people correctness
Why indeed. The team should discuss the pros and cons of the ...
"Collective code ownership" does not mean that everyone on the team gets a say on every line of code that's written. The code is still written by individuals (unless you're pair programming), and they are making the decisions they feel are best at the time. The point is that no individual "owns" a section of the code.
If John wrote the Foo module, and for ...
1) International Software Benchmarking Standards Group (ISBSG, http://www.isbsg.org/) collects this data, you can buy their report.
2) There also used to be (still is?) Chinese Software Benchmarking Standards Group (CSBSG) that collected this data for Chinese projects. I believe I saw their data some years ago, but I can't find it anymore, and their site ...
Nice question. The distribution of labour for software development across labour types varies per project, project approach and organisation. It has challenged me quite a lot in the past as an R&D manager. For current project we always work with some kind of FPA and in our case 15% for analysis unless reasons to deviate.
But that's not your question. ...
TL;DR: Those SOPs are not Agile at all and suffer from all the shortcomings of traditional Waterfall projects. In Agile methods:
Requirements are never frozen. Changing a requirement that isn't realized yet is cheap.
Development & QA are close together, without any quality gates
Projects are executed in short iterations, with feedback from the client(-...
Like Mark Phillips commented, this is a question of initiating a project.
First, understand that when initiating a project, it's all about value. If people generally feel that the system does its job, then you will have your work cut out for you to push the project on technical concerns.
If there are functionality sets or flows that cause real business ...
The waterfall model is linear, so there's no cycling involved. When the product is built, the project is done.
Your graph looks more like the Systems Development Live Cycle (SDLC) to me. The SDLC is used in process management to build, maintain and grow an IT system. So it has no defined ending.
I just can tell how the teams I worked with did best: when a developer finished a part of code he or she considered important, they brought it with them to the next review to show to and discuss it with the other team members.
Rotating pair programming-pairs also helps a lot in communicating the current state of a repository.
In my eyes, having a "target ...
Contrary to what you believe, it is not unreasonable to have had at least two sets of eyes on 100% every code change. Every team I’ve worked on for the last five years has had at least one other set of eyes on every change. Sometimes it’s a tool assisted review, sometimes it’s an informal “can you look at this quick”, sometimes it’s a second set of eyes ...
Waterfall is done when the project is delivered into a Business-As-Usual (BAU) state.
One of the defining characteristics of a project is that it is Temporary. The other four are
Uses a cross-functional team
The deliverable is unique
It causes uncertaintity
If you subscribe to this model then the project is technically done once a ...
Try to identify the biggest pain point and articulate the Agile practices that will mitigate that
Looks like you are convinced that the existing approach will certainly fail:
...or should he let them fail and feel the pain before he intervenes?
However, you didn't say which aspect of their current practice you think is likely to cause problems, other ...
Evaluating a process is more involved than just looking at a high-level view of the process flow exhibiting only the happy path. Since it is just the happy path, there are substantially far more connections where information and product material flow in reality so no credible judgment can be made here. Further, you need to examine the actual work within ...