Monday, February 22, 2021

Sprint Planning Isn't Hard.

Sprint Planning can be easy. 

An agile development team is like a stool with three legs: each team has a scrum master, a product owner, and the development team.  The team practices the values of the agile manifesto and the principles of agile development.  The scrum guide outlines several rituals where the team plans and prepares for work on the next sprint.  Efficiently running sprint planning can set up the team for success, and this week I want to provide some tips on making your sprint planning sessions better. 

As a product owner, it helps to follow Roman Pichler D.E.E.P. framework for a product backlog.  Stories should be detailed, estimates, emergent, and prioritized.  Sprint planning depends on correct prioritization to be successful.  The product owner arranges the backlog from highest priority to lowest.  All the bugs, stories, and spikes in the sprint should have a preference.  The team takes those stories and adds them to an upcoming sprint.  It is an ideal time for the development team to ask the product owner additional questions.  

On a high-performing team, all of the backlog stories are estimated through a process I call backlog coaching and refinement.  At this point, the team adds as many stories as necessary to keep the team busy for the sprint's timebox.  If the team uses story points, you take the team's velocity and place that number of story points into the sprint.  If you use a no-estimates approach, then add the total number of stories completed into the sprint.  Either method will work depending on the team.  

Finally, sprint planning is the meeting facilitated by the product owner.  Since the product owner is responsible for the backlog's health and what the team does next, they must explain user stories to the team and justify the work's priorities.  It is also up to the product owner to respect the social compact of agile. They must accept developers' timelines in exchange for the developers receiving the priorities of the product owner.  

The sprint planning session should be a collaborative meeting facilitated by the product owner to plan the work which needs to get done.  Once finished, the team should have all the necessary information to have a successful sprint.  It takes practice and obeying the D.E.E.P. framework for the backlog, but the team's efficiency will improve, which makes the struggle worth it.  

Until next time.   

Tuesday, February 16, 2021

Backlog Coaching and Refinement for Beginners

Ike knew a few things
 about planning and action.

During his retirement in the 1960s, Eisenhower talked about his leadership style and the importance of planning.  He said, "Plans are irrelevant, but planning is essential." It occurred to me the person who led the allied invasion of Europe would know a thing or two about planning and success.  The agile manifesto is very clear that teams should respond to change over following a plan.  What agilists forget is we need some form of planning to make sure we can respond to that change.  Today, we talk about backlog refinement and coaching, which is a planning session that you will find valuable.  

Three years ago, I was presenting at the Agile 2018 conference.  The best part of the experience was sitting in on other people's sessions and learning about agile from a different perspective. One of those sessions was "Transplanting the Brains of a Product Owner and Scrum Master." The presentation featured a few references to Frankenstein movies and the product owner and scrum master seeing the development project from their counterpart's perspective.  

A principal takeaway was the idea of coaching a backlog.  Just as a scrum master should coach their team to be better at what they do, a product owner should coach the backlog so the stories are easier to understand by the development team.  A backlog should tell a story about how it is delivering value to customers.  A scrum master and product owner can work together at these coaching sessions.  I like to include a member of the development team in these meetings. I have nicknamed this process backlog refinement and coaching sessions, which speeds up sprint planning because the development team is more fluent in the customer needs. 

Doing backlog refinement and coaching sessions help improve the skills of the product owner.  The product owner understands how much detail they need to include in a story.  A coaching session allows the product owner to prioritize work and enable the development team to do preliminary estimates.  Finally, refinement and coaching make the process of backlog management emergent as customer value is determined.  Communication created during the backlog's refinement and coaching will strengthen the ties between the team's particular parts: the scrum master, product owner, and development team.  

Backlog refinement and coaching allow the scrum master and product owner to trade brains to see their roles from a different perspective.  The scrum master considers the time and deadline pressure facing the product owner.  The product owner understands the juggling done by the scrum master.  

In summary, backlog refinement and coaching builds teamwork on the scrum team.  The process of having a few collaborative story writing sessions with the scrum master and members of the development team will speed up sprint planning.  Finally, backlog refinement will make the backlog more detailed, estimated, emergent, and prioritized.  Eisenhower was right; a plan is worthless but planning with backlog refinement, and coaching will make the scrum team better.  

Until next time. 

Monday, February 8, 2021

The Parking Lot in Agile

Get work done in the parking lot.

A common experience growing up in America is spending time with your teenage friends doing absolutely nothing.  We called the activity “hanging out.”  We would hang out in abandoned buildings, remote locations in the wilderness, and the basements of friends.  The only requirement was the absence of adults and plenty of free time.  For many American adolescents, the destination of choice was the parking lot of a local shopping center or strip mall.  Today, I want to discuss one of the more misunderstood places in agile - the parking lot.  

The term “parking lot” is not mentioned in the Scrum guide.  It is a practice that popped up over the last twenty years to prevent discussion in the Daily Scrum from diverting attention from the sprint goal.  In my discussion on the daily scrum, I said it was up to the scrum master to facilitate the discussion and divert the more detailed conversations into the parking lot.  

As the name parking lot implies, it is a place to host temporary discussions about topics over a finite period of time.  When you run down to the shopping center, you plan to leave your car in the lot for a short time, so you can leave quickly when you finish your shopping.  The metaphor should apply to conversations.

A parking lot discussion should be: ad-hoc, limited, and purposeful.  Parking lot discussions often pop up when there is a lack of knowledge or context.  Team members are asking how to do something, what is happening and why it is happening.  These questions can often be answered in a few minutes and by another member of the team.  Thus, questions can be answered outside the context of a formal meeting.  Parking lot conversations can be answered outside the context of a formal meeting.  

The parking lot often has a limited goal, so it should be focused on just enough information to keep work moving forward.  For instance, “where is the contract for the API, and is it strongly typed?” is a perfect parking lot discussion item.  “How are we going to make this web application sticky enough to gather all of the customer's personal information,” could drag on for days and should include more than just a brief discussion.  Finally, parking lot discussions should have a purpose.  Parking lot discussions should provide education, information, and meaning for team members; otherwise, they are wasteful.  

A parking lot, by its nature, is a transitory place.  You park, share information, and move on.  The parking lot is not a place where you should gossip, loiter, or create a general nuisance.  The business has plenty of opportunities for that kind of mischief.  So use the “parking lot” discussion to help your agile practice.  You will be glad you did.  

Until next time.

Monday, February 1, 2021

How a Daily Scrum Operates.

The scrum moves the team forward.

We are focusing on the basics of agile and scrum.  As a coach or scrum master, it is essential to cultivate habits that make them successful.  The most consistent thing a team can do is the daily scrum meeting.  It is one of those little things which can lead to massive success.  

A daily scrum satisfies three critical features of agile: inspection, adaptation, and empiricism.  The team uses the daily scrum to examine what they are doing and how close they are to meeting the sprint goal.  Based on the conversation, the team can then adapt to changing conditions.  The discussions are part of empirical thinking so everyone doing the work knows what is happening and why.  

Team members gather together in a shared space to have the daily scrum.  Since most teams are not co-located and rely on virtual meetings, it is vital to set up a consistent daily scrum environment.  Keep the forum time the same.  Use a regular background for your screen.  Turn on cameras, and everyone should be paying attention.  

Before the 2020 scrum guide, the daily scrum required everyone to answer three questions; what they did the day before, what they are working on today, and what impediments they are facing. The new scrum guide eliminates this requirement because the scrum alliance was concerned that daily scrums were turning into status meetings.  It is an adjustment, but I think it is a positive change.  The daily scrum should concentrate on one thing – the sprint goal.  Each team member should talk about how they are helping to achieve the sprint goal.  If the team accomplishes the sprint goal, they are delivering working software to the customer or client.  The daily scrum helps the team achieve the value outlined in the agile manifesto of working software over comprehensive documentation.  

Technical work is complicated, which might sidetrack the discussion.  These conversations can move to a "parking lot," which looks like the following.

Team Member #1: "I do not know how to use the contract for the restful web service for shipping addresses."

Team Member #2: "I wrote that the contract is easy to understand…"

Scrum Master: "Thanks gang, let us make that a parking lot discussion after the daily scrum."

It is then up to the two team members to meet and exchange information.  The scrum master or product owner can then follow up with them later in the day to make sure everything is moving forward.  

A daily scrum should be quick to respect the team members' time and focused on the sprint goal.  Finally, the team owns the daily scrum.  If a product owner or other member is late, it should start without them.  Starting on time and staying focused will build discipline on the team. 

Of all the rituals of agile, the daily scrum should be the most routine.  The team inspects its work.  Next, the team adapts to changing conditions.  Finally, empiricism guides all decisions.  A positive and productive daily scrum will go a long way in making the team successful.  

Until next time. 


Monday, January 25, 2021

Getting Back to Blogging

It is good to be back.

Long absences deserve an explanation.  Being a blogger while holding down a full-time job as a technology leader requires a significant time commitment.  Blogs need to be written and promoted via social media.  The twenty-four-seven media cycle is ravenous, and keeping it fed is exhausting.  It makes me wonder how more successful internet influences can keep up the pace.  Today on my blog, I feel I should explain my absence. 

I have been off-line for seven weeks.  During that time, I moved from my old house to a forever home with someone I wish to grow old with.  Picking up your life and consolidating with some else is hard given the most ideal circumstances.  In my case, my partner and I each had to sell a home and pooled our personal possession.  I was a feast of riches when it came to cookware, but it was a hassle getting it from our storage units into our home.  Additionally, we had a COVID-appropriate holiday with family and friends.  All the while, we were both working full time and working out of boxes.  Something had to give, and my blogging had to wait while I unpacked and developed a new routine.  

I am still unpacking, but I am settled enough to start writing seriously again.  The last seven weeks were a spectacle of poor leadership, resentment, grievance, and outright rebellion.  I feel compelled to comment on it, but I will keep my promise to avoid commentary like this because much better discussion exists on the political left and right.  My opinions will not provide any more additional illumination to the current cultural or political situation.  What I can contribute is my experience and wisdom relating to project and product leadership.  It is what I dedicated most of my life to understanding.  

The intermission has allowed me to think about how I will approach my little slice of the internet in 2021.  I would like to concentrate on the basics of agile.  Each week, I want to discuss the basics of agile from the daily scrum, to backlog coaching and refinement, to the standard of care.  Each week we will cover one of these topics and provide my readers with a foundation to build their own agile practice. 

The agile reformation is entering its twentieth year.  I have been part of it since 2009.  I have learned a few things along the way, and this year I will commit myself to share that wisdom with you.

Until next time.  

Monday, November 30, 2020

Give A Little Thanks to Help Your Agile Practice

Give thanks and let others
know you appreciate them.

The agile reformation does not happen by itself.  It requires numerous people working daily to deliver value to customers.  Scrum masters, product owners, and technical professionals come together each day and do the hard work of building new things.  It requires discipline and intelligence.  Each day, I am amazed at the new and innovative things the people I serve do.  We need to take time and express gratitude for the work we do for each other.  

The holiday season starts with Thanksgiving, which began formally as a holiday during the American civil war.  The Union was starting to turn the war's tide and hundreds of union and confederate dead were littered across battlefields from Pennsylvania to Georgia.  President Lincoln wanted to celebrate union victory but used the occasion to create an opportunity to reflect on what we were grateful for.  To our 16th president, being thankful and grateful was a means to unite a bitterly divided nation.  I like Lincoln’s sentiment; it shows his leadership was well ahead of its time.  

The Christian season of Advent and Christmas follow this season of gratefulness.  It is joined by the Jewish festival of lights and then Kwanzaa.  What unites all of these holidays is their focus on concentrating on what matters, especially during difficult times.  It is a shame that we need ethnic and religious holidays to remember this wisdom. 

As a coach, leader, or scrum master, it is up to you to let people know that you appreciate the work they do.  It is not touchy-feely goodness that inspires this sentiment, but detailed research by the Harvard Business Review and Forbes magazine.  Business researchers are discovering the common-sense notion of treating people with dignity can improve work performance.  A more humane office creates better results.  

Each day, I use the words 'please,' and 'thank-you.'  I refer to people by the names and pronouns they would like used.  I also want to pronounce the names of the people I work with correctly.  I have a funny-sounding foreign name, so I try to pronounce all the developers' names correctly.  It does not matter if someone comes from India or Chicago’s Oldtown neighborhood. You should be respectful of their name.  Respecting a person’s name respects them as a person and their culture.  Finally, before going home, try to meet your team members and thank them for a job well done.  I learned this at Harrah’s over twenty years ago, and it builds comradery on a team.  

The next few weeks will be a blur of work, shopping, stress, and COVID-19.  With all this flurry of activity, we should take time to express gratitude toward others and build respect, which will help us build a better day. 

Until next time.  

Monday, November 23, 2020

Emotional Effort is Required to Lead Agile.

Feel your feels. 

The software business is filled with plenty of highs and lows.  It is a profession filled with intelligent and mercurial people.  The trade is one of the few which resists automation because it requires humans to wrangle ones and zeros into something which mimics human thought.  You would think the people who work in this profession would be cold bodies of logic.  Instead, software developers are very messy and human.  Today, I want to discuss how we need to embrace the spectrum of human emotions that are part of the agile software development process.  

To learn how to write software, you have to have a unique mix of skills.  You need to understand the logic and how programming languages can execute that logic.  You have to learn how to be creative and manage levels of stress most employees never face.  Finally, you have to deal with frustrations and uncertainty because your first solution to a problem often does not behave as it should.  

The level of frustration combined with deadline pressure does something to a person.  If they seem grumpy or distracted, it is because they are attempting to solve a knotty problem.  When they are working, they are often trying to concentrate and focus.  Concentration is essential, so when someone interrupts them, the natural reaction is to lash out.  Spending time with computers and other inanimate objects creates a sense of isolation, making it hard to transition into social situations.  Finally, pride and ego issues come into play because developers want to look smart to their peers and valuable to the organization.  

Mix all these factors with traditional office politics and team dynamics, and it creates a complicated landscape for a coach or leader to navigate.  Spend time listening to people, both what they have to say and how they are saying it.  When a developer says, “I am fighting with a few bugs,” the tone of voice decides how you should react to the situation.

The office's pressure affects the team, home, and personal life can upset an individual’s balance.  A talented developer was having marital problems, and he quickly devolved into a weird and counter-productive spiral.  I squirmed as he shared very personal details of his marriage and its dissolution.  I should have been grateful that he trusted me enough to share those details.  Unfortunately, the team became front row spectators to their peer’s emotional disintegration.  It went from something which was a personal tragedy to a distraction for the entire team.  The kindest thing we did was take him off the team and work on independent projects.  It was what was best for him and the other developers at the office.  

The easy thing to do is fire the employee and not deal with the chaotic behavior.  Working with people is messy, and we should embrace that reality.  We welcome it because of the interaction of emotions, ideas, and people creates friction, generating the heat and light of new ideas.  A person I respect very much says, “you just need to feel your feels.”  

We need to respect and understand our emotions.  We also must respect and understand others' feelings if we are going to lead and coach them.  It is both the human and logical thing to do.  

Until next time.