Archive for category: Blog

At first glance, the five Scrum values seem like a no-brainer: Commitment, focus, openness, respect, and courage. But often, there isn’t one version of the truth. Without clarifying what these values mean in Scrum, the team is left to interpret what these values mean through the lens of their own experience and cultural norms. 

Commitment

In the Scrum Guide, commitment is about the team committing to achieving its goal and supporting each other. It’s important to clarify the difference between making a commitment and making a promise. While we can commit to working together to reach a defined goal, we can’t promise we’ll achieve it.

Commitment doesn’t promise an outcome. It’s about working towards an outcome. We can make a commitment to pursue our collective goal in a focused way, to being supportive of each other’s success, and working together to achieve it.

Focus
It’s no coincidence that one of the examples listed in the Merriam-Webster dictionary is, “the team lost focus.” Without focus, teams can lose their sense of direction – where they are headed at any point in time. 

Fortunately, Scrum is full of mechanisms that ensure the team stays focused.  The most important of these is the sprint timebox itself.  Teams focus on the highest priority opportunities that can fit in that fixed timeframe. Other practices can help teams focus such as  setting explicit Sprint learning goals, publishing your team’s definition of done, and adding expiration dates to product backlogs. 

You could also plan a learning focused daily Scrum where you change the emphasis of the agenda towards learning rather than task progress and delivery.

Openness
It’s easier said than done and it’s only achieved in teams that have developed trust. Without trust, people will be afraid to be truthful. They won’t be willing to admit mistakes, take responsibility, or even be honest about challenges they’re facing – because they’re afraid of the consequences. If the response to mistakes is “shaming and blaming,” people will be reluctant to admit to them or point them out.

Cultivating an environment where people can be honest and expect to receive support (instead of a rap on the knuckles), is easier in some cultures than in others. We all make mistakes. It’s what happens next that determines whether people feel they can speak freely or it’s safer to stay silent. It’s important to create a culture that embraces small failures in order to avoid the large ones.  Creating an environment in which it is safe to fail not only leads to greater innovation and experimentation but also to one that is more open and transparent.

It starts with assuming people have good intentions. That no one deliberately sets out to make a mistake. As a leader, you make them too. The important thing is to identify and learn from these so we may become better leaders and team members.  Openness is the key to unlocking future improvement.

You may find that holding a safety check when you kick off your meetings makes meeting safety a prerequisite and allows you to assess and evaluate whether safety issues have been dealt with. Feeling safe leads to more engaged participants and better meeting outcomes.

When there’s openness in Scrums, problems are identified sooner, solutions are found through greater collaboration, and everyone knows whether they’re on target to meet their goals.

Respect

In some cultures, respect is a given. You’re expected to respect your elders, your teachers, your managers. In other cultures, respect must be earned. You aren’t given respect simply because you have a fancy nameplate, a long-winded title, and are higher up in the corporate tree.  In Scrum, respect refers to the respect we have for each other.  “I respect you, because I know you”.  Because we respect each other, we treat each other with respect.  Because we respect each other, we assume positive intent in the actions and decisions that others make.  Because I respect you, I don’t think you’re purposely trying to undermine me.  If you’re doing something I don’t agree with, it’s because you believe your path is the better one.  Because I respect you, I should have a natural curiosity to try to understand “why?”

We  earn the respect of our team members through the actions and decisions we make as ScrumMAsters. We  take  responsibility as leaders. We  earn it through empathy and caring — prioritizing the success of our team members no less than our own. 

Courage
Doing the right thing — even if it means negative ramifications — takes courage. It takes courage to say “No” to unreasonable customers.  It takes courage to resist the urge to cut corners just to get something out the door.  It takes courage to admit that we have failed; that we have made mistakes; that we missed something.

It takes courage  to admit we were wrong and we should change course. And to do so in the spirit of cooperation and getting back on track, where everyone knows what needs to happen next.

As a member of a scrum team,  it’s your role to support your team in finding solutions. It’s saying, “Let’s work together to find a solution.”

To ensure your team can move from theory to practice, it’s essential to ensure everyone is on the same page about what these values mean and how to implement them. 

How events, rituals, and ceremonies add value to meetings

Not another meeting! People generally don’t look forward to meetings. It’s one more task in a day filled with demands and deadlines. For Agile teams, meetings are an essential part of daily work life. Adding ritual to these meetings makes them meaningful. It gives them value. This phenomenon isn’t unique to Agile – it’s part of our daily lives. You only have to look around to see countless examples of how rituals transform events into something unique and meaningful.

Today and every day, in a variety of settings around the world, people carry out ceremonies and rituals — whether it’s being sworn into office, awarded a graduation certificate, or receiving a medal. Some are sheer spectacle, such as the Haka, the ceremonial Māori war dance carried out by the New Zealand team to challenge opponents before a game. Not only do they have a defined purpose, they’ve become a tradition. It’s expected. Should they be excluded, their absence would be noticed and missed.

As important as they’ve become, most ceremonies don’t actually change the outcome. It’s often a public declaration, such as choosing to take someone as your life partner. You could get married without the big party. The net result is the same. So why do we do it? Because there’s value in the ceremony itself.  The same is true of Agile ceremonies.

The reason behind the ritual

Think about your daily or weekly rituals. The coffee you make for your partner before you leave for work. The Friday night dinner or Sunday lunch. Would you miss them if you suddenly skipped them? In all likelihood, you would. In fact, if someone (or something) was unexpectedly missing, you’d probably think that something was wrong. That’s because it’s more about the coffee or the meal. It’s about the meaning you attach to it. Beyond the social aspect, it creates connections. These rituals and ceremonies are intended to define who we are and how we do things.

The same is true of the Daily Scrum. You don’t just go to the Daily Scrum because it’s a meeting that you hold every day at 09:00. You go because you’re going to learn things. You go to the Daily Scrum because done right, it defines your team and who you are, such as a badge or a uniform. These rituals and how you do them are part of the uniform. They’re the badge of who you are and how you do things. When it comes to your team having these rituals, it’s how you do things on your team. They help to establish and define who you are as a team, as a unit, and as a company.

Having that ritual is more than just how you do a daily scrum. It’s defining how you do that ceremony. That ritual, that event, becomes a uniform, a badge of who you are. That’s what those ceremonies do. There’s room for that on a team because as a team, you need to define who you are. Why are you different? How are you differentiated? It’s about team “branding,” accountability, and bonding. It’s about bringing people together and creating a cohesive identity that belongs to you as opposed to them.

However, while ceremonies are important because they help to define who you are, they should not get in the way of the things you’re trying to accomplish. You (and me) need to get things done.

Can a standup be a sit down?

Sometimes you’ll hear the daily scrum referred to as the daily stand up. Often, people mistake that for being a literal stand up – as in, you have to stand up. This is a misunderstanding of its intention. Some people think it’s discriminatory, since not everyone is able to stand, particularly if they are confined to a wheelchair or have a temporary or permanent disability.

What people lose sight of is that maybe it’s not a literal standup but a metaphorical stand up, because it’s different from other meetings. If this is a meeting that metaphorically can be carried out standing up, it means that it’s portable. You can do it anywhere. It doesn’t have to have the trappings of a specific place or meeting room. You could do it in the hallway, cafeteria, outside or while going for a walk. It’s a stand up. It’s saying that this meeting is unlike any other.

It’s not usually about making sure people don’t settle in and get comfortable. Realistically, many office chairs aren’t built for comfort anyway!

Here’s a fun idea I’ve shared with people who believe it’s about speed, not comfort: If you really like the idea of standing up so your team doesn’t get too comfortable and you think your team is equipped to handle it, why not attempt the daily planks? Do the daily scrum in plank position, where everyone in your team has to maintain a plank. It’s one really effective way to guarantee that the meeting will be short and snappy! Seriously though, the idea is to make it stand out – and that doesn’t necessarily mean you need to stand up.

It’s not all fun and games

Beyond fun rituals that make your team laugh, relieve tension, and break the ice, there’s also the opportunity for rituals that check in on your team’s wellbeing, such as measuring happiness. You can rate your team’s level of happiness daily, or at retrospectives. The method can still be fun, but it’s motivation is deeper: whether your team is feeling happy or cr*ppy is going to impact their productivity. It also shows that you’re not just interested in the work they’ve delivered, you care about whether they’re happy with their tasks, the projects, and the team they’re in. This becomes even more critical in hybrid and remote teams.

When the location is your screen

Creating opportunities for these rituals has become more challenging when you’re working remotely, but it’s not impossible. To make your daily scrum different from other meetings, you may start it off with the riddle, trivia question, or puzzle of the day. Another team may start every daily scrum with the funniest themed virtual background contest where everybody shows up with their selection and spend two minutes voting on who’s the funniest before they kick off the discussion. When these rituals are left out, it becomes just another meeting.

Giving meetings meaning

Events become important when they’re different. If coronations looked like any other ceremony, would it still be as big a deal? It simply wouldn’t get the same amount of attention or be taken as seriously. That’s why you should make your key meetings, whether it’s the daily standup, scrum or sprint planning session, different from all other meetings. Every Scrum team may hold a daily scrum, but your scrum has a distinctive format that makes it stand out.

The value of the ceremony makes it more than something tribal. It creates a sense of belonging. This is your team and this is how we do it. It sets expectations. Anybody who joins your team knows they’re going to be doing it too. It creates rituals that define who you are, not just how you do things — and that’s why it’s important.

If you want to add value to your daily Agile meetings, consider transforming them into meaningful events — something your team anticipates, commits to, and fully participates in.

***

What’s your ritual and how does your team respond to it? Tell us in the comments.

***

This blog was entirely written by humans based on personal interviews and research without any AI-generated content.

As you may know, for most companies today, rapid software development is essential, given the environment of ever-changing expectations. More and more companies realize the value of Agile. In contrast to traditional methods, this methodology allows for fast adaptation to customers’ expectations; provides a framework for products of the highest quality and helps to develop a viable version of a product relatively fast. Sounds good right?

Should you be intending to give it a try, or just get to know a little more about it, we got you covered. Here are some of the top Agile software development questions that help you get a better picture about the process.

Is Agile only used in IT?

It originates from IT; however, several diverse industries have adopted the methodology in some way and shape, including but not limited to the finance, automotive, healthcare & pharma, and engineering industries.

What is Agile?

Simply put, Agile development software is a collection of best practices; namely, that the development process is broken down to pieces in a way that each development cycle adds an additional functional feature to the software. The Agile software development methodology has 12 basic principles, laid out in the Agile Manifesto.

1. Are there multiple Agile methods?There are indeed. Agile has various flavors; some of the more popular ones include Scrum, Lean, Kanban, Extreme Programming (XP), Crystal, Dynamic Systems Development Method (DSDM) and Feature-Driven Development.
2. Which one suits my project best?This always depends on your specific goals, the product and the company itself. There’s no one-size-fits-all here; you should take the time to examine which methodology is the most appropriate for your project.
3. What makes this approach better than traditional methods?Agile software development methodology allows for a user-centered development process. The software is quickly released, and customer feedback can be built into subsequent versions
4. Is it the customers who tell what the product should look like?Yes and no. They’re not telling what and how you should develop, instead what they need and consider important in a given software. That feedback should define the product itself. Agile helps by shifting the development process from feature-centered to user-centered
5. Is this method faster than other ones?Chances are it is, especially in contrast to more traditional systems. Agile software development allows you to build a functional raw version, that could be used to gather feedback from users that will later be built into the software until it meets their maximum satisfaction.
6. Do customers get a half-baked product?They don’t. What they get is a minimum viable product (MVP) with usually one initial feature. Think of sharing photos as a feature on Instagram. One basic, yet fully viable feature is not much, but can be used as a starting point for further development.
7. How long does the Agile software development process take?It always depends on the very complexity of the thing that’s being built. The advantage here is that an early version can quickly be released to the public.
8. Can you save money with this project management methodology?Most certainly you can, though in an indirect way. Since Agile software development allows for releasing a very basic version of a product, no time and money is spent on developing features that eventually will turn out to be useless. Continuous feedback helps you better understand your target audience, thus making marketing more effective and simultaneously cutting its costs.

Closing Words

Agile is indeed an effective method of running projects, and not just in software development. However, there are some prerequisites for it to work. One is a company structure that allows for cross-functional teams. Another is choosing the right framework for a particular project. In order to make things nice and smooth, try implementing the approach in smaller tasks to see what issues arise that need to be changed or improved upon. 

A product backlog orders tasks into a list and prioritizes them, so the developers know which items to deliver first. The roadmap and its requirements provide the foundation for the backlog, which usually consist of the following elements: user stories, bug fixes and features.

Although the whole scrum team works jointly on the product backlog refinement, the Product Owner owns it and is typically responsible for sustaining its items. Of course, just like every other component of a Sprint, the backlog can also run up against obstacles. Below we’ll spell out the most common mistakes a Team can make to hinder progress, and how it can keep the tool running healthy.

 How To Maintain A Smoothly Operating Product Backlog

After the product backlog is determined, it should be frequently monitored to prevent or rule out any impediments. It’s the Product Owner’s task to regularly review the tool prior to iteration planning sessions to make sure that the appropriate priorities are in place, and insights from the previous iteration has been included.

As the product backlog expands over time, Product Owners decide, which items to put into the “near-term” and the “long-term” category. The former contains items that are featured on top of the list and are more detailed. Consequently, the latter category is for tasks that are less comprehensive and important.

Apart from being a huge to-do list, a backlog serves another significant function. It constitutes a link between the Product Owner and the developers. The former might alter the prioritizes within the backlog on account of the refinement of estimates and feedback. However, it’s not advisable to make significant changes once processes are in motion, since they have a potential to interrupt the developers and cause them to lose focus. According to a study conducted on interruptions affecting developers, it’s best to keep the water as still as possible and allow some ‘quiet time’ for the experts to concentrate on their duties. This way, developers got 80% of their work done within a couple of hours. 

Related: Agile QuickTip: Limit Your Agile Teams Product Backlog

Common Blockades Affecting The Product Backlog Management

• Update blackout: The product backlog is restricted to local use and is shared rarely. This practice keeps interested parties from receiving news.
• Importance threshold set too narrow: It’s quite a frequent mistake that Teams only put maximum effort into those items that are directly connected to customers. As a result, prioritization may get distorted and the overall work only half efficient.
• Lack of modification: If the Product Owner builds up the initial backlog and fails to modify it based on feedback coming from customers and developers, it could cost the success of the project.

Wrapping It Up

A product backlog is used to give the Team guidance on how to deliver a successful project. In order for this to happen, adequate planning and organization is key. Only with these assets is it possible to keep the tool running in order and facilitate productivity and the ability to handle constant change. 

What is Agile backlog refinement? And What to do with it?

Product backlog items are all the tasks we hope to complete before we deliver the product to our customer. Every now and then, we run into some ideas that were sourced a long time ago: they are still things we might want to do in the future but we just haven’t done them up till now. 

How to apply backlog refinement correctly for items which have been there for a long time?

One idea that might really help in backlog refinement is to apply an expiration date to all your product backlog items. You can choose, let’s say, 12 months in the future, or even 18 months, for each item. And then, treat it like you would any expiration date that’s on any item in your fridge, for example.

When you open up your fridge and see that carton of milk with an expiration date that is a month off in the future, you grab and pour it without any concern because you know it’s nowhere near the expiration date. As you get closer to the expiration date, well, we’re not that confident now. We might have to sniff it, open it up, and look inside just to make sure it’s okay before we pour it and we drink it. And then if it’s a month past it, well, you go right past it for a newer can of milk. 

So, this is how we should treat the items in our product backlog. If an expiration date is in the distant future, don’t worry about it. Prioritize the item and manage it like you would any other item in your product backlog. But as you approach that expiration date, then, it’s time to really give it a sniff test. Let’s review it. Let’s evaluate and discuss it to figure out if it still needs to be there. And if a month goes by or some amount of time goes past the expiration date, well, maybe you should just throw it out – get rid of it just like you would that spoiled can of milk!

Liked this Agile QuickTip? Just wait until you hear the others! Head to my catalogue to watch the whole series on YouTube, and let me know which one is your favourite, or the most effective for your Scrum team! You can also visit our website, thinklouder.com where you’ll be able to learn more about our training and coaching offerings.