Category Archives: coaching

GROW Your Retrospectives

Question:

I have been assigned as the PO to a non-development scrum team for product marketing. After one week of work, we have delivered only 2 banner ads from a team of 10 people. The problem seems to be the process of approvals, reviews, kickoffs, briefs, tickets etc that need to happen in order to deliver the work. How would you coach me to help everyone see that our current process could be improved?

Answer:

Chris Sims with a plant.My first recommendation is to address this in the team’s retrospective. As product owner, it’s appropriate for you to say you would like to see the team get more ads, or other product backlog items, done in a sprint. Be a bit careful though; it’s very easy for the team to hear that as you blaming them or thinking that they’re not working hard. From the tone of your question, I don’t think that’s where you are coming from, but still be aware they may interpret things that way.

In the retrospective, you might consider using the GROW model that I’ve been writing about recently. GROW is designed for coaching, but it’s also great for structuring a retrospective. It stands for: Goal, Reality, Options (and Obstacles), and Way Forward. It’s an arc that you, or the scrum master, might guide the team through.
Read the full article…

Share it!

Coaching Questions With GROW

Chris Sims with a plant.My previous article covered the GROW coaching model. This article builds on that by adding coaching questions. Questions are a powerful tool a coach uses to help the client find their own way forward. While the coach can provide information and guidance, a key element of coaching is supporting the client in solving their own problem.

Some questions help the client see things in a new way, or consider things they hadn’t before. Much of coaching is deep listening. Questions are the invitations we give to our clients, asking them to share with us. They also allow the coach to gently guide the client’s examination of the situation, and ultimately move them into problem solving and action planning.
Read the full article…

Share it!

GROW Coaching Model

Agile coaches often encounter clients that are stuck. They know what they are doing isn’t working, yet they can’t find their way out of the dysfunctional cycle. At least, not alone. The coach’s job is to help their client:

  • gain deeper understanding of their situation
  • create a vision for a better future
  • identify obstacles & options
  • create an action plan

 
Chris Sims with a plant. GROW is a framework that a coach uses to guide their client through this process. The client might be an individual, team, or even a whole organization. GROW is an acronym for the stages of the coaching process: goal, reality, obstacles (and options), and the way forward (will do). Let’s walk through the stages of the model, in the context of Scrum.

Read the full article…

Share it!

Online Office Hours With Chris, And More!

Chris Sims Office HoursThe COVID-19 situation has brought many changes and challenges. Every change creates new possibilities for something good. For Agile Learning Labs, it gives us the opportunity to connect with our community in new ways.

Online Meetups

We are moving our MeetUp group online. The Scrum Professionals MeetUp group is going to resume our regular schedule starting this month. Tune in every third Wednesday of the month for a talk or workshop, as well as facilitated open discussion. We will continue having time for job seekers and companies to connect.

Online Office Hours

Every Monday afternoon, you are invited to join me for my open office hour: 3:00 PM – 4:00 PM PDT. This is your chance to ask me anything, and get free advice and coaching. I’m planning to use a Lean Coffee approach to structure each office hour, so the most important and popular topics get the most attention. Each office hour will be listed as a free event in the Scrum Professionals MeetUp group.
Read the full article…

Share it!

From Component Teams To Feature Teams

Components I recently facilitated a software development group’s transition from component scrum teams to feature scrum teams. The new structure reduces cross-team dependencies, which had been causing significant delays in shipping new features. Over the course of a day, we dissolved the existing component teams, groomed a shared product backlog, created a shared definition of done, self-organized into new teams, and held LeSS-style sprint planning meetings. The excellent work everyone did left me in awe, and I felt honored to have the opportunity to facilitate the day. The participants left energized and excited for their new adventure.

What follows is a description of how we structured a one-day event to transition the participants from being members of component teams to being members of feature teams.
Read the full article…

Share it!

My Clients Aren’t Dying To Adopt Scrum

atul-beingmortal-cover3d1-319x479I recently read the book Being Mortal by Dr. Atul Gawande about empowering people to make end of life decisions. Now you might be wondering, what does that have to do with scrum? Well it turns out the same questions we might ask a dying person to help facilitate their end of life in an empowering way are the same ones we might ask a client to empower their scrum practice or agile transformation.
Read the full article…

Share it!

A Scrum Master Is A Teacher, Mentor, Coach, And Facilitator

A scrum master wears many hats including teacher, mentor, coach, and facilitator. Each is a different stance the scrum master might take when interacting with the scrum team, or others in the organization. Part of the art of being an excellent scrum master is being able to select an appropriate stance for a given situation. We also need to be able to flow between them, inspecting and adapting based on the situation and the needs of the people involved.

Teacher

This is the act of showing or explaining something to someone so that they acquire new knowledge. The scrum master is an expert in scrum and related agile practices. The scrum master spreads this knowledge throughout the organization, enabling people to engage in their work more effectively.
Read the full article…

Share it!

5 Reasons Scrum Helps Teams Become High-Performing Faster

Scrum Masters and Product Owners know how hard it is to get their team to become high-performing. They can rest assured that they’re on the right track. Scrum helps teams become high-performing faster than other work methods. The reason is simple. Becoming high-performing is baked into the Scrum recipe. In my experience coaching agile teams, I have observed over and over that teams that use Scrum go from forming, storming, norming and ultimately to high-performing more quickly and reliably than teams that don’t. Here are five reasons why:

1. Scrum roles – Each role plays a part in helping teams perform better

The Scrum Master is an embedded agile coach. The Scrum Master plays a direct role in easing teams through the forming and storming stage. They take a coaching stance and share behaviors that they observe are challenging the team’s ability to work together.

The Product Owner maximizes the value of the product and the Development Team. They point the direction for the team, which eases the team’s shift into norming.

The Development Team Members organize and manage themselves. They have the freedom to shape their own environment. This empowerment facilitates the move toward high-performance. And the supporting roles of Scrum Master and Product Owner are there to serve the Development Team to make the shift successful and sustainable.

2. Scrum events (Sprint Planning, Daily Scrum, Sprint Review, Retrospective)

Each Scrum event is meant for a specific purpose. They provide a minimal level of structure upon which the team can build. This is why Scrum is often referred to as a process framework. Here are some examples of how the Scrum meetings help teams accelerate to high-performance:

Sprint Planning: Team members avoid analysis paralysis. They don’t spend months analyzing requirements and designing solutions before producing something. They quickly put together something useful upon which they can iterate.

Daily Scrum: This is a short meeting meant to make it easier for a team to actively manage itself and coordinate its work. Each team member demonstrates their progress, which helps others learn to trust that everyone is pulling their own weight. It’s more difficult to ride on other people’s coattails when you have to stand before your colleagues each day and talk about what you’re doing.

Sprint Review: The team members share equally in the success or failure of the team. No one on the team wins unless they all cross the finish line. This reinforces the individual member’s commitment to the team, which facilitates the norming process. And once they become cognizant of this new reality, they unlock the door to high-performance.

Retrospectives: From the beginning, the team carves out time to inspect and adapt. This means they take a practical and thoughtful look at what went well and what didn’t. They search for ways to improve in the very next sprint. Talking about challenges, both task-wise and interpersonal, pushes the team to storm quickly, and with the aid of the Scrum Master, to ease into norming.

3. Scrum artifacts (Product Backlog, Sprint Backlog, an Increment of Something that is “Done”) – each artifact serves as a focal point around which the team can organize itself

Product Backlog: The Product Owner is empowered by the customers to order the Product Backlog by value, risk, priority, necessity, or other factors. This eases the pressure on the team to figure out what they have to do next. At the same time, the Product Owner and team collaborate on the details of the items in the backlog.

Sprint Backlog: The team collaborates to make a short-term work plan to deliver items from the Product Backlog. By planning and acting together, the team learns what it takes to produce valuable results and makes delivering those results the measure of progress.

Increment of Something that is “Done”, usually an increment of potentially shippable software: They trust their colleagues’ motivations because everyone has agreed to pitch in and deliver the next increment of potentially shippable software together.

4. Scrum Teams put the Agile Manifesto into practice:

“Individuals and interactions over processes and tools” The team members work more closely together. Cubicle farms are rare in a truly agile space. It’s also preferred to have the team members co-located instead of spread across the world. The team members speak with each other more often. Not only are conversations held face-to-face, but the act of conversing is preferred over comprehensive documentation.

“Responding to change over following a plan” When you make a big plan up front, you have less tolerance for mistakes because you can’t go back and change things without substantial disruption or cost. On the other hand, a scrum team is encouraged to make decisions as it goes along and limits its risk to the length of the sprint. If something doesn’t work, the team just fixes it in the next sprint.

5. Building high-performance through trust

The team spends very little time in the forming stage because the team members rapidly build trust through applying Scrum. From their very first sprint, they make commitments to each other and diligently practice keeping them. The team members learn each other’s talents and skills by observing them being practiced. They quickly see what others are capable of, and they gain a new level of assurance because they’ve seen their colleagues demonstrate their abilities.

Share it!

Performance Review Pain Review – The Agile Way

Performance Review Pain ReliefTake a piece of yellow paper, a slice of pizza, and a couple of guys with clipboards – and what do you have?

Last week – it was the latest gathering of the North Bay Agile Meetup group. The topic was “Performance Review Pain Relief.” So what would you do with that piece of paper – write a performance review – or make an airplane? At this Meetup – we did both.

Led by Chris Sims of Agile Learning Labs and Harold Shinsanto – we formed agile teams of expert paper airplane manufacturers. And in the course of producing some of the most embarrassing paper airplanes in aeronautical history – the group explored what works and doesn’t work with performance reviews.

In the context of “agile business” – it would be easy to decree that old-fashioned stack-ranking and personal performance reviews should go by the wayside. After all, rating the performance of individuals relative one another runs counter to the ideas of self-organization, teamwork, and continual improvement so central to agile product development.

And until the HR department hops on board the “agile train” – are we just stuck? The group decided no. As an agile team – we can

  • Make sure we clarify “the goal” – understanding the performance criteria for the team and for individuals long before any feedback session

  • Foster a culture of coaching – even when “the boss” is officially only providing annual written feedback in the traditional performance review – coaching can be something done by the team – for the team.

  • Develop systems for continual feedback and improvement – rather than only examining results when the “system” says we must – find ways to frequently improve. Inspect and adapt. Lather, rinse, repeat. Sounds a lot like what we do in agile anyways!
  • And to the Human Resources professionals who may accidentally stumble on the great world of agile, scrum and team-based work – come on over. We’d love to talk. We saved a couple of slices of pizza just for you.

    Share it!