KIMBERLY ANDRIKAITIS
  • Home
  • Shop
  • Blog
  • AMA
  • Links
  • Resume
  • Contact

Adventures in Agile

The Scrum Master Dilemma: To Mandate or Not?

1/8/2021

0 Comments

 
​During the Q&A portion of an Agile panel discussion, a Scrum Master asked the following question:
“My team prefers to have their daily scrum just twice per week. I know I can’t mandate that they have it daily, so what should I do?”
 
My initial reaction was to unmute zoom and shout “Of course you can mandate this! It’s called the DAILY Scrum for a reason!”, citing the official event title from the Scrum Guide. However, instead of prescriptively waving the Scrum gospel around, I paused to contemplate the word she used: “mandate”.
 
According to dictionary.com, mandate (when used as a verb) is to order or require; make mandatory. When you mandate something, you are coming from a place of authority, of leadership. You are now dictating the process; you are setting the rules.
 
Do Scrum Masters have the right to mandate rules to a team?
 
Yes.
And…
Sometimes no.
 
I know, I know, everyone hates a wishy-washy answer but hear me out.
 
Have you heard the phrase “Shu-Ha-Ri”? This term is derived from martial arts and is used to describe the progression of training or learning. Essentially, there are three stages of acquiring knowledge. I like to think of it as:
  • Shu Stage: Learn the Rules
  • Ha Stage: Bend the Rules
  • Ri Stage: Break the Rules
If the team is at the Shu stage, they need to master the basic rules before attempting to customize them. Using the Daily Scrum example above, a Shu level team needs to first understand and abide by the underlying guidelines.
 
For example, this means meeting on a consistent basis (daily), keeping the Daily Scrum focused, raising impediments, strategizing towards completing the sprint goal, and containing it within a 15-minute time frame. Until these elements of the Daily Scrum are truly ingrained in the team’s DNA, I would expect the Scrum Master to continually reinforce (mandate) these rules.
 
When the team has moved past “Shu”, the Scrum Master can take a more flexible or pragmatic approach.
 
What indicates that the team has advanced from “Shu” to “Ha”? Or from “Ha to Ri”? Unfortunately, there is no magical “Ha-Ri Finish Line”, but you can hunt for clues such as:
  • The Daily Scrum is held at the same time and place, regardless of who is in attendance.
  • The Dev team facilitates the event themselves, without relying on the Scrum Master or Product Owner as a crutch.
  • There’s vibrating, ambitious energy surrounding the completion of upcoming work against the Sprint timebox.
  • The conversation is natural and organic. Questions such as “When can we start testing?“  are raised and answered.
  • Team members freely request help and/or hold one another accountable.
  • The team’s Story Point burn down chart is clearly displayed and analyzed. The team focuses on the sprint trends and strategizes how they will meet their Sprint goals. 
  • The Dev team elects to meet twice a day, once during the morning Scrum and once in the late afternoon, as an extra touchpoint.
  • The Dev team prefers to work as a cohesive unit, situated in the same room, pair programming, or mobbing together.
The above examples are indicative that the team has fully embraced the agile mindset (being agile, not just doing it).
 
As a Scrum Master observing these behaviors, I would feel confident stepping back and allowing the Dev team to bend some rules (ie: scheduling their daily scrum twice per week). However, I would monitor them to make sure they continue to stay within the guardrails of the framework, values, and principles, since it’s easy to get complacent.
 
In summary, there is a certain rhythm and rigor to Scrum. The Scrum Master’s job is to promote/support Scrum by helping everyone understand Scrum theory, practices, rules, and values. How this looks depends on the maturity of the team.
 
The one question I will always go back to is: Is this a true Shu, Ha, or Ri level team? The answer to this question almost always determines the best approach or course of action. 
0 Comments

Sprint Planning - The Benefits of Tasking

9/13/2018

0 Comments

 
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.


  • A “task” is considered necessary if it must be done for that story to meet its acceptance criteria
  • Tasks aren’t just for development. There could be tasks for manual testing, automated testing or design sessions. 
  • There were times when they would write a task to accommodate one of the Definition of Done statements, so it wouldn't go unnoticed. 
  • In a perfect world, tasks should be written as deliverables since they are measurable. Instead of describing what you’re going to do, describe what you’re going to deliver. 

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.


  • Keep them small and manageable. As a general guideline, each task should be broken down small enough to complete in less than 1 day (6 hours). 
  • Advantages of small tasks: 
    • Easier to estimate.
    • Accuracy of estimates likely to improve (practice makes perfect!)
    • More measurable. 
    • Provides clarity during stand up on what work was completed (1 day tasks are either done or they are not!). We can visually progress as tasks continue to move through the process daily vs every few days.
5. Estimates are discussed and agreed on as a team.

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:
  • Understand the amount of work required to complete the stories
  • Identify which stories they feel comfortable committing to
  • Commit to the sprint (best case scenario - using the Fist of Five or Roman Voting technique for consensus)


Benefits of Tasking:
  • It fosters upfront planning which:  
    • minimizes the potential need for rework. 
    • allows us to discover unknowns sooner rather than later.
    • allows us to identify potential roadblocks or bottlenecks. By identifying them up front, we can plan the sprint better.
    • mitigates risk.
  • Keeps the team engaged in the whole sprint.
  • Fosters collaboration between team members.
    • Team gets clarity into potential impacts to other features due to the discussions that evolve at the planning session.
  • Uncovers gaps in the process or requirements.
  • Junior team members are involved in the strategizing process – allows them to understand the thought process from some of the more senior developers.
  • Offshore team members benefit by having access to the tasks needed to complete a story.
  • By knowing the number of hours available, we can realistically commit to the appropriate number of stories.
  • The team gains confidence in their commitments & delivering their sprint goals, coming out of the meeting.  
  • Burn down charts are accurate.
  • There is visibility into the work that is getting done – we can see tasks moving forward.
  • Multiple developers could work on one story which means getting it through to done takes less time. You know - that thing called flow.
  • Tasking allows for the “pull process” to work correctly (ie: tasks aren’t assigned; the team grabs their own tasks). This gives them a feeling of control and autonomy throughout the sprint. Sometimes this pushes them out of their comfort zone and challenges them. 

Challenges of Tasking:
  • All teams would need to agree on the # of hours/day for team capacity
  • Tasking is for the team, tasks aren’t meant to be scrutinized for anyone else.
  • Tasking at a planning meeting takes time (up to 4 hours per sprint).
  • Getting buy in from all the team members could be a challenge as well. One possible solution: start small. Take two team members to task out a story. Another option, at a starting point, is to only task stories that are medium --> large sized. 
0 Comments

Retrospectives Best Practices

8/14/2018

0 Comments

 
RETROSPECTIVES: 
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. 

BEST PRACTICES:

1.) Hold a retrospective at the end of every sprint. (Very Important.)

Basic Rules of Engagement:
  • The discussion focuses on the team (rather than individuals) and understanding (rather than defending)
  • All attendees are honest and transparent while treating each other with respect
  • The emphasis is on improvement; not criticism or attack
  • The attention is kept to items the team can control
  • All opinions are welcome

Retrospective Process:
  • The ScrumMaster shows the previous retrospective action items and follows up on their completion. 
  • The ScrumMaster also reviews Sprint metrics with the team (burn down/up, team velocity, cycle time etc.)
  • The areas of discussion have been prepared ahead of time and are visible to the team (this can be on a physical white board or virtual board). Some potential categories are as follows - but there are MANY MANY others you can choose from:
    • What worked well for us during the past sprint?
    • What did not work well for us doing the past sprint?
    • What should we do differently?
  • The team takes 10-15 minutes to reflect on the previous sprint in order to answer the three questions above. The entire team is engaged and each person contributes to each category.
  • Stickies are placed on the board below their associated category (<-- this assumes your team is colocated, if distributed, use a virtual whiteboard like Mural)
  • All items are discussed amongst the team and grouped (like with like) by the team. This nuance is important because the retrospective IS NOT FOR THE SAKE OF THE SCRUMMASTER, but is FOR THE TEAM. Their contributions subtly push them to the forefront of this ceremony as opposed to being passive observers. 
  • Each team member votes for three items they would like to see implemented. Typically, they vote on the items for improvement, not the things that went well. Because, well, that just makes sense.
  • The top 3 items are discussed amongst the team to determine measurable action items.
  • Measurable action items are assigned to an individual and followed up on during the next retrospective.
  • The meeting ends. Smiling, the team exits with a renewed excitement and optimism for the approaching sprint. 
  • All stickies from the retrospective are posted in confluence.


TIPS FROM OTHER SCRUMMASTERS: 

  • Because we have a team member off-site, we bypass the physical stickies & board in favor of www.noteapp.com (free for up to 2 people). The site allows us to collaborate fully by creating virtual color coded stickies which are used for dialogue. Since we can all view and discuss the stickies simultaneously, each team member is engaged and present.
  • I request two stickies per team member, since we’re such a small team. It’s a challenge, but they usually come through. 
  • What has helped my team is a neutral category or column.  We go through the typical what worked well and what didn’t, but I also have a spot for both which I refer to as neutral.  This has allowed the folks on the team to bring up something that they could classify in both the “worked well” and “didn’t work well” column and I’ve found that with a neutral category it helps to bring out comments, thoughts, etc. that may not have come up because it wasn’t clear cut which bucket it fell into.   
  • We start retrospectives with Appreciations.  It’s a nice way to say thanks to individual people in the team or the whole team for something to specifically call out.  Like thanks for the extra effort in getting X accomplished or thanks for helping me do X.
  • Try to schedule your retrospective as soon as possible. We found that team members forgot  what worked and what didn't work when the meeting was held too long after the sprint ended. 
  • Post meeting notes "privately" in confluence so only you and your team members can access.  This will help the team stay honest about continuing to do what works, starting new things to improve processes, and stop doing what isn't working.
  • If you have shy team members, be sure to remind them to bring their items to the meeting ahead of time. In the beginning, I would start by sharing what I believed worked and didn't worked. This would get the ball rolling. As time went on I would simply call people out if no one volunteered to speak first.
  • Everyone should be reminded to NOT take any of the negative feedback personally. Remind the team the goal is to improve as a team.
  • Give shout outs to team members who recommended or suggested a new process, that worked. This is great way to encourage others to share their ideas and suggestions in the future.
  • Encourage team members to come prepared with a solution to an issue. For example: The complaint is Standups are taking too long - much longer than the allocated 15-min timeslot. The team member should also be prepared to offer a way to resolve this issue such as use an egg  timer to be sure each participant doesn't go over their 2 minutes. This will prevent the team from just sitting and dwelling on what didn't work without some type of solution to the issue in mind.
  • We’ve combined the what didn’t go well and what we should do differently. This really makes everyone think about how we can improve and also helps it from feeling too negative.
  • We are a small team too, and generally, even though my team members are not shy, we get along well, communicate well, and go smoothly through our sprints without really any issues to discuss. Probably any team that has members that have worked together for a while are like this. I always start each retrospective by reviewing the last sprint. It lets us add any items back to the list that still need work, and kind of puts them in the mindset of the meeting through reflection.
0 Comments

Release Retrospective Considerations

7/1/2018

0 Comments

 
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: 
  • What were the major milestones in this release? 
  • Who were all the team members/roles, stakeholders, influencers? When did they join/leave?
  • What worked well in this release?
  • What were some “Ah Ha” moments?
  • What was frustrating for us?
  • What were our major distractions?
  • What do we still not understand?
  • How well do you think we did?
  • What practices do we want to keep or do again?
  • What can we throw away / what’s not working?
  • What are our ongoing problems?
  • What problems can we fix or escalate?
  • What 2 or 3 new things would we like to try?
  • What is our action plan for instituting these recommendations?

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. 
0 Comments

Refinement Best Practices

6/6/2018

0 Comments

 
VALUE:
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:
  • removing user stories that no longer appear relevant
  • creating new user stories in response to newly discovered needs
  • re-assessing the relative priority of stories
  • assigning estimates to stories  (in the form of Fibonacci* story points, t-shirt/animal/vehicle sizing etc.)
  • correcting estimates in light of newly discovered information
  • splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration
  • determining if research spikes are necessary before a story can be worked on
 
 
BEST PRACTICES:
Prior to the refinement session:
  • The Product Owner prepares the stories by adding descriptions, clearly defined acceptance criteria and other appropriate artifacts. This ensures the story is well understood by the PO and that they are prepared. 
  • Once the PO has a good idea of which stories they want to discuss, they forward a prioritized list to the team. The team can review the stories beforehand and gather their thoughts and questions; thus increasing the effectiveness of the meeting. 
 
During the refinement session:
  • The PO summarizes what she expects to achieve so the team has a clear understanding of the goals of the meeting.  This could simply be something like “I’d like to walk out of this session with 4 groomed/refined stories.”
  • The Product Owner focuses the team’s attention on the first story, using the prioritized backlog. The story is reviewed and the team is encouraged to collaborate, ask questions, suggest modifications and provide feedback. 
  • Once all concerns/questions/comments are addressed, the Product Owner requests a high level story point estimate (relating to size & complexity), using the Fibonacci sequence.  Story points allow POs to quickly size features and consider the sprint plan without getting bogged down in implementation details. 
  • If there are team disagreements, the ScrumMaster reiterates that story points should be decided by consensus and opens the floor for the team to reach a resolution.  Some level of consensus should always be possible.
  • As a general rule of thumb, each story discussion is time boxed (I like 12 minutes per story) to keep the conversation moving and not get bogged down in the implementation details.
  • Not all refinement sessions will be straightforward and uncomplicated. There are times research spikes are identified or stories need to be further split, and story points just can’t be identified.
  • Although the PO needs to recognize their meeting goals, they should be adept enough to keep the session moving and organized enough to return to the following session, with the new spikes/stories in hand.
 
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. 

 


0 Comments

Proving the Value of the Sprint Review

5/18/2018

0 Comments

 
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 event 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 review.
 
Due to this particular Scrum event, the team identified gaps which could then be immediately addressed.
 
They inspected.
They adapted.
 
… And in my eyes, that’s a major win. It’s what Scrum is all about.
0 Comments

This is their meeting...

4/12/2018

0 Comments

 
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: 
  • Code Quality
  • # of defects
  • Story estimates > Reality vs. assumptions 
  • UX (fine tuning; giving attention to detail)
  • Finishing on time
  • Planning & Refinement discussions
 
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.
0 Comments

    Author

    Just an agile-dork writing about dorky agile things.

    Archives

    January 2021
    May 2020
    April 2020
    March 2020
    January 2020
    July 2019
    April 2019
    December 2018
    September 2018
    August 2018
    July 2018
    June 2018
    May 2018
    April 2018

    Categories

    All
    Coaching
    Introspection
    Relationship Building
    Scrum Events
    Scrum Values
    Working Remote

    RSS Feed

Proudly powered by Weebly
  • Home
  • Shop
  • Blog
  • AMA
  • Links
  • Resume
  • Contact