Here's a format I recently used with Product Owner and a Scrum team - the origin escapes me.
Slide 1: what we thought would happen (our goal)
Slide 2: what actually happened (here's where we show our work)
Slide 3: what we need from you (our biggest questions eg have you had an opportunity to use the app)
Slide 4: what's next (our guess as to the goal)
Why we liked it as a team: it helped communicate our uncertainty to our sponsors and customers attending our reviews. Became easier over time to talk about things going wrong, constraints and get attendees to participate. We got good attendance and in some reviews convinced customers to demonstrate what they liked and did not like about the finished reporting apps. On one occasion the presenter was the sponsor who asked for the work to be done.
The context: a business intelligence team building reporting apps in a government transport agency. One of the challenges they identified when I started was getting stakeholders to care, and show up.
How the story ended:
I am sharing it here because as soon as the project was complete all this team momentum was lost. The team was dispersed to other work. The product owner's contract finished and she left. I am hoping one day the idea of long standing teams sticks. But I cannot see it happening with the current funding model and leadership. This is because of the short term project mindset, and approach to organizing everyone into resource pools. People are thrown at projects typically and then pulled out of them at short notice. The word "delivery" is frequently used, and "value" - rarely.
One thing will endure from the experience: Interviewed by volunteers from outside the project the team involved were enthusiastic about their work and the bonds they made working together. So were the stakeholders. I'll remember this as something I was proud to be part of too.
Thanks for sharing! I know it isn't a product company nor an agency.
I'm not a fan of the terminology hacking, if you want to do your own thing, by all means do it, but don't misuse existing terms that have precise meanings, and get them to mean something else.
I understand then it doesn't sound as cool anymore, but it's far better than teaching people wrong things and saying they are right outside of a business context (which I don't believe is a strong argument because Scrum is defined outside that context too as a framework for solving complex problems).
I am happy to help review your materials for accuracy, but you really shouldn't be teaching these things.
I have had very good success in using the Scrum Facilitators template for exactly the reasons you state.
thanks Deanna!!
Thanks for sharing, I will let Erik know!
Hi Maarten,
Here's a format I recently used with Product Owner and a Scrum team - the origin escapes me.
Slide 1: what we thought would happen (our goal)
Slide 2: what actually happened (here's where we show our work)
Slide 3: what we need from you (our biggest questions eg have you had an opportunity to use the app)
Slide 4: what's next (our guess as to the goal)
Why we liked it as a team: it helped communicate our uncertainty to our sponsors and customers attending our reviews. Became easier over time to talk about things going wrong, constraints and get attendees to participate. We got good attendance and in some reviews convinced customers to demonstrate what they liked and did not like about the finished reporting apps. On one occasion the presenter was the sponsor who asked for the work to be done.
The context: a business intelligence team building reporting apps in a government transport agency. One of the challenges they identified when I started was getting stakeholders to care, and show up.
How the story ended:
I am sharing it here because as soon as the project was complete all this team momentum was lost. The team was dispersed to other work. The product owner's contract finished and she left. I am hoping one day the idea of long standing teams sticks. But I cannot see it happening with the current funding model and leadership. This is because of the short term project mindset, and approach to organizing everyone into resource pools. People are thrown at projects typically and then pulled out of them at short notice. The word "delivery" is frequently used, and "value" - rarely.
One thing will endure from the experience: Interviewed by volunteers from outside the project the team involved were enthusiastic about their work and the bonds they made working together. So were the stakeholders. I'll remember this as something I was proud to be part of too.
Keep up the good Maarten and I can not wait for your Miro template to be out soon. How are we going to get it easily ? On Miro or???
Yes, it will be in the Miroverse! :)
Maarten, this is a very good analysis and it shows your deep understanding of the subject (of course!).
However, I think I missed the link to your Miro template 😉
Not out yet! :) Working on it.
I also read the original SCREAM paper, and it contains quite some Scrum mistakes. Would you want to receive a list of errata?
Could you please point to me where that was written in the original conference paper? I'll happily adjust if I missed something.
30K does not include the costs of the other people who are involved, and the cost of delay of 20 weeks. It's still too slow IMO!
But if you're only using it to provide an alternative pedagogical experience, then cost of delay doesn't matter indeed.
Also, why is it being compared with Scrum and not something like eduScrum then?
One other thing, SCREAM already exists as a parody of poor Scrum:
https://www.agilegothenburg.org/blog/2019-posts/the-scream-guide-is-out
Thanks for sharing! I know it isn't a product company nor an agency.
I'm not a fan of the terminology hacking, if you want to do your own thing, by all means do it, but don't misuse existing terms that have precise meanings, and get them to mean something else.
I understand then it doesn't sound as cool anymore, but it's far better than teaching people wrong things and saying they are right outside of a business context (which I don't believe is a strong argument because Scrum is defined outside that context too as a framework for solving complex problems).
I am happy to help review your materials for accuracy, but you really shouldn't be teaching these things.