Agile Coaches' Corner

Recently, Dan received an email from a listener that posed an interesting question. In short, they said, “We’re doing alright every sprint and the business is doing alright too — we’re not really facing any competition. So, when the team asks, ‘Why should we continually improve?’ how can I help them through that scenario?” This is a great question! Though this team is stable, have been working together for a long time, and are doing well — they’ve reached a plateau.

This episode marks the first anniversary of the start of the Agile Coaches’ Corner podcast! In celebration of this special mark, Dan Neumann and his collaborator, Sam Falco, are taking a look back at the very first episode: “Do Scrum Well Before Scaling!” They’ll be revisiting the topic — but from a slightly different angle this time: “What anti-patterns interfere with or prevent good scaling?”

 

Tune in to hear Dan’s and Sam’s anti-patterns around scaling in Scrum and some of their solutions on how to address them or stop them before they start!

 

Key Takeaways

Anti-patterns that interfere with or prevent good scaling:

Not having a sprint goal; not having one clear goal for the sprint that is understood by everybody (which ends up creating a laundry list of items that are not tied together which can create unrealistic expectations about delivery)

Having two sprint goals (which causes a lack of focus) — “If you aim at two goals you won’t hit either of them!”

That everything doesn’t have to be integrated or can be integrated after a few sprints (this can be a side effect of not having a clear sprint goal), which creates risk build-up

If everything is not integrated, technical debt will bring things to a grinding halt and create a mountain of undone work

A lack of automated testing and thinking you can build out the unit tests and automated functional tests later — because later might never happen or, by the time you get to it, the effort becomes far too large

Team dysfunctions and anti-patterns that affect scaling:

Not making the impediments visible — if you make the impediments and dependencies visible and communicate in-person this can be resolved fast!

A common dysfunction in beginning Scrum teams is this concept that individuals own the product backlog items which leads to siloed work (which, in turn, can lead to not getting things done because the team takes on more than it can handle and cannot coordinate properly)

Assigning stories to individual developers (when it is actually much more effective to leave the PBI unassigned or assigned to the Product Owner)

Multiple Product Owners for an individual Scrum team (you only want one — but if there are multiple ones in a scaled environment they should be aligned!)

 

Mentioned in this Episode:

The Scrum Guide

Agile Coaches’ Corner Ep. 1: “Do Scrum Well Before Scaling!”

Agile Coaches’ Corner Ep. 51: “Getting to ‘Done’ Within a Sprint”

Agile Coaches’ Corner Ep. 43: “The Importance of the Product Owner Role in Scrum with Sam Falco”

Scrum@Scale

 

Sam Falco’s Book Pick:

Mastering Professional Scrum: A Practitioners Guide to Overcoming Challenges and Maximizing the Benefits of Agility, by Stephanie Ockerman and Simon Reindl

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

This episode marks the first anniversary of the start of the Agile Coaches’ Corner podcast! In celebration of this special mark, Dan Neumann and his collaborator, Sam Falco, are taking a look back at the very first episode: “Do Scrum Well Before Scaling!” They’ll be revisiting the topic — but from a slightly different angle this time: “What anti-patterns interfere with or prevent good scaling?”

Today Dan Neumann will be focusing on the topic of getting to ‘done’ within a sprint.

Getting an increment to ‘done’ is really challenging — even for Scrum teams that have been working for a while. So it is especially challenging for folks that are new to Scrum and sprinting all together. Even at the longest duration of a sprint (which is one month), it can fly by incredibly fast! So if you’re used to really long delivery cycles with long requirements, think about how fast a two-week sprint will go!

 

So how might we get to a done increment? Tune in to find out!

 

Key Takeaways

What does it mean to get ‘done’ in a sprint?

In the Scrum Guide, it says that the increment must be done and in usable condition

The team ultimately decides what ‘done’ is (but it does need to be in usable condition)

What do we not want to do to get to ‘done?’ What methods — though, often posed — simply do not work?

Nailing the requirements up-front so they’re moving because it’s easier to hit a static target than a moving one

Building within the sprint and then testing within the next sprint (which is a non-option because within each increment it should be in a usable condition)

Build for seven days, do a code freeze, and then test for three (which is ineffective because you end up with questions such as: ‘What did the developers do for the last third of the sprint?’ And, ‘What do the quality specialists do for the first two-thirds of the sprint?’ etc.)

Implementing “Wagile” (Waterfall-Agile), where you nail the requirements and then iterate through the delivery of the requirements through the sprint

Extending the sprint because the work isn’t done (this is the best time to stop and have a retrospective)

Dan’s recommendations for new teams looking to get ‘done’ every increment:

As a Scrum team, collaborate to break your product backlog items down into smaller pieces (small batches are going to move through the sprint faster, and a smaller product backlog item will get delivered more quickly than a large product backlog item [it’s far more valuable to have 9 things at 100% and 1 at 0% than to have 10 backlog items at 90%])

Make sure that everyone on the team is really focused on quality

Really maximize the amount of work not done; ruthlessly focus on meeting the acceptance criteria for your product backlog items and no more than that

Pull your testing forward

An activity that can be super valuable for Scrum teams is to have a subset of the team (representing quality, development, and the product owner) to get together and define what the test cases are that are ultimately going to have to pass

Look for tools to support the people and interactions — tools can really help your Scrum team move forward rapidly (tools that can automate the unit tests that need to execute are especially beneficial)

Encourage more self-organization and look for ways to increase more collective code ownership within your team (activities like paired programming and mobbing can help with this)

Dan wants to hear from you!

What ideas have you tried and seen work for getting code to ‘done’ within a sprint?

What have been some things you’ve tried and haven’t worked?

Would you be willing to start taking more notes throughout your day and then give yourself some time to reflect on those and identify your own areas of growth? And, if you do, what did you find out?

 

Mentioned in this Episode:

The Scrum Guide

“Wagile” (Waterfall-Agile)

Pair Programming

Mob Programming

Agile Coaches’ Corner Ep. 45: “The Benefits of Mob Programming with Chris Lucian”

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

Today Dan Neumann will be focusing on the topic of getting to ‘done’ within a sprint. Getting an increment to ‘done’ is really challenging — even for Scrum teams that have been working for a while. So it is especially challenging for folks that are new to Scrum and sprinting all together. Even at the longest duration of a sprint (which is one month), it can fly by incredibly fast! So if you’re used to really long delivery cycles with long requirements, think about how fast a two-week sprint will

We, as humans, are really intolerant of uncertainty to a large degree. We actually are inherently set up to dislike uncertainty in most situations.

 

So how do uncertainty and our ability to be able to deal with it have anything to do with agility and my everyday work team? Well, Dan thinks it has everything to do with it! Uncertainty and our ability to cope with change affect how teams function, how people respond, and even how the team plans projects in the first place.

 

In this episode, Dan jumps right into what uncertainty is (and why we, as humans, are rather intolerant of it), how we can better cope with uncertainty, how it relates to agility, and how agility can be used to address uncertainty!

 

Key Takeaways

How do we respond to uncertainty?

As the uncertainty of an outcome approaches the 50% mark (i.e. there’s a 50% chance that an outcome could be either negative or positive), that is when our stress response is highest

If we already know the outcome (be it positive or negative), there will not be much of a stress response either way — it is with the uncertainty that it is the highest

The five coping techniques as outlined in “5 Ways to Manage Your Fear of Uncertainty”:

1. Commit to gradually facing uncertainty

2. Connect to a bigger purpose

3. Don’t underestimate your coping ability

4. Bolster resilience by increasing self-care

5. Appreciate that absolute certainty is impossible

How to address uncertainty with agility:

Shifting away from plan-driven software into a more agile approach can bring the fear that there is a lot more uncertainty in delivering the software — however, agility actually helps us face uncertainty by slicing capabilities and through establishing feedback loops

On the technical side of agility, uncertainty is also addressed through automated unit testing and test-driven development

Frequent code check-ins are also valuable in addressing uncertainty

In terms of connecting to a bigger purpose to address uncertainty, think of the scrum product owner as a chief storyteller (their job is to articulate the purpose and help those on the team connect their contributions on a daily basis to the greater vision of the product overall)

‘Don’t underestimate your coping ability’ when applied to agility can be thought about as the ability to deal with things when they don’t go well

When people underestimate their ability to deal with software that may need changes down the line, they’ll overbuild software — so it’s important to remember: YAGNI (You ain’t gonna need it!)

Most importantly, remember: “You don’t want to sacrifice the good enough for the perfect” — you can always change the code down the line, it is not detrimental

Bolster resilience by increasing self-care by sleeping well, taking a nap at work (if you can), and taking a break when you’re feeling stressed

You can also bolster resiliency by growing your technical chops (through coding katas), looking for opportunities to engage with the broader community (through code camps or meetups focused around your particular domain), and looking for opportunities to play at events like Global Game Jam (because social connections often bring you new opportunities and new ideas you can leverage on your teams as well)

It is important to remember that absolute certainty is impossible; there is no way of knowing our code will meet the needs of a user forever — in fact, it’s quite impossible to have the perfect solution that will work forever (so roll with the changes as they come in and simply embrace it!)

 

Mentioned in this Episode:

“5 Ways to Manage Your Fear of Uncertainty,” by Jelena Kecmanovic (Fast Company)

“Computations of Uncertainty Mediate Acuate Stress Responses in Humans,” by Archy O. de Berker, et al. (Nature Communications)

Agile Coaches’ Corner Ep. 49: “Concepts Around Agile: Common Misunderstandings and How to Correctly Apply the Agile Manifesto Principles”

Coding Katas

“YAGNI — You Ain’t Gonna Need It” (DevIQ)

“School’s Out,” by Alice Cooper

Global Game Jam

Lego Serious Play

 

Dan Neumann’s Book Pick:

Lego4Scrum, by Alexey Krivitsky

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

In this episode, Dan jumps right into what uncertainty is (and why we, as humans, are rather intolerant of it), how we can better cope with uncertainty, how it relates to agility, and how agility can be used to address uncertainty!

Today on the podcast, your host, Dan Neumann, is going to be exploring concepts around Agile. This is a very important topic as a lot of times we go into an organization and find that there’s a lack of clarity or a lack of common understanding about what agility really is. Often, it’s the agile itself that is confused with a popular framework on the market, or, it is seen to be implementing a different methodology than what they already have.

 

In this episode, Dan will be exploring a couple of these misunderstandings around implementing agility, what exactly defines agile, and some of the principles behind the Agile Manifesto and how to correctly engage with them

Download the Manifesto for agile software development and principles 

Key Takeaways

What defines Agile:

As the Agile Manifesto states: “We’re uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:

• “Individuals and interactions over processes and tools
• “Working software over comprehensive documentation
• “Customer collaboration over contract negotiation
• “Responding to change over following a plan
• “...While there is value in the items on the right, we value items on the left more”
  • I.e. while there is value in processes, tools, documentation, contracts, and plans, the Agile Manifesto simply places more value on individuals and interactions, working software, customers collaboration, and responding to change
• These agile values have allowed the agile approach to be more successful and a better way of delivering software than many alternatives
• Agility is not binary; it’s not that you are agile or you are not agile — think of it more like a spectrum

Common protests and misunderstandings about Agile:

• Sometimes the phrase, ‘it’s not agile,” is thrown around like a weapon — but in the manifesto itself there is nothing about how the plan is to be displayed; it’s up to the people doing the work to determine how much documentation is appropriate
• Some argue that agile is simply hip and trendy for websites or that it only makes sense for delivery of a certain type of system, yet, amongst the names of the signatories on the Agile Manifesto there are people that do a variety of work (from extreme programming to Scrum to embedded software to financial systems)
• A common protest is: “We can’t be agile because we do _______,” but regardless of the type of work you do, you can still place value in the items on the left over the right
• You don’t have to be doing Scrum or paired programming to be agile

Three of the twelve principles behind the Agile Manifesto and how to correctly engage with them:

• The second principle: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
  • How to engage with it: In some organizations, change occurs simply because their opinions change — but it’s key to really ‘welcome change’ when there is a substantial positive benefit from making it
• The sixth principle: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
  • How to engage with it: though you can email and use messaging out of convenience, it is really important to engage in face-to-face conversation whenever you can (especially when communication seems to be going off the rails)
• The tenth principle: “Simplicity — the art of maximizing the amount of work not done — is essential.”
  • What this principle means: Software development tends to be laser-focused on getting the requirements from the customer and doing all of the things that the customer needs… but the team tends to take an architecture mindset forward and overbuild (all these extra complexities create a lot more code to maintain and defers risk); AKA ‘gold-plating’
  • How to engage with it: If you want to pursue more agility, one way to do that is to start looking with a critical eye at what’s being asked for and take a look at how you’re implementing it and really try to figure out where there are opportunities to not do something or not do something yet
• Remember: Delivering working software for your customer is the highest priority rather than serving the architecture

 

Mentioned in this Episode:

The Agile Manifesto

Principles behind the Agile Manifesto

Slack

Microsoft Teams

Azure DevOps

Trello Boards

Gold Plating

 

Dan Neumann’s Book Pick:

The Truth About Animals: Stoned Sloths, Lovelorn Hippos, and Other Tales from the Wild Side of Wildlife, by Lucy Cooke

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

Today on the podcast, your host, Dan Neumann, is going to be exploring concepts around Agile. This is a very important topic as a lot of times we go into an organization and find that there’s a lack of clarity or a lack of common understanding about what agility really is. Often, it’s the agile itself that is confused with a popular framework on the market, or, it is seen to be implementing a different methodology than what they already have

This week on the podcast, Dan Neumann is joined by his collaborator, Sam Falco! Together they’re going to be tackling three Scrum-related questions that they dug up on Quora.

 

Sam finds himself running into these particular questions fairly frequently. In fact, every new client seems to have a set of similar questions! So if you’ve ever pondered, “What is better: one-week or two-week sprints,” “What is the scrum master’s role,” “What are the tasks that a scrum master has to perform,” or “What are the first things a scrum master should do when starting at a new organization?”... tune in!

 

And if you have any questions you’d like to hear answered in a future episode, you can email them to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

 

Key Takeaways

“Do you prefer one-week or two-week sprints? And why?”

The Scrum guide says up to a month

Sam doesn’t have a preference between one-week or two-week sprints as it depends on what the situation (and organization) calls for

The key is to balance how much time it will take for the development team to do the work with the risk the organization is willing to absorb by not releasing (i.e. if an organization can wait three weeks without messing with the scrum team’s sprint goal — then three weeks is a good length)

Sam recommends that teams brainstorm their definition of ‘done’

Either way, it’s important for the organization and team to maintain focus for the sprint duration, no matter the length

A short sprint means there’s less to plan, less to review, less retrospective, and it scales more linearly

All-in-all: it really depends!

“What is a scrum master role? And what are the tasks that a scrum master has to perform?”

Scrum masters are responsible for coaching the product owner, the development, and the organization

Through transparency, inspection, and adaptation they should be working to improve the system over time

They should be always be asking: ‘What value are we getting out of this activity?’

They have to remove impediments for the scrum team (once it is clear that the team cannot clear them)

They must coach and protect the team

They should help those outside of the team to understand how to interact with the team

They need to coach the team and the organization how to work in Scrum

They need to work with the organization on how to spread Scrum (as well as agile values and principles)

The scrum master has to do whatever is necessary to help the team be successful

“What are the first things a scrum master should do when starting at a new organization?”

When you’re coming into a new organization as a scrum master, you should give the team that you’re going to work with a reason to trust you (Sam recommends creating a “mind map” of yourself and modeling some vulnerability)

Have a group AMA as well as one-on-ones with each member of the team to build trust

Ask the team what their challenges are, listen to them, and address those first

Build a report with the dev team and the product owner

You should be networking within the organization and learn who’s who

If it’s a completely new organization, you want to establish good Scrum practice from the get-go, explain the ‘why’ behind the Scrum Guide, and make sure that the team is engaging in good Scrum practice

 

Mentioned in this Episode:

Quora

Mind map

Agile Coaches’ Corner Ep. 1: “Do Scrum Well Before Scaling!”

Deep Work: Rules for Focused Success in a Distracted World, by Cal Newport

Agile 2019 Conference

Quiet: The Power of Introverts in a World That Can't Stop Talking, by Susan Cain

Quora Questions:

“Do you prefer one-week or two-week sprints and why?” Asked by Sara Morsi

“What is a scrum master role? What are the tasks that a scrum master has to perform?” Asked by Rashmi Pathak

“What are the first things a scrum master should do when starting at a new organization?” Asked by Alex Dolphin

 

Sam Falco’s Book Picks:

Arcade Perfect: How Pac-Man, Mortal Kombat, and Other Coin-Op Classics Invaded the Living Room, by David L. Craddock (Author) and Milan Jaram (Illustrator)

Digital Minimalism: Choosing a Focused Life in a Noisy World, by Cal Newport

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!