Archive for category: Blog

Sprint Tasks Tips: Staying Focused when Agile Sprint Planning

Assigning tasks at sprint planning makes us task-driven or more focused on our tasks than the goal of the sprint. For some time, it looks like we’re making rapid improvements until some tasks get blocked. Then, we just move on only to later on realize that we haven’t fixed all those tasks that were blocked. Now you’ve got just a little bit of time to resolve those things. More than that, when we’re task-driven, collaboration tends to be a last resort rather than a first resort.

Here’s what I mean:

Imagine Bill and I were on the same Scrum team. He’s a developer, I am too. If Bill is stuck on something and he comes to me for help. If I stop working on my task to help, I put at risk my ability to be successful because we’re only successful if each individual completes their task.

Not only that, I’m actually putting our sprint at risk. To avoid that, I’m more likely to make suggestions to Bill for some things he can do on his own. If it doesn’t work, he’ll come back and I’ll propose a few more until I run out of things that I can suggest. Then, I’ll ask to sit together with him and see if we can resolve this. Again, you see how collaboration is a last resort here. 

Contrast that with the “just in time” approach where everyone working on the sprint is focused on that sprint goal and assigns themselves a task not at the beginning of the sprint, but when it is needed. The result? We learn from each other, build better and make real improvements. 

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!

Product owners, the team members who’re responsible for investing in the product that we’re delivering, are not mandatory participants of the Daily Scrum. But as people shepherding the investment, they are interested in them because it’s a valuable 15 minutes spent synchronizing with the team: an opportunity to be updated with what’s happening with the product. 

What if your product owner never shows up to any of your team’s daily scrums? That’s weird. 

What if your product owner never shows up to any of your team’s daily scrums? That’s weird. 

You want to go and figure out why because this is one of those agile smells – the symptoms of a problem that may not be revealing the problem itself. Just like you would when you notice an unusual smell in your kitchen, you need to sniff around to pinpoint what it is. Maybe the things we’re working on aren’t a priority to our product owner. Or we convinced our product owner to invest in what they don’t value or understand. In that case, we should stop and speak with them. 

If your product owner doesn’t attend the daily scrums, don’t wait too long to start sniffing. Because if they’re too busy to show up, they’re probably too busy to do the other things we expect of our product owners. So, take a deeper dive, starting from the obvious reasons why and then, the not so obvious reasons so you can uncover the truth and fix the situation in time.

Liked this #AskG Tip? 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.

 

In an Agile environment, you don’t have to be nice. But you should always be kind.

Leaders should be: [Fill in the blank.] 

Depending on whether you’re a traditionalist, boomer, Gen X, millennial, or Gen Z, you probably have very different perspectives on what leadership looks like and how leaders should act. In recent years, leading with kindness is starting to take a front seat. 

“By now, many leaders have realized that when it comes to business, nice guys often finish first. Old-fashioned images of corporate callousness and greed have been replaced by a gentler, more human conception of great leadership,” according to William F. Baker and Michael O’Malley, authors of Leading with Kindness: How Good People Consistently Get Superior Results.

One perspective we can all agree on when it comes to defining leadership: “A leader is someone others choose to follow.”  If nobody is following you, you are not a leader.  The characteristics of effective leaders are the same traits we seek when choosing who to follow.

Put people first
While kindness isn’t explicitly mentioned in Agile values, it is implicit in the first which states: We value individuals and interactions over processes and tools.  Essentially it says, we put people first. We adapt our practices and our processes to meet the needs of our people, not the other way round. 

Being kind starts with empathy and caring about others.  We want our employees to care about our goals, our customers, our profit margins. If we want them to care, then we as leaders must genuinely care about their wellbeing, paths, and goals.  You would only choose to follow someone you believe genuinely cares about you — your wellbeing, concerns, and success.

Putting people first allows them to perform at their best. It allows them to care. Otherwise, what we’re saying is: “I give you money, therefore you must care.” That’s not what happens. You give me money to do a job. You don’t pay me to care. People can’t be a headcount in a spreadsheet. People are individuals — with a name and a belly button.

Take every interaction with a positive intent
If somebody screwed up or made a bad decision, it’s not because they intended to do it. If we assume positive intent in the actions and decisions of the people we lead then our focus becomes not about blame and consequences, but rather about growth, learning and improvement.  One characteristic that all effective leaders share is the recognition that “Everything is my fault!” We are always accountable for all of it. This admission allows us to have conversations about how to grow better together — how to make better decisions and take better actions.

If someone is not succeeding, it’s our role as leaders to provide the support mechanisms and structures, or create environments where they will be more successful. Leading with kindness means that we, as leaders, need to find ways to make the environment and the person more successful. When we fail to do so, it’s on us, not on them. We want to create a culture that celebrates small failures so as to avoid the large ones.

——————————————————————————————————————————–

Leading with kindness is caring. If we care, we need to assume people are acting with good intentions.

——————————————————————————————————————————–

When we talk about kind leadership, we’re modeling the behaviors of the people we want around us. We want our team to be open, transparent, and honest, be courageous, and treat other—s with respect. It starts with us.

Kind leaders don’t try to be ‘nice’

Being ‘kind’ is not the same as being ‘nice’. Being ‘nice’ is not required — being respectful is.  It’s about always letting people know where you stand with them. Being ‘nice’ is often disingenuous.  It sometimes hides our true intentions.   If someone’s trying to be nice, they may censor themselves and not be honest. Maybe it’s to avoid conflict, to be liked, or ingratiate themselves. Being nice can often mask a bunch of other motives. 

If we care about the people we interact with, we will begin to prioritize their needs above our own.. Acting with kindness means acting in a way that benefits the other person even if it doesn’t directly benefit you.  It’s about giving before asking  and never taking. 

Being kind in challenging situations means you empathize, listen, and understand. You don’t do it to be nice, likable, or it’s your job. You do it because you genuinely care.

Kind leaders are forward looking
Kind leaders ask, “How do we do it better next time?” What’s done is done. There’s nothing we can do about it. If we are as truly accountable as leaders then punishing someone for a mistake they made would be misdirected.  If somebody’s not the right fit and doesn’t work well within the team, firing them is the right thing to do. But it’s not done for retribution but rather out of kindness to that person and the rest of the team.  If you’re kind, you genuinely want that person to do well, even if it’s not at your company. And you’ll probably do what you can to give them a soft landing and help them find a better opportunity.

——————————————————————————————————————————–

Being right doesn’t matter
People are overly consumed with being right or proving themselves right. Success matters. Achieving the goal matters. Saying “I told you so” is irrelevant.

——————————————————————————————————————————–

It takes courage to be a kind and effective leader
Not everything works out the way we want it to. To provide openness, feedback and clear direction means we’re exposing ourselves to potentially failing. Fear of failure isn’t unreasonable. The courage to face that fear is what makes someone a good leader. 

A leader is someone you choose to follow
Kindness is a characteristic people want to follow. If your team knows you care about them, their success, and what happens to them, that means they can trust you. If they can trust you, they can collaborate with you. They won’t be afraid to fail because they know you won’t throw them under the bus. You’ll protect and shield them. If all this is true, they are more likely to follow you. These are all attributes of kindness in leadership. 

In order to be kind, we have to care.

 Is Your Team on Target? How to use Scrum Burndown Charts to Measure Performance

Scrum Burndown Charts are designed to provide your team with feedback on how you’re performing, so you can make informed decisions as you move forward.  There are different levels of burndowns including project, release, and sprint burndowns, but they all have the same purpose — to give your team feedback against your target plan. 

All burndown charts have the same basic structure: measuring time (X axis) versus planned work remaining (Y axis). We’re going to look at four different ways of measuring a sprint burndown at the Product Backlog Item (PBI) level.

Burn down the number of incomplete PBIs on the sprint

The challenge with burning down the number of incomplete PBIs is that sometimes items vary dramatically in size. If some items can be implemented in 3 days while other items may take 7 or 8 days, this may not give you enough precision in terms of how you’re doing against the plan. 

Burn down the estimate of incomplete PBIs

The drawback with burning down the estimate of incomplete PBIs is that some items can only be completed in half a sprint. Your chart will accurately show a horizontal line until day 6, but it’s not very informative in terms of showing whether you’re on target or not. You won’t know until day 6 or day 7 if you’re behind, and at that point, you won’t have a lot of options.

Burn down at the sprint task level

If you’ve identified 100 tasks that you must execute during the sprint, you can burn down the number of incomplete tasks. But take note: your plan isn’t fixed. If on day one, you had 100 tasks and on day two you had 95 tasks, it doesn’t necessarily mean you’ve completed five. You could have completed 10 and identified 5 new tasks.

This chart shows you the number remaining which includes both those to be completed, those removed, and those that you added.  However, if some of the tasks vary dramatically in size (from an hour or two to a couple of days), then burning down the number of tasks may not give you a great enough level of precision.

Burn down the estimated task hours remaining

You may decide to estimate the 100 tasks by the number of  hours it should take to complete them. If the total estimated hours are 500, you’d expect to have no hours remaining at the end of the sprint. There’s a trajectory you’re supposed to take – a flight path your team’s work must take to finish this planned amount of work in this amount of time. This becomes the target.

Why plotting your progress helps you make informed decisions 

By plotting your team’s progress on a daily basis, you can clearly see the trend of when you’re going to complete this planned work. If you’re looking at a burndown with the red line as opposed to the burndown with the blue line, it should lead you to make very different decisions.

The blue line tells you that you’re ahead of plan and there’s very little risk of not finishing everything you planned. But the red line tells a very different story, because based on your current rate of progress, you’re not going to finish everything you planned. This means you need to be very careful about what you choose to work on, since only the completed tasks become part of the increment.

Take note: the estimated hours remaining is not equal to the original estimate minus time spent – it’s a re-estimation of the time remaining now you’ve started working on it.

The Bottom Line

Burndown charts are a useful way of tracking progress and helping your team make informed decisions. But a word of caution: burndown charts are only useful if they are placed where everyone can see it and your team looks at it and uses it every day.

Kanban vs Scrum: What’s Better for Your Project?

Deciding between Kanban vs Scrum can be a tough nut to crack, especially since these terms are often mistaken for one another and go hand-in-hand. However, there are some key factors that set them apart. 

What is Scrum all about?

Scrum is a framework that builds upon the Agile project management method. It’s a widely used methodology for handling projects, and keeping up rapid action, advancement, testing, and delivery of products.

Typically, projects are divided into two-week or one-month cycles called ‘sprints’. It’s the Scrum Team’s responsibility to keep the execution of pre-set tasks within the given interval, so the next Sprint may set off uninterrupted. Daily retrospective meetings are indispensable elements of a successful iteration. 

Related: Agile QuickTip: Kick off your Team with a Retrospective

What is the essence of Kanban?

Kanban is a frequently utilized agile methodology, characteristized by ‘visualization’. By contrast to Scrum, Kanban focuses less on deadlines and puts more emphasis on work in progress (WIP). Assignments and processes are added to a Kanban board, where team members can easily visualize them. It aims to identify and get past difficulties, enhance productivity and output, and make the pace of workflow consistent.

Since both approaches are iterative in nature, split projects into smaller pieces, and prioritize early product delivery throughout steady process improvement, there’s confusion over which approach is best suited to a given project — especially since a study shows  the two methods can successfully coexist in projects. 

Kanban vs Scrum: Differences in cadence

As mentioned, Scrum progresses quickly to meet each Sprint’s deadlines. Due to relatively short iterations, complicated assignments are broken down into more manageable pieces which facilitates team adaptation and learning. Sprints are handled via planning, review, and Scrum meetings on a daily basis.

Kanban’s primary goal is to keep the workflow running and alert the team about altering priorities. A Kanban board perfectly serves this purpose, as it lets the team keep track of tasks that can be uniquely categorized. Often used labels include “To do”, “Working on it”, and “Stuck”.

Individual delivery methods in Kanban vs Scrum

In Scrum, the final product delivery happens ideally at the end of each Sprint. During the Sprint review meeting, the team decides whether the Sprint Goal (the team’s predetermined objective) may be released or not.

Kanban doesn’t operate on fixed deadlines. Therefore, updates are delivered as soon as they are finished, irrespective of whether they were ready earlier or later than expected.

Important metrics used in Kanban vs Scrum

Undoubtedly, speed is Scrum’s most significant metric, providing a great reference point for how heavy workloads can be in future iterations.

Kanban relies heavily on cycle time, which indicates how long it takes for an assignment to reach the finish line. Boosting this metric is crucial for the efficiency of Kanban teams.

Different accountabilities in Kanban vs Scrum

Scrum accountabilities are built on three specific pillars: the Product Owner, the Scrum Master, and the Developers. The first advocates for the customer, promotes developer task-prioritization, and handles the product backlog. The second guides the team to achieve optimal results. Lastly, the third delivers increments and requested business values.

Would You Like To Improve Your Skills As A Scrum Master Or Product Owner? Check Out Our Available Online Classes!

In Kanban, there’s one collective team working on the board. Sometimes a coach is appointed for better coordination, but these teams usually operate based on mutual responsibility.

Which framework fits your project best?

There’s no clear answer to this question. It’s all project, team and goal-dependent. We’ve identified key considerations to help you decide what will work better for your project:

• Customer-centric approach:
  Scrum is your go-to method. Feedback is the backbone of any Scrum Team, helping them learn what’s best for customers, and refocus priorities accordingly
• Framework with milestones and boundaries:
  Choose Scrum, since its limited flexibility may foster better productivity, efficiency and output
• 10+ people in your team:
  Consider Kanban. Scrum is suitable for smaller groups because of daily meetings and fixed deadlines; Kanban is ideal for bigger teams that mostly work on a collective board.
• Changing project goals or priorities:
  Pick Kanban. While Scrum operations are more prone to stoppage due to delays, Kanban processes usually don’t build upon one another. It all comes down to continuous update release. When there are several different requests in varying size and priority and one process runs up against obstacles, the others will keep going.

Still not sure? Talk to one of our experts about whether the Scrum methodology is a good fit for your organization.