Attaining the PSM I = Greatest affirmation of my career
Hi everyone!
So while I'm fairly new to these forums, I've been practicing Scrum since 2009.
There were successes and failures along the way, but the part about empiricism has definitely helped me in my last venture as Scrum Master and became the backbone to being a more efficient servant-leader in helping the Scrum Team.
I was actually studying for an Agile certification last year but had to put it on hold for other reasons, but I'm happy to say that I got my PSM I last week.
This for me was by far the greatest affirmation in my career, especially coming from a guy with a Multimedia Arts background and spent the first part of his career in Creative Advertising. Turns out, things like protecting my team from impediments and allowing them the freedom to be self-enabling towards developing collaterals for ad campaigns were things I carried with me as I learned Scrum when I switched to game dev and app dev industries.
Really looking forward to improving my fundamentals in Scrum as I continue my career in this path!
Congratulations! You say you learned Scrum when you switched to game dev; how well would you say empiricism applies to creative advertising?
Thanks Vincent!
Regarding your question on empiricism in creative advertising, I think my team of designers back then were pretty fortunate that we had recurring ad campaigns during a calendar year, and when a campaign would come up, we could look back at the previous times we worked on our deliverables so we can assess what worked/failed/could be improved, and keep those in mind when we started working on that campaign. It also helped us get an idea of "velocity" heading towards the campaign's launch.
We didn't run sprints back then but we were, in a way, able to design the entire campaign incrementally. If I had to turn the work we did into a Product Backlog for instance, I think what we would have had was:
Feature: Campaign's Main "Comp" (which also would have been a Sprint Goal)
- User Story: As a user, I want a campaign's main look to represent its visuals and can be translated to different sizes and forms of delivery. Acceptance criteria would be: Contains all important information of Campaign, all sponsor logos visible and sized appropriately based on sponsor type (main sponsor, secondary sponsor).
- Tasks would have been: "Create a study of the main design" (assigned to each member of the team), "Internal review of design", "Have design approved"
next sprint goal would be "Campaign's design, delivered in all known orientations and sizes (horizontal/vertical)", then User Stories would have been "As a user, I want to see a vertical orientation of the design that was suited for large-print campaigns" or "As a user, I want to see a horizontal orientation of the design that is suited for web ads".
Something to that extent. Hope that made sense!
Very interesting, thanks!
Thanks Raphael for this feedback.
You write:
things like protecting my team from impediments
Could you give some examples? Indeed, I'm preparing to act as Scrum Master, and I really would like to be "prepared" to this kind of challenge: facing and solving impediments.
Hey Nicolas, I just saw your post.
Impediments are pretty much anything that could hinder the Development Team from progressing with the work that brings a User Story to the definition of done. Based on experience, it can be both internal and external.
Internal impediments could be "workstation is slowing down, so compiling code is taking longer than usual", or "I do not know how to approach this specific task", or "I'm confused about how the use cases on this user story".
External impediments can be "someone asked me to enhance this feature from a previous sprint because they want to demo it for a client".
Now we won't be able to immediately get rid of, or be rid of, all impediments as they can and will happen. As Scrum Masters, we need to serve the Scrum Team by addressing these and solving to maintain efficiency towards the Sprint Goal. Some things that have helped me in the past are:
- Make sure everyone in your Development Team mentions any impediments, but make sure not to go over the timebox for Daily Scrum; gauge if the conversation on the impediment has no resolution, in which case "park" the conversation til after the Scrum then discuss it.
- Always make sure to facilitate discussions and guide the team through what caused the impediment, the effect it has should it linger on, what are the possibilities to resolve it. You don't need to know the answers to everything, but you can bring the team towards resolutions. From the examples I brought up, workstation performance may mean upgrading parts, coding approach might be an opportunity to pair program with another member of the team, use cases can be discussed with the Product Owner to provide clarity.
- Safeguard the Scrum framework, especially for people within the organization who don't know how it works. In the instance of the external impediment, I would talk to the person who had that request and recommend talking to the Product Owner; while the idea of the enhancement would seem simple enough in their eyes, that is still time away from development, and could easily be underestimated.
I guess just be aware of what's happening around the Scrum team. Remember, "Inspection, Transparency, Adaptation"... if you are able to check what's going on, understand why it's happening and adjust accordingly, then you'll be ready to deal with these impediments.
Hope that helps!
Thanks a lot Raphael for these detailed examples, it gives me a clearer view of what can be impediments. And it fosters my willingness to help the Dev Team by removing them :-)