For someone involved in non-technical delivery, I would expect they had experience delivering agile projects.
(Of course, agile projects typically call them product owners instead, a subtle distinction.)
I've been involved with agile projects since 2006 and I am still learning new ways of delivering software that solves the right problem, developing team cohesion, surfacing risk early, and other things you don't learn in the 3 day class.
I can teach Scrum in 30 minutes, but there should be an actual expert around until enough of the group has internalized the reasons for the concepts and feel like they can adjust it to suit their situation without fear of dogma. (This expert, however, won't usually cost $200,000 unless they signed the manifesto themselves or are otherwise agile-famous.)
(Here's the 30 seconds if you don't have anyone around. Start with trying to group the next most important thing to do in a 2 week chunk. Every day, talk with each other and make sure to surface any problems and risks as fast as possible. Have at least one person who will use the software sitting with the team to answer questions as they pop up. And every week, take an hour to figure out what's working well, what isn't, and what you need to adjust to make things work more smoothly. There are dozens of technical and organizational practices to go through and try, but the best is to keep the ones that work for you, ditch the ones that don't.
Standups and Demos are just 2 of those organizational processes. Use them if they work, ditch them if they don't. For example, I'm currently working with expert practitioners and we're not doing a standup because we're small enough, work close enough together, and have worked with each other long enough to just talk.
>> Here's the 30 seconds if you don't have anyone around. Start with trying to group the next most important thing to do in a 2 week chunk. Every day, talk with each other and make sure to surface any problems and risks as fast as possible. Have at least one person who will use the software sitting with the team to answer questions as they pop up. And every week, take an hour to figure out what's working well, what isn't, and what you need to adjust to make things work more smoothly
Product Owner is not the same as Project Manager. Product Owner is similar to Product or Program Manager in software, though the Product Owner role is usually a subset focused on software development and does not include go to market and P&L.
SCRUM Master role is the closest to a Project Manager.
The SCRUM Master isn't on all agile projects, but the SCRUM Master can be any combination of rotating team member responsible for following up on team tasks and facilitating SCRUM rituals to a full agile coach responsible for team coaching, organizational-wide systems/process analyst and change agent. Sometimes they get saddled with traditional project management deliverables as well.
The product owner, however, controls the backlog, and the yes/no in what defines the product is most often the most important (and difficult) position of the PM.
Right, Product Owners (like Product Managers) define the "what" of the product, effectively guiding the team on what market problems to solve and for which customers.
That's different from the Project Manager who works on resourcing and timing of a project.
For someone involved in non-technical delivery, I would expect they had experience delivering agile projects.
(Of course, agile projects typically call them product owners instead, a subtle distinction.)
I've been involved with agile projects since 2006 and I am still learning new ways of delivering software that solves the right problem, developing team cohesion, surfacing risk early, and other things you don't learn in the 3 day class.
I can teach Scrum in 30 minutes, but there should be an actual expert around until enough of the group has internalized the reasons for the concepts and feel like they can adjust it to suit their situation without fear of dogma. (This expert, however, won't usually cost $200,000 unless they signed the manifesto themselves or are otherwise agile-famous.)
(Here's the 30 seconds if you don't have anyone around. Start with trying to group the next most important thing to do in a 2 week chunk. Every day, talk with each other and make sure to surface any problems and risks as fast as possible. Have at least one person who will use the software sitting with the team to answer questions as they pop up. And every week, take an hour to figure out what's working well, what isn't, and what you need to adjust to make things work more smoothly. There are dozens of technical and organizational practices to go through and try, but the best is to keep the ones that work for you, ditch the ones that don't.
Standups and Demos are just 2 of those organizational processes. Use them if they work, ditch them if they don't. For example, I'm currently working with expert practitioners and we're not doing a standup because we're small enough, work close enough together, and have worked with each other long enough to just talk.