Talking about the Team

October 27, 2017October 27, 2017 Alec Hardy Leadership, Organization, Team QA, Team

One of the hallmarks of being agile versus merely doing agile is that scrum team members contribute in whatever way is needed for the team to meet the sprint goal. Old habits of dividing roles into teams can be a barrier to realizing the benefits of agility.

Before agile, many organizations had “development teams”, “QA teams”, “UX teams”, etc. To be agile, the organization should promote a culture where there is a “Scrum team”, which consists of a ScrumMaster, PO, developers, QA people, test engineers, and anyone else who helps get stories to “done”. Everyone on the Scrum team is equally responsible and committed to delivering the work, which means that sometimes they must do certain tasks that are outside of their typical skill set for the team to meet its goal.

From an organizational design perspective, having a QA team or QA Community of Practice can still be necessary from an HR perspective (i.e. reporting to a QA manager) and to share/grow QA practices across the organization. But the notion of separate teams within the Scrum team perpetuates the unproductive notion that the work is complete once I have finished my part of it, even if the story truly is not “done”.

Reflections:

Within a Scrum team, there is no “Dev Team” or “QA team”. There is only “the team”.
Leaders in organizations that are transitioning to agile should work to remove the division of responsibilities between traditional roles and promote the notion of one role on a team – “team member”.

What’s the What?

April 10, 2017 Alec Hardy Communication, Developer, Requirements, User Stories

I recently parted ways with my Scrum teams in order to pursue an opportunity another company. One of the team members asked for general feedback about how the team had been doing. Here is my response:

Team,

I have always been open with you about things we are doing well and areas where we need to improve as a team, so instead of specific criticisms or suggestions, let me leave you with a few words of wisdom:

Always ask yourself, “what’s the what?”

Always ask yourself, “why?”

As a technical person, it’s easy to jump to the solution before really understanding the problem. Instead, always strive to understand what user or customer wants and why they want it before deciding how to solve the problem. How is this put into practice? An easy way is via user stories that reflect what the user is trying to accomplish rather than a technical solution. It could be a business task the user is trying to accomplish or a business goal that they are trying to achieve.

The beauty of agile is that you, as technical people, are not only empowered to ask these questions but are expected to. If anyone ever tries to tell you that you should not be concerned about the “what” or the “why”, do not accept that answer. Your users and customers will be much better off when you understand their needs.

Cheers!

Alec

The Product Owner Trap

April 6, 2017April 6, 2017 Alec Hardy Product Owner

My first job as a Product Owner was at a company and industry that were new to me. I enthusiastically embarked upon learning the business, the (very large and complex) products, and getting to know the team and customers. After a few months, things seemed to be going pretty smoothly and my boss asked me to take responsibility as Product Owner on a second team. Challenge accepted! I took it as a sign that I was doing a good job and ready for more responsibility. Now I had two large (7 +/- 2 people) Scrum teams both dealing with unrelated parts of a complex product and implementing unrelated, complex customer needs. Was I learning as deeply about the product and the customers as when I only had one team? Maybe not, but I still felt that I was growing and delivering value.

The mistake that I made was in accepting a third large team, also with a complex problem to solve, unrelated to the work the first two teams were doing. While it was fun to operate at such a fast pace, I started missing daily standups and retrospectives. Sometimes I had to focus on one customer for a few days at the expense of my other teams. In short, I stopped being a good Product Owner. Worse, I relied more on others around me for quick answers to questions about how the (existing, complex) product that we were enhancing worked rather than discovering that for myself thus stunting my learning process. The teams felt as though they were not getting what they needed from their Product Owner.

Eventually I went back to being PO for just two teams. What did I learn about a Product Owner’s maximum capacity? It’s not as simple as saying that it is a maximum of two or three teams. It may only be one team. It might be three teams. It depends on:

The Product Owner’s level of domain expertise and level of existing product knowledge.
The complexity of the customer’s needs or goals. Complex problems take time and collaboration to figure out.
Whether the different teams are working in the same domain (or in the case of a very large problem domain, are they working on the same aspect/area of the same domain).
Team sizes. Bigger teams usually mean more is completed in each sprint which means more work for the PO before and during sprints.
The Product Owner’s level of expertise at being a Product Owner. If the ceremonies and nuances of working with a team and the customer are still somewhat unfamiliar to the PO, it will take them more time do fulfill basic PO responsibilities.

Reflections:

There is no simple rule for determining how many teams a Product Owner can serve at the same time. Look at all of the factors above when deciding how much is too much.

Retrospectives – Back to Basics

August 3, 2016October 27, 2017 Alec Hardy Communication, Leadership, Uncategorized

For a new Scrum Master, the mechanics of getting started with retrospectives are deceptively easy. Somebody tells them to write three columns on the whiteboard (What Went Well, What Did Not, Ideas) and to facilitate the discussion. The Scrum Master makes sure that management is not invited to the meeting. He/she Identifies the team members who are not participating and try to get them talking. Simple. The retrospective becomes a blend of problems mixed with solutions and “action items” for the next sprint. If the team is lucky, it identifies the most valuable areas for improvement. Unfortunately for many teams, they go through the motions but do not get to the heart of their biggest problems/opportunities. It becomes a stale ritual and the team plateaus.

Surprisingly, many Scrum Masters fall short on the basics of how to conduct a retrospective. They think that all it takes is writing the three columns on the board. Properly done, it actually starts as soon as sprint planning is done.

In their book “Agile Retrospectives – Making Good Teams Great”, Esther Derby and Diana Larsen suggest the following structure for a retrospective:

Set the stage – get the team in the right mindset for a retrospective
Gather data – identify the key things that happened during the sprint
Generate insights – about those things and why they happened
Decide what to do – new practices to improve
Close the retrospective – take a minute to step back and reflect on the sprint, the team’s accomplishments, and the retrospective itself

Lots of different techniques exist for each of the stages of a retrospective. The art is in the Scrum Master recognizing which one fits the team at that particular moment in time.

To set the stage for the retrospective, the Scrum Master may remind the team that the retrospective is a safe environment. They could also do a check in where they go around the room and ask each person “How are you doing today?” to engage the team. Another technique is to ask people “if the team were a car, what kind/make/model of car were we in this sprint?” and record each person’s answer on the board. This can provide an interesting reference point to revisit if someone says the team was a Pinto but during the remainder of the retrospective does not point out any problems that occurred during the sprint.

In gathering data about the sprint, the Scrum Master and team consider:

The sprint goal
The sprint backlog and the results (done, not finished, etc) for each story.
Impediments or challenges that occurred during the sprint. Laying them out on a calendar can help illustrate how they affected the sprint and generate conversation for how to handle them in the future (the Scrum Master may get in the habit of noting these as they happen).
Is the team going through a storming phase? Asking team members to track how they were feeling about the sprint during specific stages of the sprint can help surface opportunities for working agreements, practices the team should adopt, etc.
After trying to remember what happened over the last week or two (they know better than to do three or four week-long sprints) the team and Scrum Master may start to note some events as they happen to make data gathering easier in the retrospective.

To generate insights, the team can approach the discussion a number of different ways:

Was every story closed? If not, what state was each one in at the end of the sprint? Ask why. Then ask why again.
Did the team stretch yet still meet the sprint goal? Reflecting on what the team did well could reinforce those practices and also set the stage for a discussion about how to take it to the next level.
Is there a lot of discussion about whether the team should adopt certain practices? The insights could be focused on things the team to start doing, stop doing, and continue doing.

Teams are usually pretty good at coming up with ideas for how to do things differently. Trying to do all of them at once or forgetting about them in the throes of the next sprint are common pitfalls. A good Scrum Master will gather these ideas as the team identifies them during the retrospective. A great Scrum Master will sense when the team has not really gotten to the heart of an issue or opportunity and prod them to drill down to the heart of the matter.

Once the team has identified ideas or new practices to try in the next sprint, posting them near the Scrum board is an easy way to quickly remind the team about them when the team is gathered around the board during the daily standup. The remaining ideas go into the Insight Backlog. This backlog can be evaluated along with new ideas that come out of each retrospective to decide which ones to try next.

Some formats for gathering data and generating insights include:

(Old reliable) What Went Well, What Did Not, Improvements. Team members write ideas on sticky notes and put them in the respective columns. Dot voting for which ideas to adopt.
Reviewing results for each story, conducting 5 whys for each one.
Start Doing, Stop Doing, More Of. Again, sticky notes placed by team members can help with participation.
Sailboat. What things are the wind in the team’s sails, propelling it? What are the anchors that are slowing it down? Another variation is Motorboat, where the team identifies the anchors that are slowing down the boat (team) and they can even place them a different ‘depths’ to indicate their severity.

Reflections

There are many ways to conduct a retrospective. The Scrum Master’s job is to find the right way to help the team improve at that particular moment in time.
Overcomplicating the format of the retrospective can get in the way of improvement.
Letting the format of the retrospective get stale can result in team members who have shut down from boredom before they even enter the room.
The Product Owner should be there. They are a member of the team after all.
In closing the retrospective, take time for Appreciations. Good people aren’t just working for a paycheck.

Shadow Backlog

April 1, 2016April 1, 2016 Alec Hardy Backlog, Requirements, Scrum Master, User Acceptance Test Cases, User Stories Agile, Backlog, Communication

ShadowBacklog

The team was under pressure to deliver a rewrite of the flagship product after having been handed an agressive delivery date. In spite of the Scrum board and other information radiators in their area, the Scrum Master had to deliver progress reports to the CEO every day. The company president and vice presidents attended sprint reviews and grilled the team whenever a story was not closed or sprint goal not met.

One could easily argue that a fixed scope and fixed delivery date is in no way agile – end of discussion – but this still happens in organizations that use (at least partially) agile practices leaving Scrum Masters to navigate choppy waters.

Of course the team developed some coping mechanisms, the most insidious of which was kicking the can down the road.

Whenever the team encountered unexpected complexity or scenarios when working on a story, they said “this wasn’t in the story that we planned, so let’s call the current story done so that our sprint metrics will look good and handle the extra stuff sometime later.” Everyone except for the Scrum Master was happy – for awhile. Team velocities looked good. Stories were being closed as planned. On the surface it looked like features were being completed. The teams were going to deliver on schedule. The Scrum Master knew deep down that they were either going to deliver late or deliver an application with enormous amounts of technical debt. She also knew that the organization could not handle to truth so she soldiered on.

Then the bubble burst. The collective “oh crap” moment happened when people realized that the system should be production-ready but was not. Some features were incomplete. Bugs were still there from parallel testing that had been performed months ago. There was no room in the time before the expected completion date to resolve all of the open issues. Market launch would be delayed.

The ‘shadow backlog’ existed in the developers’ minds and in the list of open defects that were logged elsewhere from ongoing user testing. There were no product backlog items for them and no sprints in the release plan for addressing them.

Reflections:
– Make sure that all remaining work is visible. Create backlog items for stories, technical debt, and bugs. The backlog consists of Product Backlog Items (PBIs), not just user stories.
– Get user feedback during the sprint to avoid surprises later. Ideally users are integrated into the process via acceptance test driven development (ATDD). At a minimum they have an opportunity to see stories in action and provide feedback in the sprint. Any feedback and new ideas that cannot be incorporated during the sprint should be captured as real backlog items and sized/prioritized.
– Don’t be afraid to keep a story open if it was more difficult or took longer than expected when sprint planning was originally done. Better to take a little heat now rather than have the bubble burst later.
– Avoid ‘bucket stories’ near the end of a release that become a dumping ground for stuff that did not get completed in the sprints. Bucket stories can quickly grow exponentially and delay the release.

Product Ownership – How Can I Best Serve the Team Today?

August 18, 2015 Alec Hardy Uncategorized

As a Product Owner, I start each day by asking myself, “How can I best serve the team today?” The PO and Scrum Master’s roles as servant leaders is not news. The challenge for the PO is translating this mindset into actions. It is all about mastering the cadence of product ownership.

Assuming that a backlog is in place and the team is working on the user stories, the Product Owner’s typical activities are something like:

Attend daily standups. Every day.
Help the Scrum Master resolve certain blocking issues for the current sprint.
Meet with team members to answer questions about stories in the current sprint.
Prepare for the next backlog grooming meeting. Revisit backlog prioritization, identify which stories will be groomed, add Acceptance Tests/Criteria or other information to the stories. Consult with end users or business stakeholders where appropriate.
Facilitate backlog grooming meetings with the team.
Receive demos of or perform testing for stories as they are completed as part of the sprint. This is typically part of the team’s Definition of Done.
Meet with clients/stakeholders/users to discuss and define future product plans.
Participate in the team retrospective.
Facilitate the sprint demo.
Prepare for the next sprint planning meeting by revisiting backlog priorities and assessing progress against the Release Plan.
Attend sprint planning.

This is a long list of responsibilities. Note the choice of words. They are not just tasks or meetings – they are key responsibilities that must be fulfilled in order for the team to function properly.

Organizational skills are key here. As a product owner, I use a couple of different things to manage the volume and complexity of this role:

A calendar for scheduling meetings and recurring events. Of course this includes daily meetings, weekly backlog grooming meetings and other ceremonies. I also schedule time to sit down by myself to prep for the next grooming meeting or to prep for the next sprint planning meeting. In doing so I am much more likely to actually do these rather than to forget about them or push them aside when a lot of other things pop up.
A personal Kanban board (I use Trello) to keep up with requests that are made of me. This could include questions from stakeholders/users/clients, information requests from developers, research items, or any other tasks that I need to take care of. I find that a Kanban board helps with prioritization. It also helps with tracking items that are in progress, such as when I need to request information from users to make a priority or feature decision for the developers. Some of these activities cannot be done in one setting so tracking them on the Kanban board helps prevent them from falling through the cracks. Limiting personal work in progress can help avoid task saturation and the mistakes that ensue.

Reflections

The Product Owner must understand and develop a cadence for fulfilling their responsibilities. Operating in a haphazard manner hurts them and the team.
Managing personal work in progress helps reduce mistakes and the number of things that fall through the cracks.
No personal organization system is perfect, so I also make it very clear to the Scrum Master and the team to call me out whenever I have fallen short on fulfilling my responsibilities. I am there to serve them, after all.

Backlog Grooming: Scrum’s Red Headed Stepchild

April 19, 2015April 19, 2015 Alec Hardy Communication, Grooming, Product Owner, User Stories Acceptance Criteria, Communication, Grooming, Product Owner

Backlog grooming differentiates good scrum teams from ones that are just scraping by. Viewed by some people as optional, there is often a temptation to skip it in favor of remaining focused on the current sprint. Experienced teams understand that backlog grooming can have an impact not just on the next sprint planning meeting but on the extent to what they build meets user needs.

What is backlog grooming?
The team reviews stories or epics in the backlog to be done in future sprints. The Product Owner (PO) explains the stories, the team asks questions, and additional story information may be captured as a result of the conversation. The PO may leave the meeting needing to gather additional information from users or customers about the story. The team may identify research spikes needed to understand the technical approach for the story. Typically the focus is on stories for the next sprint, but if those are well enough understood the focus may be on stories or epics further down in the backlog. The team may also adjust the sizing of stories based on what they learn during grooming. Large stories may be split into smaller ones, especially if they are going to be in the next sprint.

Note that backlog grooming can also be called “backlog refactoring”. My personal preference is to avoid the term “refactoring” because in some organizations new to agile, “refactoring” is still a dirty word associated with something that needs to be reworked because it was not done correctly the first time.

Why is it important to do on a regular basis?
I once worked with a Scrum team that literally took an entire week to finish a sprint plan. The team did zero backlog grooming. The sprint planning meetings were a combination of the PO identifying new user stories, the team members asking questions, delays while the PO sought answers, and delays while the team researched the feasibility of certain options. The end result was stories and sprint plans full of vagaries and risk. Contrast this with a team that does backlog grooming on a regular basis. Questions surface during the discussion and those questions are either answered immediately or the PO and team have time to research the answers. By the time sprint planning rolls around, most of sprint planning is about HOW the team will build it and not WHAT they are supposed to build. The PO and team can create a sprint plan to which they can commit.

How often should backlog grooming by done?
Backlog grooming should be a weekly meeting. Each meeting should be at least one hour long. A rule of thumb is never to do backlog grooming on the first or last day of a sprint. One the first day of the sprint the team is eager to get rolling the new sprint’s stories; on the last day of the sprint they may be focused on finishing off the last few sprint items. The last thing we want is for grooming to be perceived as getting in the way of the team’s success. Also, a few days may be needed after grooming to get answers to questions.

For a team that runs two week sprints starting on a Monday and ending on Friday, every Wednesday would be a perfect day for backlog grooming.

Who attends backlog grooming meetings?
The Product Owner, the Scrum Master, everyone on the team, and business representatives as needed. It is key for all of the scrum team members to attend so that they all have a good understanding and commitment to each story. Because a story is partly what is written down and partly a conversation, team members cannot expect to skip grooming and then catch up by reading the stories.

What is the PO’s role in backlog grooming?
The Product Owner’s role in backlog grooming starts before the actual meeting. The PO ensures the story prioritizations in the backlog are correct so that they know what stories will be groomed. They add acceptance criteria or user acceptance test cases to stories as appropriate, depending on how soon each story will be pulled into a sprint. While these are basic PO responsibilities, they are sometimes overlooked or ignored because of customer meetings, management presentations, etc. Regularly-scheduled grooming meetings are a great way for the PO to establish a personal cadence of prepping stories for backlog grooming.

A few days before backlog grooming, the PO tells the team which stories will be covered in the upcoming grooming meeting. This gives team members a chance to take a look at the stories ahead of time and either start thinking about the stories and possibly come prepared with questions.

The PO typically runs the grooming meeting.

What is the Scrum Master’s role in backlog grooming?
The Scrum Master can help out the PO by scheduling the meeting and taking care of meeting logistics. More importantly, the SM can ensures that the PO is on top of the backlog prioritization and knows what will be groomed. As a Scrum Master, I worked with a PO who was chronically ill-prepared for backlog grooming meetings. I addressed this via pre-meetings with her a few days before backlog grooming to help her get into the habit of prepping the backlog for grooming.

What is the team’s job in backlog grooming?
If possible, team members take a look at the stories to be groomed before the actual meeting. In the meeting, they seek to understand the requirements by discussing and asking questions. The PO may provide 50% of the story content before the grooming session. Good discussions will round out the acceptance criteria as the team and PO look at the story from different perspectives.