j icon

Scrum Chronicles #3

Published: 2022-12-30

This post is a continuation of a series of LinkedIn posts I’ve made this week chronicling the Agile transformation process I’m currently undergoing in my marriage. Links to those posts are below:


Scrum Chronicles #1:

https://www.linkedin.com/feed/update/urn:li:activity:7014262944754540544/


Scrum Chronicles #2:

https://www.linkedin.com/feed/update/urn:li:activity:7014569603632676864/


The path begins to take shape with a dose of humility

I went out to take recycling and came back to Meg having re-done all of the sticky notes on the board we mounted last night. She had devised a color coordination system that put backlog items into categories (chores, house/renovation, play, other, jj/meg professional development). She had also re-written many of the items.


1f060017-9e46-40b7-a031-6fab6480392d

There were two reactions I had.


The good reaction: “Wow! You’re really buying into this and it feels really good to be on a team with my wife instead of feeling disconnected.”


The ugly reaction: “WHY DID YOU RE-DO EVERYTHING IS THIS SOME KIND OF COMMENTARY ON MY HANDWRITING AAGGGHHHHHHH.”


Because yes, I’m human and both my higher self and insecure self are always wrestling for control of the steering wheel.


What makes Agility difficult, in my experience, is the human need for control and how much Agile encourages us to let go of control (not planning too far into the future, embracing unknowns) and be part of a bigger whole. One of the things that draws me to the role of ScrumMaster is the idea that this role has no inherent authority in the traditional managerial sense. A servant leader leads in a very different way, and ultimately empowers others to manage themselves by acting as a coach, mentor, and teacher. They don’t have the final say.


I experienced that acutely today with Meg. I wanted to take control and dictate how things should be done. But, I was able to take a step back and realize that her changes were awesome and I wouldn’t have done it like that. We’re a team and the cool thing about being on a team is how the product that comes out of a good team is greater than the sum of its parts. This was a small and powerful reminder of that.


What followed after that initial reaction was a great conversation where the shape of our Scrum implementation began to take form.


Events

There are five events defined in the Scrum Guide that act as containers for work done by a Scrum Team as well as the interactions that keep a team creating value and improving continuously. Those events are the Sprint, Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective.


I won’t go into a nitty gritty definition on each one, but I will describe how we’ll be implementing our own versions of some of these events.


The Sprint

The heartbeat of Scrum is the Sprint. A Sprint is a set increment of time during which work on a project or endeavor is completed. It is no more than a month and typically covers two weeks. It acts as the parent most container for the other events in Scrum and creates a repeated cycle of those events and the time spent doing the work itself so that feedback is quick on the results of work and how the team can improve its processes and interactions.


Meg and I decided on two weeks for each Sprint. We used to do “State of the Union” meetings that were supposed to happen each week, but our work schedules and social calendars made it hard to do those with consistency. Two weeks gives us a short enough time period to be meaningful but not so short that we spend all of our time outside of work…. in more meetings with each other. I don’t know about you, but that sounds like the opposite of the type of freedom and sanity a good Agile organization promises.


We also decided that anything in the “Doing” column of the Kanban board would be anything we’ve planned for the current Sprint, since the board exists as a high level look at what we want to be working on during a Sprint, not a day to day task board. Talking about those specifics has already gone a long way at reducing the cognitive overhead and confusion that comes with not explicitly stating how we are organizing and looking at the visible work we’ve accumulated and planned.


Daily Scrum

The Daily Scrum (or Daily Standup if you’re coming from other Agile Methodologies) is a daily meeting time boxed at no more than 15 minutes. During that meeting, you share progress you’ve made, talk about your goals for the day, and share any impediments you’re facing towards completing those goals.


Meg and I opted to not do this daily in the morning, but instead in the evenings when we are sitting down for dinner. This makes the most sense for our schedules - much of what we are trying to coordinate happens in the margins around work, not during our work day. Our Kanban board is mounted next to the dinner table to make that conversation organic.


Sprint Planning/Review

Sprint Planning is the first event of a Sprint where the Developers on a team decide what work they will pull from the Product Backlog to the Sprint Backlog and work on during a Sprint. For Meg and I, the Backlog contains a combination of recurring household tasks and singleton tasks, as well as higher level commitments (like my 10 day training course for the PSM I certification and her chaplain professional development activities).


We decided to plan when exactly we would do the next Sprint Planning each Sprint since our schedule is changing so often. We haven’t done a planning yet, but I imagine it won’t take very long (maybe 30 minutes or so) if we’re keeping the Daily Scum going consistently enough and have a good finger on the pulse of what’s happening with our home and marriage.


This event is also where we will review progress from the previous Sprint. This is typically done in a separate event, but it seemed like too much to have that many events every two weeks when we’ll already be shifting items around the board and talking about how things went anyways.


Sprint Retrospective

All of these events can make a marriage feel too much like a business and not like a relationship that is also meant to be nurtured and enjoyed. So, we decided to make the Sprint Retrospective, which is an event during which a Scrum team steps back and talks about how they can improve the way they work together, a date. That means we’ll have two dates a month on the calendar (at least) and can have that conversation in a relaxed, non-reactive way. This is the time when we’ll make adjustments to any of the tools, processes, and interactions we have so that other events can be more dialed in to a single purpose.


Into the Unknown

I’m really excited about how things are shaping up. Seeing all of the items on our Backlog is huge for transparency and accountability. Now, when one of us wants to add something, it takes up physical space and sits next to other ideas and commitments we’ve made. It helps us balance our activities (are we neglecting home tasks or forgetting to have fun?) and have less reactive conversations about our priorities as a couple.


The next post I write will cover our first Sprint Planning session and how I plan to manage my commitments we make during that session along with my other personal and professional commitments. Stay tuned!


👈 Back to Blog Home