Agile isn't always Agile
Stefan Roock describes multiple process models in his article about hybrid project management forms (Link, German) with very specific details.
The following is my approach to boil them down into one, Agile in Waterfall and compare them with Waterfall and Agile.
Details of concrete implementations may vary. If you want this, take a look at Stefan's article.
| Action | Waterfall | Agile | Agile in Waterfall | |
| Scope defining a high-level definition of what to develop | Mostly upfront, without a bigger chance to incorporate feedback and changed context. | Just as much as needed for current the iteration* with good enough quality by the whole team. | The same as Waterfall. | |
| Requirements defining concrete details of what to develop | Mostly upfront, without a bigger chance to incorporate feedback and changed context. | Just as much as needed for the current iteration* with good enough quality by the whole team. | Just as much as needed for current the iteration*, but limited to the fixed scope. | |
| Development creating the product increment | Covering nearly all requirements in a single shot, without much feedback from testers or customers. Not always developers are invited to previous actions. | Just as much as needed for the current iteration* with good enough quality by the whole team. | Just as much as needed for the current iteration*, but without learning from customer feedback. | |
| Testing investigating the actual state of the product and reporting it | Covering a big, so far untested, product with little chance to inform previous actions. Also testers are usually less often invited to Scope and Requirements. | Just as much as needed for the current iteration* with good enough quality by the whole team. | Just as much as needed for the current iteration*, but without learning from customer feedback. | |
| Customer Feedback giving feedback how good the product solves customer needs | High potential for the product not matching the needs good enough. Scope and Requirements can usually only be adapted by higher costs. | Can influence the next cycle's scope and the team gets early feedback to incorporate. | The same as Waterfall. To some degree it could also be withing the iteration, but then it is more about details and less about potentially changing the scope. |
* iteration: could be a Scrum sprint as well as ticket in Kanban (working on multiples in parallel). Can include release work as well.
Any agile framework can be in Agile or Agile in Waterfall, depending on the context. Scrum, XP, Kanban, etc.
- Method as Agile means: A team is allowed to learn from their work, especially by feedback from the customer. It adapts to the feedback and work. Iterations are about finding out what the customer needs.
- Method as Agile in Waterfall mean: A team is not prohibit to do learn and the framework is mostly used by management for team control. Iterations are mostly about breaking one big Waterfall plan into smaller milestones and judge the team's effort on reaching them.
The difference between both can sometimes be tiny details and it is easy to fall from one into the other.
This is at least a spectrum where teams can be more or less agile, incorporating feedback reasonable early. I made this separation is show the key differences more prominent, but it depends on details.
What do think is your team and company doing and why is it like that?
I choose the colors intentionally to make the graphic better readable for people with color vision deficiency.