I consider myself an outgoing introvert - definitely reserved among a large group of unfamiliar faces, but genuinely engaged & energized when it's one-on-one.
In my spare time, I gravitate towards jigsaw puzzles, reading, coloring, crafts, meditation and yoga. My energy tends to soar after brief periods of solace and silence, my mind woken and brain invigorated. Following this recharge, I've reached the pinnacle of my social self - the Kim who wants to peel back the inner layers of my colleagues / friends / family members ... strengthen relationships.. form tighter bonds... become BFFs....
Sometime this enthusiasm isn't shared, as I've encountered a sprinkling of withdrawn / quiet / "leave me alone" types during my IT years, And I get it.
I really do.
However, as a Scrum Master, I am compelled to build relationships and strengthen bonds, but I'm also sensitive to the fact that this goal may not be reciprocated. Which I find, to be a tragedy, really.
To nudge people into opening up, I've created a sampling of powerful questions (shamelessly stolen from my own coaches) - which seems to do the trick. I keep these questions posted on my monitor and return to them when/if conversation stalls.
Here they are:
Internal to work
Outside of the office
A few tips:
* Never ask a question you don't feel comfortable answering yourself.
* Use these questions sparingly! The intent is not to ambush or interrogate our colleagues.
* Consider your audience - if you feel the question may not be taken well, don't ask it! Employ common sense, empathy and respect.
I hope this helps! Do you have additional questions I can add to my list? Let me know!
What is Sprint Planning?
Spring planning is needed for the team to negotiate which stories will be tackled within the sprint. This should be decided after reviewing the number of hours available against the number of task hours required. In addition to hours available, the team should understand their velocity/trends as well - but that's another blog altogether.
How is it done?
1. The Product Owner prioritizes the refined sprint backlog stories and clarifies requirements.
2. The team’s “Sprint Budget” is identified – this is the number of available hours the team has to work on during the sprint. Ideally, the dev team is allocated to working 6 hours per day, to account for meetings and other interruptions.
In my Deutsche Bank days, the team would write their names on the whiteboard (stacked, as rows) and the days of the sprint (as columns). Looking at the days, they would write a "6" within their row for all days they would be working at 100% capacity. If there were holidays, PTO, offsite training - those days would be shown as "0". We would count the number of all teammember hours available and notate that as well.
3. Stories are deconstructed into tasks.
As a Product Owner for this group, I taped & prioritized the printed stories / wireframes / gherkins etc. to the whiteboard. Before tasking began, I would review the stories one last time and answer any questions. From there, they would self organize into small groups and tackle the tasking for each of the stories.
4. Tasks are estimated in hours.
6. Add up task hours and deduct them from the Sprint Budget.
7. Commit to the stories the team knows they can get done.
8. Identify several stretch stories just in case the team delivers early.
My DB team was cross functional and "T" shaped. The developers were able to assist with testing as needed, which allowed them to truly own & swarm on work. During the tasking part of this meeting, the Product Owner is not involved although she should be available for any questions that arise. Typically, the ScrumMaster facilitates this session with the team members.
The end result of this session is for the team to:
Benefits of Tasking:
Challenges of Tasking:
As Scrum Masters, we are responsible for having the courage (<-- One of the scrum values) to not only observe, but to also provide tangible, constructive and valuable feedback to our team members as well.
Even if it’s uncomfortable / awkward / scary.
I grew up an only child and was thrilled when praised by my parents, teachers, friends, family etc. Accolades in the form of hugs, paper certificates, applause, shiny gold star stickers or smiles confirmed my value and motivated me to maintain or improve my good work.
As a professional adult, I still bask in the warmth of positive recognition and compliments, but know it’s not always sunshine and daisies. I can recall a conversation with a previous manager/mentor who once asked how I like to receive feedback. I smiled. “Are you familiar with the shit sandwich?”.
The “Shit Sandwich” is built like this: Bread (flattering content) + Meat (unflattering content) + Bread (More flattering content).
Because I’m an extremely sensitive perfectionist and I absolutely hate to disappoint, I respond well to this structure. Although I’d love a delicious glutinous carb only toasted sandwich, I welcome observations and suggestions for further improvement.
My second favorite feedback tool is the SBI, which stands for “Situation, Behavior, Impact”.
According to The Center for Creative Leadership, “When you structure feedback in this way, your people will understand precisely what you are commenting on and why. And when you outline the impact of their behavior on others, you're giving them the chance to reflect on their actions and think about what they need to change. The tool also helps you to avoid making assumptions that could upset the other person and damage your relationship with him or her.”
Here’s a real world example:
During our retrospective yesterday (situation), you were texting on your phone when the other team members were adding sticky notes to the board (behavior). You are highly regarded on this team so when you appear checked out, I’m concerned that other team members will also follow suit. (impact).
For me, the SBI method is easy to apply and helps to provide behavior changes. Also, it allows me to completely consider the what, why and how prior to the conversation.
To find out how they would like their feedback to be given, provide a few options to your team members. By opening the conversation this way, you’ll have a much more engaging and effective discussion.
The purpose of a retrospective is to inspect how the previous sprint went with regards to people, relationships, processes and tools. This is where we reflect on ourselves and our work in order to identify the good, the bad and future opportunities.
Retrospectives allow us to create an actionable plan to implement improvements so that we can become better at what we do. After all, the bad habits we have developed over the years are not going to disappear with the wave of a magical wand & a "bippity bippity bop!". Teams have to continually work to reinforce good patterns of behavior and eliminate the not so good.
1.) Hold a retrospective at the end of every sprint. (Very Important.)
Basic Rules of Engagement:
TIPS FROM OTHER SCRUMMASTERS:
I like to schedule an 'as needed' Release retrospective with my teams for them to inspect the release from a holistic, big picture point of view. It's essential to pause from the nitty gritty of everyday coding/testing so they can review the release process and course correct/pivot if necessary.
The list below includes some questions that I ask the team to mull over, so they can pinpoint, assess and identify improvements.
Questions to consider:
To save the team time and to allow for some serious juicy conversation, I will forward this list of considerations a few days ahead of time.
The intent of the refinement ceremony is to ensure the backlog remains populated with items that are relevant, detailed and estimated to a degree appropriate with their priority; and current understanding of the product and its objectives.
The team (Product Owner, ScrumMaster, Developers) meets regularly to refine the product backlog, which can lead to any of the following:
Prior to the refinement session:
During the refinement session:
More information on estimating stories based on the Fibonacci sequence can be found at: http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps-step-2-how-to-estimate-your-product-backlog/
TIPS FROM OTHER AGILE PRACTIONERS:
- My team meets daily for an hour; we alternate Design meetings with refinement sessions. Yes, this is time consuming -- however, since we’ve already discussed the story implementation beforehand (during Design), we’re able to efficiently identify story points and tasks during refinement.
- Having 2 refinement Sessions per week keeps us from falling behind. In addition, I have a nice set of stretch and future sprint stories to pull from.
- For any team members off site, we use either Pointing Poker, Planning Poker or Plan-It Poker. (All are free, and defaults to Fibonacci point values but can be customized ahead of time).
- I like this because
• Team members can vote when they are ready and there is a button to ‘Show Votes’ all at the same time.
• There is a timer that re-sets after each ‘Clear Votes’ has been triggered (optional)
• There is the option to join a session as an Observer.
- I always try to have an Acceptance Meeting at least a day or two before each refinement session to make sure there are no questions in regards to testing. I always book it, but we end up cancelling if we don’t need the time which is about 80% of the time. If we are all on the same page, I know that the refinement session will go smoothly. If we’re not, I at least have some time to add more details or even split a large ticket into smaller tickets before the refinement session. Also, having them aware of the tickets is almost as much detail as I am will allow him to help me timebox in the refinement session so we stay productive.
- The QA on my team reviews the stories before the developers see them, so they can verify that the acceptance tests are captured and that the story is testable.
- I send the list of stories to the team about 24-48 hours before refinement. They review them and reply all, responding with questions or red flags about the stories. This lets us identify stories that require a design session or other technical planning and are not yet ready for refinement.
- During the meeting, each story is timeboxed – 4 minutes for discussion, everyone throws points, then 2 minutes to discuss and agree on points. If a story needs more than 6 minutes, it’s not ready for backlog refinement and we hold it for a design session.
**Just an additional note **
You may have heard this ceremony referred to as “Grooming”, but recently, that word has been given a pretty bad connotation. Which is why it’s “Refinement” is the more accepted substitution. You're welcome.
During a recent retrospective, my newly formed scrum team raised a concern that they weren’t “plugged in” with one another throughout the sprint. They were all working on stories which contributed to the goal, but they didn’t see the outcome of their work. An action item was raised for the following sprint: “Incorporate sprint reviews” which they all agreed was needed.
As you are probably aware, the purpose of this meeting is “to inspect the increment and adapt the Product Backlog if needed”. Therefore, I scheduled the review prior to their sprint planning and retrospective. The day before, I reminded them of the upcoming demo and requested they self-organize, keeping it contained to 45 minutes.
The day came and each team member demonstrated the results of their work. They asked each other questions and clarified various misunderstandings, but mostly it was smooth sailing.
At one point, the Product Owners ears perked up on a particular comment made by one of the Dev's. He recognized that something was amiss and probed for additional clarification. Apparently there was a security gate that hadn’t been considered for production. Following a lengthy discussion, the team ultimately changed direction -- adding 3 new high priority stories for the next sprint, in order to address the discrepancy.
The PO was astonished and questioned why this wasn’t raised earlier. Frankly, he was frustrated, which was understandable – I probably would have been too. However, as the Scrum Master, I was elated! I could barely contain my excitement -- this was precisely the point of the sprint demo.
Due to this particular Scrum ceremony, the team identified gaps which could then be immediately addressed.
… And in my eyes, that’s a major win. It’s what Scrum is all about.
As with most people, I typically act based on what’s important to me. As an example, at retrospectives I show burndowns, burnups, velocity. I talk with the team about predictability and throughput. I remind them of the importance of collaboration and sprint commitments. Essentially I communicate what I believe is imperative for team success.
I’m often met with silence, which I assume means disinterest. The longer I speak, the more frustrated I become because WHY AREN’T THEY INTERESTED IN THIS? IT’S SO IMPORTANT!!!!
Being that my teams are distributed, I’m unable to assess body language - but I can see their pupils glaze over and eyelids flutter. Lately, the retrospectives have been painful and rather uncomfortable. The team is disengaged & quiet, and honestly -- even I don't look forward to them. I realized it’s time for a new approach.
In my quest for continual self-growth, today I stumbled across this quote: "This is their meeting, not mine.” (how strangely coincidental!)
This is so obvious.
And so simple.
How did I forget?
Pushing my ego to the side, I arrived at a retrospective this morning with one question for the team: “What do you care about?”.
For once, quiet team members spoke up. Eyes shined a little brighter. Developers were eager to answer that question. The answers were varied:
This was astonishing to me. They talked about their true concerns & took ownership of the actions. One person even voicing his anxiety of the roller coaster velocity (!!). We didn’t focus on the sprint per se, but the team identified what was really on their minds.
By flipping my objectives into a true servant/leader mindset, we were able to have a very direct, efficient conversation, resulting in actionable goals - and ultimately team improvement. (<-- Important to me! )
I guess, sometimes we don’t see the forest through the trees.
Just an agile-dork writing about dorky agile things.