Did they actually name it SCREAM? 😅 I thought you were just being humorous. I'm not familiar with this relatively new approach, so thank you for your detailed research and work. I've learned something new from you, as always 🙌
I haven’t read the original paper, but the 'obvious Scrum mistakes’ you mention trigger me. Every time someone starts complaining about Scrum, I notice they have all these assumptions which are not grounded in the Scrum guide. When I point this out, the usual response is: well, that’s the theory, but I’m talking about the practice. When I ask if they have a scrum master or at least someone who coaches the team in scrum practices, the response is something like: there’s no budget for a scrum master, or scrum training. I wish my socratic conversation skills were better so I could get them to see their self defeating logic.
We all make mistakes (me included), and I'm much more interested in the results than the terminology. However, that being said, these mistakes and the lack of an Agile mindset often seem go to hand in hand. Correlation isn't causation though.
The reverse isn't true, I've also seen places where all the right labels and nomenclature were used but they still were missing the point.
It seems that SCREAM! is particularly geared towards educational settings, aiming to prepare college students for real-world challenges by engaging them in multidisciplinary projects. Such a good idea and placing greater emphasis on discovery and ideation are both good things as you noted. Someone should interview these clever professors so there is an interchange of ideas! Love this find so much!
I fully agree that scrum is NOT for researchers, architects, POs, stakeholder types. They really can not be bothered to go through the scrum process, I have seen literally tears when forced to do so.
Every situation is of course different.. yet I would not go so far toward introducing yet another new agile methodology. Existing ones like Scrum, Kanban, Scrumban can be combined on a single workflow if you have something like Jira.
As a software team requiring heavy design heres what we do:
- One workflow containing all states and transitions on a ticket for both ideation and development phases.
- 2 boards. 1 Kanban for Ideation phase, 1 Scrum for development phase, still the same ticket and workflow.
- The Ideation phase has the PO, architects, researchers, whoever working on Kanban to fill the "Dev Backlog" with tickets that meet the DOR (definition of ready). In our case the Ideation states are: Funnel (backlog) > Discovery > Design > Elaboration > Ready for Q&A > Ready for Estimate > Dev Backlog.
The ticket are prepared and presented in a Q&A meeting after which the Dev team take over to estimate the ticket. Spike (investigation) tickets can also be handed down to the dev team which is estimated as normal.
- Thus the "Dev Backlog" state is the end of the Ideation Kanban, and the start of the Development scrum process.
- From the Dev Backlog you run vanilla Scrum for the developers to keep things simple and predictable. The usual states: "Dev Backlog" (note: overlapping) > In Development > In Review > Done.
- For adhoc work you leave open a percentage of your capacity.
- We do 6 week cycles where the Developers do three 2 week sprints.The Ideation team produce in parallel a prioritised wishlist for the next 6 weeks.
- Ideation team have their own meetings as they see fit outside of the scrum process.
Did they actually name it SCREAM? 😅 I thought you were just being humorous. I'm not familiar with this relatively new approach, so thank you for your detailed research and work. I've learned something new from you, as always 🙌
There even is a Scream Master!
😂😂😂🥲
I haven’t read the original paper, but the 'obvious Scrum mistakes’ you mention trigger me. Every time someone starts complaining about Scrum, I notice they have all these assumptions which are not grounded in the Scrum guide. When I point this out, the usual response is: well, that’s the theory, but I’m talking about the practice. When I ask if they have a scrum master or at least someone who coaches the team in scrum practices, the response is something like: there’s no budget for a scrum master, or scrum training. I wish my socratic conversation skills were better so I could get them to see their self defeating logic.
We all make mistakes (me included), and I'm much more interested in the results than the terminology. However, that being said, these mistakes and the lack of an Agile mindset often seem go to hand in hand. Correlation isn't causation though.
The reverse isn't true, I've also seen places where all the right labels and nomenclature were used but they still were missing the point.
It seems that SCREAM! is particularly geared towards educational settings, aiming to prepare college students for real-world challenges by engaging them in multidisciplinary projects. Such a good idea and placing greater emphasis on discovery and ideation are both good things as you noted. Someone should interview these clever professors so there is an interchange of ideas! Love this find so much!
Hi Maarten.
I fully agree that scrum is NOT for researchers, architects, POs, stakeholder types. They really can not be bothered to go through the scrum process, I have seen literally tears when forced to do so.
Every situation is of course different.. yet I would not go so far toward introducing yet another new agile methodology. Existing ones like Scrum, Kanban, Scrumban can be combined on a single workflow if you have something like Jira.
As a software team requiring heavy design heres what we do:
- One workflow containing all states and transitions on a ticket for both ideation and development phases.
- 2 boards. 1 Kanban for Ideation phase, 1 Scrum for development phase, still the same ticket and workflow.
- The Ideation phase has the PO, architects, researchers, whoever working on Kanban to fill the "Dev Backlog" with tickets that meet the DOR (definition of ready). In our case the Ideation states are: Funnel (backlog) > Discovery > Design > Elaboration > Ready for Q&A > Ready for Estimate > Dev Backlog.
The ticket are prepared and presented in a Q&A meeting after which the Dev team take over to estimate the ticket. Spike (investigation) tickets can also be handed down to the dev team which is estimated as normal.
- Thus the "Dev Backlog" state is the end of the Ideation Kanban, and the start of the Development scrum process.
- From the Dev Backlog you run vanilla Scrum for the developers to keep things simple and predictable. The usual states: "Dev Backlog" (note: overlapping) > In Development > In Review > Done.
- For adhoc work you leave open a percentage of your capacity.
- We do 6 week cycles where the Developers do three 2 week sprints.The Ideation team produce in parallel a prioritised wishlist for the next 6 weeks.
- Ideation team have their own meetings as they see fit outside of the scrum process.
Well, good luck with that! (Getting my cv ready to go elsewhere)
What do you mean?
In above comment