By Chantal Jenoure

“We all need people who will give us feedback. That’s how we improve.”
– Bill Gates

At the heart of Agile is people.

Think about it - customers, cross-functional teams, stakeholders - are all part of the puzzle and one cannot be Agile without all the people components.

Agile teams are designed to work cross-functionally, where each team member’s output plays a part in fitting an entire puzzle together. Our success is codependent so one person finishing their task isn’t sufficient until everyone on the team has completed their work.

Working, proverbially, elbow to elbow with our team members, will inevitably cause friction and conflict. One way to channel this conflict constructively is to encourage our team members to give each other feedback.

Encourage them to consider the Scrum’s values of openness, commitment, courage, focus, and respect, and ask them to use this to drive the ‘spirit’ of how the feedback is given and received.

Unsplash Photo by Annie Spratt

Here are some points to consider when giving feedback

1 Ask yourself - is the recipient open to receiving feedback?

2 Speak to the recipient privately. No one wants to receive feedback in a public setting. You want the person to hear what you have to say, without being distracted by who may be listening or for them to be trying to also process how everyone may be responding to what you’re saying.

3 Focus on the behaviour and not the person. You aren’t criticizing the individual. You want the recipient to be aware of the impact of their actions or words.

4 Don’t delay giving feedback. Give feedback as soon as you can. Delaying the conversation may cause details to fade in the individual’s mind.

5 Be realistic. Focus on changeable behaviour.

“Criticism, like rain, should be gentle enough to nourish a man’s growth without destroying his roots.” – Frank A. Clark

Unsplash Photo by Christina @ wocintechchat.com

Receiving Feedback 

If you are on the receiving end of feedback, here are some points you can consider.

1 Listen carefully. Trust that the person is coming to you directly because they want to see you become the best professional and teammate you can possibly be. There is no ill-will or ill-intent.

2 Ask clarifying questions to make sure you understand and try to not be defensive, or dismissive or reluctant to hear what is being said.

3 Focus on the issue/behaviour and try not to feel like it’s a personal attack. We’ve all been there. It’s hard to hear that we may have said or done something that may have offended or hurt someone, so instead be committed to focusing on how you can express yourself differently or work differently amongst your teammate(s).

4 Thank the person for their feedback and apologize, if appropriate. No one is expecting an immediate change. No one is expecting that you may not slip up again. All that is required of you is that you bear the feedback in mind as you move forward. If you find that you’ve slipped up, do the right thing and make immediate steps to acknowledge that it wasn’t intended and that you haven’t forgotten the feedback you received.

By Chantal Jenoure

The Scrum Master plays an important role in guiding the organization towards a more transparent, inspective, adaptable way of operating. 

The Scrum Master facilitates this by wearing a number of hats, with respect to their work with the organization, including: Coach, Advisor, Teacher and an Agent of Togetherness. 

Unsplash Photo by Christina @wocintechchat.com

The Scrum Master as Coach

The Scrum Master leads, trains and coaches the organization in its Scrum adoption. They ensure that the organization creates an organization wherein a Scrum team can thrive. They help in creating the psychological safety that a team needs to experiment and fail without adverse recourse.

Unsplash Photo by krakenimages

They challenge the organization to make changes such as:

➤ Consulting with customers before starting any work
➤ Consulting with customers during work
➤ Consulting with customers after the work is ‘done’
➤ Working in iterations: if we focus on delivering some value in each sprint, what can we do that is potentially shippable to the customer.
➤ Understanding that we are doing “just enough” work to deliver potential value to the customer

➤ Ensuring that we have all persons on the team, who are critical to the successful delivery of our project, i.e., a fully dedicated team.

The Scrum Master as Advisor

The Scrum Master should be a trusted advisor to the business line, unit or department, as well as the IT (or implementation team). Because of the key role they play on a Scrum team, they are able to use the forecasting information, at their disposal, and negotiate and communicate (changing) delivery timelines with the relevant stakeholders.

Their knowledge of how Scrum works can help to also determine if a prospective project can be completed using the Scrum framework. [Scrum is only one of many Agile frameworks and is suitable for “generat[ing] value through adaptive solutions for complex problems” - The Scrum Guide].

Unsplash Photo by Christina @ wocintechchat.com

The Scrum Master as Teacher

The Scrum Master helps the organization to understand and adapt an “empirical approach for complex work.”

Unsplash Photo by Christina @wocintechchhat.com

Let’s take a step back.

The Scrum Guide describes the theory of Scrum as one “founded on empiricism and lean thinking.”

Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.  - The Scrum Guide

In an organization, the Scrum Master may find that they are always championing this cause. They will help to break the harmful cycle of making random and haphazard decisions. They will challenge conversations and mandates to better understand:

➤ The vision of their stakeholder (why is this change needed)

➤ The change within the marketplace

➤ The intended outcome, benefit or perceived value to be had from their request 

They will also find, in conversations with their stakeholders, that they have to challenge requests that are “gold-plating” the solution or one that falls within the upper left quadrant of the Risk-Cost-Value-Effort Prioritization matrix below.

The Scrum Master will also help in finding solutions to complex problems. They should have a variety of tools in their toolkit to facilitate problem-solving sessions and conversations. This may include facilitating sessions for brainstorming, ideation and story-mapping, to help the team to find solutions to these complex problems. 

It is important that the Scrum Master knows how to keep the conversations:

➤ Flowing towards a solution. They will find that conversations can easily go down a rabbit hole or go completely off-course, i.e., where the discussions become centered around (important) things that have nothing to do with the problem at hand.

➤ Timeboxed so that the time is well-spent and that the sessions concludes with: 

i. Great ideas that will need to be further investigated and fleshed out 

ii. Action items to answer unknowns or assumptions made, to ensure that the team is on the right path to building the right thing, the right way from day one. 

The Scrum Master as an Agent of Togetherness

The Scrum Master is tasked with helping the team to work well with their stakeholders. Too many times, the Scrum team is operating independently of the business stakeholders.

Unsplash Image by John Schnnobrich

The Scrum Master has to play an instrumental role in ensuring that:

➤ The business stakeholders are kept abreast of the progress of the work being done
➤ The Scrum team are open and transparent about the challenges they are having
➤ There is collaboration with solving these challenges
➤ The business stakeholders avail themselves and their knowledge to support the team
➤ The business stakeholders trust that the team will deliver a high-quality, high-value solution, within the shortest time possible
➤ The Scrum team articulates clearly and comprehensively any changes they need to business policies or operating procedures that may:
i. Ease the delivery of their solution
ii. Relieve any pain-points that their customers may experience

iii. Simplify the solution being delivered

iv. Simplify the operational procedures that will support the completed solution

Unsplash Photo by Priscilla du Preez

The Scrum Master may have to be creative in how they facilitate these conversations but they should do all they can to ensure that their team feels supported and the business feels clear and certain of what the solution is and how it will work. 

###

This is the final installment in the series that looks at the Role of the Scrum Master. If you missed the previous posts, you can check them out here:

1. The Scrum Master Role (3) - Collaborating with the Product Owner

2. The Scrum Master Role (2) - A Practical Look

3. A First Look at the Role of a Scrum Master (Part 1)

Transitioning to an agile way of working takes effort. After all, it's about changing behaviors. That’s why it’s important that we’re cognizant of the barriers, which may slow the progress of transformation.

In this episode, we talk about these 4:

1. Agile as a magic fix or saving grace

2. Lack of trust or transparency 

3. Resistance to inspecting and adapting

4. Deadlines as the primary measure of success

What other barriers have you observed? We'd love to hear about your experiences.

Who knew how rewarding and fulfilling it could be to invest time, energy and effort into your passion project?  

We are happy to say that one week ago, Agile Caribbean Link turned 3 🎉

Looking back, we didn’t know what this would become, if anyone would be interested in our experiences or if our content would be well-received. 

But we did it anyway. 

We started small. 

We started one step at a time. 

Here are some of the lessons we’ve learnt over the past 3 years. 

We hope it’ll encourage you to pursue that which makes you happiest, even if there are no immediate gains. 

The gains will come 😄

 By Chantal Jenoure

The first day your new team is assembled, they are not a team, they are a group of people who have been given a common goal. As a Scrum Master, you will want to do everything in your power to help them achieve that goal. 

One thing I've learnt is that you can't focus solely on that common goal. I realized if I wanted my team to work as a unit and become a team, I would need to be deliberate about it. 

Here are a few actions I took to intentionally build a cohesive and resilient team.

Be intentional about getting to know each other 

1 Free personality tests

These will help you to understand the individuals on your team. You will better understand how they think and approach problems; how they deal with failures and criticisms; what are their strengths and weaknesses. Find a fun activity to help your team members to share their results with each other. This will create an atmosphere where they can find similar traits as well as better understand each other's nuances. 

Tips

> Tap into this free personality test  

You may be tempted to keep the results under lock and key but the true value of this exercise comes from having a common understanding of what makes your team members tick.

16personalities.com

> Find opportunities to tap into your team member's strengths 

Is one of your team members gifted at creatively presenting or summarizing a blocker? Ask that person to help in articulating the help the team may need to keep moving forward.

Unsplash Photo by Mimi Thian

> Find opportunities to balance out their weaknesses 

Is there a difficult task that would make one of your team members get lost down a rabbit hole? Pair that person that is a quick problem solver so that they can benefit from a different approach to solving the problem.

Unsplash Photo by Charlesdelivio

2 Use simple icebreakers to get everyone talking and 'moving as a team'. 

Tips

> Try the 10 Finger Icebreaker game. 

This game is perfect for remote teams. Give persons a heads up that they will need to have their cameras on. Each player holds up their 10 fingers in the air. Starting with one person, who makes a simple statement that is true for them. If the statement is false for anyone else, they put down 1 of their fingers. Last person with a finger wins. For example, I love going deep sea diving. 

©agilecaribbeanlink

>This or that

Have a quick conversation about the preferences of your team members. This is another way you create an opportunity to understand the likes and dislikes of your team members. 

Source: https://www.ricotta.team/blog/this-or-that-questions

 

Source: http://smallthingsinlife.net/fun-instagram-story-templates/

3 User Manual to Me 

This user manual allows your team members to capture their likes and dislikes when working on a team. As the Scrum Master, you can select questions so that you can have a baseline of how to approach various team activities for the team. 

Unsplash Photo by Austin Distin

Tips

Below is a sample. This information can be captured as shown in the image or by using a table in Word. You would share the template with each team member, giving them sufficient time to complete it and advise them when they would share the document with the other members. 

You can also add this activity to your onboarding toolkit for when new members join the team! 

By Nicola Brown

Metrics can easily get a bad rap.

And I understand why. Sometimes, in our bid to prove we’re adding value, we hastily start measuring things - anything - without any real thought on how they can help.

Unsplash Photo by Christina @ wocintechchat.com

For me, metrics are not about having something to report on. It’s about getting a better understanding of how we’re working. They should help inform some of the deeper conversations that we need to have, as we embed continuous improvement as part of the culture.

I must add too, that like everything else, the metrics that a team uses will evolve over time. It’s important to look at where we are, identifying what’s the next best step to take and in figuring that out, selecting the correct metric that can help us unearth the opportunities.

For software development teams, especially newly formed teams, I will share a few metrics that I recommend starting with.

This blog post will focus on the first one - VELOCITY. 

1 Velocity

Full disclaimer! 

There has been a lot of talk about how negative it can be to use velocity as a performance metric. I completely get it. It’s one of those metrics that can be easily misused. So let’s lay out some context before we start diving into why look at velocity.

“Working software over comprehensive documentation”

As an Agile team, the aim is to deliver incremental value, early and often. That means, we need to be getting work done and into the hands of our customers. 

This is where velocity is useful - in helping to forecast or estimate how much work can be reasonably done, based on past performance.

But as useful as it can be, it can be as easily misused. Here are just a few of the ways:

✖ As a comparative tool across teams.

Teams differ. No two teams will work the same, just like no 2 humans will do anything in the exact same way. 

Even if both teams are considering the same factors when looking at a story, there are nuances and differences in how they may approach the work. 

Therefore, we should never, ever, under absolutely no circumstance, compare the velocity across teams.

Unsplash Photo by Markus Spiske

✖ As an absolute forecasting tool

Velocity will fluctuate sprint over sprint. That’s a reality. 

When working in an Agile manner, we start with what we know and as we proceed, we uncover and learn new things. Sometimes new work emerges. And that also means, sometimes the initial plan has to be adjusted and adapted, based on that new information, to allow for discovery or investigations, which may result in a new plan or approach being required. 

To expect a team’s velocity to be fixed and remain unchanged, may not be the most reasonable (or practical) expectation. So while the velocity can help us to forecast, based on the information at present, a team should never be penalized or chided if those forecasts change. They are best guesses, not an exact science.

How can velocity be helpful?

➤ As a reference tool in any planning exercise

It can help keep the team grounded - or better yet - keep their plans realistic. 

Sometimes our teams are overly optimistic about what can be accomplished in a given period. By looking at what we were able to accomplish in past periods, we can eyeball if we seem to be taking on less or more work. 

In either case, a conversation can be prompted by asking questions such as: what is different about the work that we are doing now?

Unsplash Photo by airfocus

➤ To prompt a deeper look into why work was not completed

Velocity charts also indicate the amount of work not done. 

Depending on the type of tool being used, we may also be able to drill down to see exactly which piece of work was not completed. Having this information makes it easier to dissect, as a team, the factors that impacted us completing that piece.

Where there were factors external to the team, there is an opportunity for the Scrum Master to bring the issue to the attention of the responsible stakeholders. 

Where the factors were internal to the team and within our control, the conversation shifts to questions like - what can we do to prevent a recurrence? What do we need to do differently next time?

In the next post in this series, we'll examine 'CYCLE TIME'. 

By Chantal Jenoure

A Scrum Master’s closest partner should be their Product Owner.


Why?


According to the Scrum Guide 2020:

“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”

How is the Scrum Master role different from that of the Product Owner?

To distinguish between the roles of the Scrum Master and the Product Owner, I’ll say this simple statement - “Whilst the Product Owner is responsible for determining WHAT is built, the Scrum Master guides HOW the solution is built.”

Unsplash Photo by Christina @ wocintechchat.com

In the grand scheme of things, why is this such a big deal?

Well, in many organizations that are ‘exploring’ Agile, there is nothing of more importance (and most times, under more scrutiny) than the output (and hopefully, this means, value delivered) of their Agile teams. 

This is why it is important that the Scrum Master guides and aids the Product Owner to focus on the most important increment and that the increment is implemented as quickly as possible to deliver the intended value as early as possible.

How the Scrum Master supports the Role of the Product Owner

The Scrum Guide (2020) also outlines that the Product Owner captures the work to solve a complex problem into a Product Backlog. 

This role is accountable for managing the Product Backlog effectively. 

© AGILE CARIBBEAN LINK

One Product Owner per team

Additionally, the Scrum Guide stresses that the Product Owner is one person. The role cannot be filled by a number of persons or a committee. In the same breath, the decisions of this individual should be respected by the organization.

Unsplash Photo by Parabol

The Scrum Master champions this, by ensuring that:

1 The voice of this individual is respected and their decisions are honoured, by garnering the support of key stakeholders as well as reiterating the team’s focus, the Product Goal and what each increment will include. 

2 No one goes around the PO to have sidebar discussions with the developers to change the priority or focus on what they would have agreed with the PO to deliver.

3 Changes to the product backlog are done through conversations with the Product Owner and not through the issuance of mandates or imperatives. This is crucial to the success of a Product Owner, seeing that they are accountable for what is built. Furthermore, the Product Owner should always have a full understanding of what, how and why the requests and needs of the stakeholders have changed to ensure that the team is focusing on the highest priority at all times.

Next up, we'll look into the Scrum Master's role to their organisation. 

In case this the first in the series that you are reading, check out Parts 1 (A first look) and 2 (A Practical Look) here! 

By Nicola L. Brown

Why choose iterative delivery?

Perhaps the more important question is why would anybody want to deliver a solution this way?

Why not simply build everything that we think our users want; create the perfect solution and deliver that at one point in time?

Wouldn’t that be easier? Doesn't that make natural sense?

Well, one of my first thoughts, when trying to rationalise this, is that more often than not, any problem that we are trying to solve, somebody else has taken a shot at solving it.

The likelihood that there is already a solution to an opportunity that we have identified, is very high, especially in this age. 

Unsplash Photo by Mars Sector-6

So, where does that leave us? Does it mean, we shouldn’t even attempt to solve that problem, create that experience, explore that opportunity?

Absolutely not!

Rather, it means that from day 1, we have to ensure that whomever’s lives we think we’re going to improve with our solution, they are active participants in the process.

It doesn’t mean that they are hands-on in building the solution, but for anything that is being contemplated, they must have a say.

A good way of looking at it is to accept that until an idea has been validated by our potential user, it is a mere assumption. 

I guess in a round-a-bout way, this takes me back to my original set of questions, I’ll start with the ‘why’.

via GIPHY

Why is iterative delivery a key Agile component?

1 Delivering an iteration allows us to know sooner, if the product or solution that has now come to life, is in line with the validated idea.

🠊 Did we build what our user expected?

🠊 How on point or far off are we?

2 The reality is that sometimes we, as users, need a nudge to understand if what we thought we wanted, was actually really what we wanted. I’m sure we’ve heard the quote by Henry Ford, "If I had asked people what they wanted, they would have said faster horses." 

3 It allows us to get feedback on how our product or solution can evolve (or if it even needs to evolve) or should be taken back to the drawing board. 

And while we may understand the reason behind delivering like this, sometimes it gets a little fuzzy in trying to figure out how to get it done. 

Let’s try to break this down as simply as possible.

Five Key Steps to Delivering Iteratively

1. 🔍 Be clear on the problem

First, we must be clear on whose problem we’re trying to solve. No matter how great we think our solution is, it cannot solve everyone’s problem.

People are dynamic; even in how we use solutions are different. I’m almost sure you can easily think of a friend who has the same model phone as you and may use it completely different from how you do. That’s just the reality. 

Unsplash Photo by bruce mars

1. 💡 Identify our customers

So let’s start by thinking about our customer segments. And when we’ve identified the segments, we’ll narrow it down some more.

Some things we’ll want to think about is:

• Which segment is smallest or largest?
• Which segments provide an opportunity to solve a simple problem which may have a huge impact?

We’ll shy away from the segment which may seem to have the most complex problems with the least amount of persons in that category. 

1. ⮝ Prioritize what we’ll deliver

This is where we can also start looking at our value matrix. It’ll help us identify our quick wins and those are what we want to go after. The bonus to delivering something quickly to our users, it boosts team morale. There’s a certain euphoria and pride when a team sees something they’ve worked on, being used, and is working as intended. 

© Agile Caribbean Link

1. 💣 Deliver the simplest thing

After we’ve identified our target, we want to deliver the simplest thing that will start making a difference in our user’s life. This requires deliberate effort and focus because it’s easy for us to get caught up with working towards perfection.

I may be going off here, but I think this is one of the biggest opportunities for us in the Caribbean. We’re quick to delay releases if we don’t get a process automated or digitized end-to-end and to do this takes time and effort. The more we delay, the higher the waste, as we’re not delivering value to anyone. 

The most important rule in our development is always to do the simplest thing that could possibly work. Not the most stupid thing, not something that clearly can’t work. But simplicity is the most important contributor to the ability to make rapid progress.

- Ron Jeffries, Do the simplest thing that could possibly work

Photo by UX Indonesia on Unsplash

This was one of the first lessons I learnt from my Programme Manager. He was keen on us understanding that especially when we’re changing a process, it’s important to readily identify at each step, how much of the process we would automate. And it wasn’t willy nilly either.

It was starting with the end user in mind; improving the part of the process that they needed to interact with, so that from the first release, they would feel the difference. If it meant that within the office, this seemingly digital flow, required us to still have some manual actions, that was fine. The next iteration could start looking at that. But the intent was always, how are we improving our customer’s experiences. As John-Matthew Sinclair states in Welcome to the Experience Economy, "businesses have to do more for their customers."

We know that we’re operating businesses and so this may not feel like the ideal, but if we’re serious about changing the ways of working, we have to have these, perhaps,  uncomfortable conversations. What is required is transparency and openness about how we plan to deliver. 

1. 💬 Proactively seek feedback

So what happens after we deliver?

Do we pack up shop and move on to the next thing? Nope!

We have to ask our customers for feedback on what we’ve delivered. That can take several forms. The simplest way is to just ask. This could be in the form of sending out a survey…think something like Net Promoter Score (NPS).

Unsplash Photo by Christina @ wocintechchat.com

Again, we know that ideally we’d want to include collection of this kind of feedback in the solution we’ve released. But, really, is that necessary for a first release? Can we readily cite an instance that our end users indicated that they needed an NPS survey in order to use a solution? I would make an uninformed guess to say that doesn’t happen.

So, there’s absolutely nothing wrong if soliciting this feedback requires a little manual effort on our part in the first instance. If possible, a phone call goes a far way as well. It allows us to get a deeper insight into what our customers are thinking, as we’re able to ask follow-up questions if a remark was unclear. You can explore some other ideas here.

However we get the feedback, it’s important to use those insights to figure out opportunities for improvement in the solution, or a direction for what the next iteration may look like. The feedback becomes an input, a kind of starting point, to determine what’s next. 

And then the cycle starts again.

But the point is that, while we’re working to improve people’s lives, we have to figure out how to make that happen sooner. And to do that, we cannot be chasing perfection. Instead, let’s figure out how to get solutions to our users faster and more frequently.