Agile Coaches' Corner

This week, Dan Neumann is joined by a special return guest — Christy Erbeck! Christy is a Principal Transformation Consultant at AgileThought and a Certified Dare to Lead™ Facilitator. She has over 25 years of experience in domestic and international consulting, training and coaching, and working in both software development and non-product-focused environments, including manufacturing (discrete and process), distribution, and sales and marketing

In this episode, Professional Scrum Trainer Sam Falco addresses the question: "If we have stories that aren't finished by the end of the Sprint, how do we get credit for the work we've done so far?"

Introduction

I get that question a lot, both in training classes and when I'm coaching teams. It stems from a fundamental misunderstanding of what a Scrum Sprint is for and how Scrum Teams should measure their effectiveness.

How does seeking credit relate to the Agile Manifesto?

Two of the principles behind the for Agile Manifesto are relevant:

1. "Working software is the primary measure of progress." It doesn't talk about credit.
2. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

Seeking credit for unfinished work violates both principles. There's no value in unfinished work!

OK, mister smart guy, I hear people saying, but it happens. Sometimes things don't get finished. What should we do about it?

Achieving the Sprint Goal without finishing all Sprint Backlog items

In the most positive scenario: the team achieved the Sprint Goal, but there were some extra items in the Sprint Backlog that weren't directly related to it. We have a working, thoroughly tested Increment that meets our definition of "Done," but we also have these one or two things we were doing, and we've run out of time.

If that's the case, congratulations on creating a potentially releasable increment! As to those extra bits that you thought you could finish, have a conversation with your Product Owner. Is this work worth continuing? Make sure it is reflected in the Product Backlog, so the Product Owner can order it appropriately. Maybe it should go into the next Sprint, maybe not. It's the Product Owner's call.

In your Retrospective, talk about the fact that the Development Team brought work into the Sprint that it couldn't complete, and talk about why it happened. Did the team overestimate how much work it could do? Adjust for that in future Sprint Planning. Did your team add the extra work as a kind of "stretch goal," or add new work to the Sprint Backlog late in the Sprint because it was running out of work to do, and wanted to "fill up the time?" Talk about whether those are practices that add value. That half-completed work is a form of waste.

The Sprint Goal was not achieved

Another scenario, less positive, is when the incomplete work means that the team failed to achieve the Sprint Goal. There's no new working increment. If that's the case, the team needs to figure out why that happened. This becomes another topic for a Retrospective. Was the Sprint Goal too ambitious?  Worse, was the Sprint Goal simply, "Do all the things?" Learn to create better Sprint Goals. If the Sprint Goal was reasonable, figure out what kept the team from achieving it. Do better the next Sprint. Examine your practices and figure out how you can achieve the Sprint Goal next time.

Just don't kid yourself that you "get credit" for incomplete work. Don't engage in accounting tricks, where you split the Product Backlog Item and include the incomplete work in this Sprint's velocity and hope to finish the rest in a future Sprint. Carrying over work from Sprint to Sprint subverts the Product Owner's accountability for maximizing the value of the product and of the Development Team's work.

How do we measure effectiveness of a Scrum Team?

Scrum Teams should measure their effectiveness by the value they deliver, not by how busy they are from Sprint to Sprint. If the organization values productivity measures rather than value delivery, the Scrum Master should work with the organization to re-orient its outlook. The Scrum Master will also probably need to work to establish safety for the team, so that they don't feel obligated to try to fill up every minute of their time.

Conclusion

The purpose of a Scrum Sprint is to produce a thoroughly tested product Increment that is in useable condition. There is no "credit" given for work that isn't complete in Scrum. You either produce an Increment by the end of the Sprint that meets your definition of "Done," or you don't. You either fulfill your Sprint Goal, or you don't. There's no middle ground.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events

See available training courses at agilethought.com/training.

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

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

In this episode, Professional Scrum Trainer Sam Falco addresses the question: "If we have stories that aren't finished by the end of the Sprint, how do we get credit for the work we've done so far?"

Sam says:

I get that question a lot, both in training classes and when I'm coaching teams. It stems from a fundamental misunderstanding of what a Scrum Sprint is for and how Scrum Teams should measure their effectiveness.

How does seeking credit relate to the Agile Manifesto?

This week, Dan Neumann is joined by repeat guest and AgileThought colleague, Quincy Jordan! Quincy is a Principal Transformation Consultant and Agile Competency Lead who has been with AgileThought for just over two years. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. Quincy also served as a principal consultant and agile coach at SCRUMstudy.com for over six years.

 

In their discussion today, Dan and Quincy are talking all about disruptions in these unprecedented times. Right now, disruptions, especially in the transformation space, are incredibly challenging. Though, there is a silver lining given the circumstances; Disruption can also lead transformation where there wouldn’t have been without the push. So in this episode, Quincy and Dan highlight some of these transformations that they’re seeing currently happening within companies and the silver lining of what it could mean for these companies in the long term.

 

Key Takeaways

Transformations currently happening within organizations:

Airlines have had to revisit their business model and reward programs (such as extending reward points)

Companies are making very quick adjustments and shortening their feedback loop

Companies also have to respond very quickly which is causing them to figure out what they need to respond to and prioritize

Companies have a new focus that has emerged: they need to figure out the true important problem that they are solving

Companies are needing to figure out creative ways to continue operating during this time

They are adding services (like curbside pickup) and figuring out what services to subtract (such as offerings that are not applicable or appropriate during this time)

Obtaining professional certifications have gone remote as well (such as on Scrum.org)

Companies and individuals are understanding what is important to focus on now and moving more quickly to get it in place

They are figuring out how to limit their risk by figuring out what to respond to and what not to

They are limiting risk by shortening their feedback loop (sometimes to even a matter of days)

They are leveraging their infrastructure and their ability to use Cloud technologies to scale up and roll out new changes 

They are making sure that the company’s values stay central to the decisions

Final thoughts and questions around transformation:

COVID-19 has really challenged the agile space as many of its principles are grounded in being in person/communicating in person

It has proven that remote facilitation and coaching is possible

When someone’s back is pushed against the wall all of a sudden new solutions arise because you have to

It’s not just about being Lean or Agile; it’s about figuring out the right problems to solve as quickly as possible

‘What are the things that are being disrupted that will lead to true transformation and then what things are being disrupted that are being put on pause and will be revisited later?’

‘What disruptors that are happening now as a result of all of this will create a new norm that becomes what we have transformed into?’

Are we changing for now and then going back or is it a permanent change in how we do things?

There is more need and delivery on remote agile coaching and remote transformation consulting due to not being able to go on-site (will this be more of a permanent offering going forward or is it just transient until everything settles down?)

 

Mentioned in this Episode:

Mike Rowe

“Amazon temporarily suspending Amazon Shipping service”

Scrum.org

Scrum Alliance

MURAL

 

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 week, Dan Neumann is joined by repeat guest and AgileThought colleague, Quincy Jordan! Quincy is a Principal Transformation Consultant and Agile Competency Lead who has been with AgileThought for just over two years. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. Quincy also served as a principal consultant and agile coach at SCRUMstudy.com for over six years

In this episode, Professional Scrum Trainer Eric Landes addresses the questions: "How technical stories should be used in Scrum?"

Overview

I have been asked how technical stories should be used in Scrum.  Great questions, and of course Scrum has a framework, while not specifically talking to this issue.

When discussing technical stories, I typically am thinking about things like product performance, system availability, and security.  I refer to these as non-functional requirements, and the Scrum guide does not specifically speak to NFRs.  However, the scrum guide has this to say about the product backlog:

"The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. "

So, looking at the scrum guide definition it would seem that we can put NFRs in the product backlog.  Of course, the last sentence of this part of the scrum guide:

"The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering." means that the team needs to work with the Product Owner on NRFs that belong in the product backlog.

Example of a Non-Functional Requirement

Here is an example of an NFR that might be used in the backlog.  The team has a screen on an application that shows personal information, including credit scores to a sales administration user of your application.  Your security team has deemed that Personal Information like this cannot be displayed due to certain laws within different countries. Your product owner could add a PBI that describes hiding data on the Sales administration screen, which is not adding functionality. 

Refine the Definition of Done

I also tell students that NFRs that apply to multiple PBIs might be a candidate for definition of done.  For instance, if we have a security requirement that all code must be run through a static code analysis and then dealt with, we might put running a static code analyzer against source code as part of our definition of done. 

Update the Acceptance Criteria

Another way to deal with an NFR is to place it in the Acceptance Criteria of a PBI. Let's say we have a feature that includes posting data to an external data store.  The requirement was that after a sales transaction the sales data needs to be pushed in that data store within 10 minutes of the transaction.  We could easily put that into your Acceptance Criteria.

Conclusion

The bottom line is that while Technical Stories, or Non-Functional Requirements are not mentioned explicitly in the Scrum Guide, the framework gives teams ways to handle them.  And in typical self-organizing fashion, it is up to the team to determine the best way to handle this for their application.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events

See available training courses at agilethought.com/training.

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

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

In this episode, Professional Scrum Trainer Eric Landes addresses the questions: "How technical stories should be used in Scrum?" Great questions, and of course Scrum has a framework, while not specifically talking to this issue.

In today’s episode, Dan Neumann is once again joined by his colleague, Quincy Jordan! Quincy is a Principal Transformation Consultant and Agile Competency Lead who has been with AgileThought for just over two years. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. Quincy also served as a principal consultant and agile coach at SCRUMstudy.com for over six years.

 

Today, they’re talking agile psychology and the rise of the agile Jedi. They go beyond the general skills and practices of agile to the key mindset pieces and various ways of thinking. Similar to a Jedi, agilists need to also go on a journey of mastery to improve all aspects of their skills. So tune in to find out more about agile psychology and begin on your path to becoming an agile Jedi!

 

Key Takeaways

What is agile psychology?

Being more in tune with how things are impacting the teams

From a human standpoint, you’ll have an easier time getting teams to perform better

Understanding people better and then understanding how to use that information effectively

Evaluating things like reading the room and reading microexpressions — and not only picking up on them but knowing what to do with that information

What does it mean to be an agile Jedi?

It is a play on Star Wars — Jedi is a master of certain skills, so in reference to agility, it is referring to going beyond agile coaching to a true mastery of agile psychology and understanding how you influence vs. manipulate, etc.

It’s about mastering the soft skills, reading microexpressions, seeing microaggressions, etc.

Quincy’s tips for coaches and project managers:

It’s important to ask yourself if the project was truly successful (i.e. it’s not always just about getting the result — ask yourself, ‘Are you contributing to a sustainable model?’ or ‘Is this a sustainable business model that goes toward business agility?’) 

As a coach, it is important to teach behaviors and skills rather than a shift in mind-shift

Bad practice: project managers that are more concerned about if the process was followed rather than if the outcome was achieved

It’s important to understand that the individuals on your team understand the psyche of the role they’re assigned in an agile framework (i.e. you can’t just spray paint a lime orange and call it an orange!)

When you’re moving someone from one role to another during an agile transformation it is important to take psychology into consideration

It’s important to consider the ‘why’ behind the Agile Manifesto

Agile coaching vs. Agile psychology:

A key difference: getting into the experience that those that you’re influencing are having i.e. influence vs. manipulation

The difference between influence vs. manipulation is the intent

If you’re operating in agile psychology, you want to influence, not manipulate

Helpful tools, tips, and skills around building agile psychology:

Active listening training can be helpful in helping you to empathize with the person you’re listening to and forcing you to put your own thoughts aside and genuinely listen — critical thinking is also crucial

Micro-expressions and negotiation training is beneficial in learning how to read others (the agile psychology part comes in when you learn what to do with this information)

If you can empathize with someone it puts you in a better position to help them in shifting their thinking that is more beneficial for the whole

 

Mentioned in this Episode:

The Dave Ramsey Show (Podcast)

National Public Radio (NPR)

Active Echolocation

 

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 today’s episode, Dan Neumann is once again joined by his colleague, Quincy Jordan! Quincy is a Principal Transformation Consultant and Agile Competency Lead who has been with AgileThought for just over two years. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. Quincy also served as a principal consultant and agile coach at SCRUMstudy.com for over six years

In this episode, Professional Scrum Trainer Sam Falco addresses the complaint: "I don't like Scrum because there are too many meetings."

At first glance, that seems like an odd thing to say, because there are only four meetings.

The Meetings in Scrum

Sprint Planning is timeboxed at up to eight hours for a one-month Sprint. It's usually shorter for shorter Sprints.

The Daily Scrum, as the name implies, happens every day, but it's timeboxed to no more than 15 minutes.

Sprint Review takes no more than four hours for a one-month Sprint, and it's usually shorter for shorter Sprints.

Sprint Retrospective maxes out at up to three hours for a one-month Sprint. Like the other two big events, it's usually shorter for shorter Sprints.

In a one-month Sprint then, you're spending no more than 15 hours in the big events, and for the Daily Scrum, five or so hours spread out in fifteen-minute increments. And that's out of roughly 160 hours per month. That means that we're talking about twelve to thirteen percent of your time in meetings that are designed to make the remaining 87 percent more effective.

It's not actually that much time. So, what drives the complaint that Scrum has too many meetings?

Scrum Might be Adding Needed Structure

One driver comes when Scrum is being introduced into an environment where there aren't many existing meetings. Usually, this is an organization that is emerging from a startup culture, where there is a more wild-west style, with an informal network of ad-hoc communication. As startups grow, that informal network starts to break down. A framework like Scrum ensures that the necessary coordination and collaboration occurs. Otherwise, meetings metastasize across the calendar.

Get Rid of Some Old Meetings

More commonly, I hear the complaint in the context of an organization that already has a ton of existing meetings. Scrum events are overlaid like a veneer on existing process and meetings, which are retained without examining them to determine if they're providing value.

The Solution

The solution is not to add Scrum to existing process and meetings. Scrum is a radical replacement for an ineffective, bureaucratic culture--including all those meetings that aren't providing value. Odds are, the Scrum events supply all the value you need for effective collaboration and delivery. If you find that you really do need more structure than Scrum provides, you can always add it back in.

Regardless of which direction the concern about too many meetings comes from, implementing Scrum requires intentional, thoughtful organizational redesign. That calls for an experienced, effective Scrum Master who is adept at navigating all levels of the organization and helping achieve business agility.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events

See available training courses at agilethought.com/training.

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

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