Agile Coaches' Corner

This week, Dan Neumann is joined by David Horowitz, the co-founder and CEO of Retrium! Retrium is an incredible tool that’s all about helping teams have engaging retrospectives that fuel continuous improvement. It enables Agile teams to have more effective conversations, discover new insights, and generate action plans by providing a toolbox of activities, a guided facilitation process, and a space to organize your retrospective documentation in one place

In this episode of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: Do Sprint Reviews and Sprint Retrospectives Overlap?

Why do we talk about what went well in a Sprint Review?

In a Professional Scrum Foundations class I taught recently, one of my students asked if there was an overlap between the Sprint Review and the Sprint Retrospective. She was reacting specifically to the statement from the Scrum Guide that in Sprint Planning, “The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.” Doesn’t that discussion properly belong to the Sprint Retrospective?

It’s easy to see how someone could be confused by that statement in the Scrum Guide. After all, a common format for Retrospectives is “What went well, what could have gone better, and what could we do differently?”

The Intent of a Retrospective

The difference is in the intent. In the Sprint Retrospective, the Development Team is focused on how it can improve its work. Whether that has to do with the way we work together, the tools we use, improving our Definition of Done, or some process we’re using, the goal of the Retrospective is to produce improvements it can introduce into the next Sprint.

The Intent of a Sprint Review

By contrast, the focus of Sprint Review is to collaborate on the most valuable thing we can do next with regard to the product. When the Development Team talks about what went well and what problems it ran into in this context, it is valuable feedback to the Product Owner and stakeholders about the nature of their work—facts that ought to be taken into account when creating and ordering Product Backlog items.

Provide Feedback

Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at [email protected].

Want to Learn More or Get in Touch?

Register for our upcoming AgileThought Virtual Community events: "Working Agreements Workshop" and Kanban for Work and Home"

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 of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: Do Sprint Reviews and Sprint Retrospectives Overlap?

This week, Dan Neumann is joined by George Dinwiddie, an Independent Software Consultant and Coach who works with organizations both large and small to develop software more effectively. He strives to help organizations, managers, and teams solve the problems they face by providing consulting, coaching, mentoring, and training at all levels.

 

Dan and George will be taking a deep dive into George’s newest book, Software Estimation Without Guessing: Effective Planning in an Imperfect World, which addresses both the technical and sociological aspects of estimation. In this episode, George takes listeners through several chapters of the book, key points and best practices, as well as myths and misconceptions, all to help your organization achieve its desired goals with less drama and more benefit!

 

Key Takeaways

What is software estimation?

A tool to estimate for the particular need you and your organization has

Estimation in comparison to past experience and by modeling the work mathematically (or a hybrid of both)

One of the big purposes of making estimates is for the business to build a look ahead and make decisions

What are not estimations?

Commitments

Negotiations

Plans

“Estimations are wrong; if they were right, they would be called measurements.”

How to estimate/estimation best practices:

It’s important to track progress with your estimates to create a feedback loop (burn up charts are an easy way to do this)

It’s okay to be wrong in the estimates

With sprints, you want to be more 50/50 with the estimates

Communication is critical

Having contingency plans in place is a good idea

Estimations are not the same as plans — estimate, and if it is critical, then put in some contingency buffers

Allow for some space for the unexpected

When you find out that your estimate is wrong then that means some assumption that you’ve based your estimation on is wrong (so there’s a lot of value in analyzing what assumption is untrue and to learn from it)

For simple estimations (like how much work to take on for the next two weeks) you don’t need a lot of precision or accuracy

Set near-term estimates

Be clear about how far along you are (“...otherwise, you’ll be fooling yourself”)

Have a good measure of what is done or not (you can use test automation for this)

A model can be very helpful but if it doesn’t really track reality then it’s going to lead you astray

The book’s purpose:

It strives to help people work with estimates (given a desire to have things come out well)

Provides a guide for comparison-based estimates

It’s not very recipe-driven; it more so provides things to think about and options to consider

A how-to on estimating for unknowns

Rather than walking people through a series of steps, George’s book aims to help people think about what they’re trying to accomplish and how what they’re doing is accomplishing that

Approaches to estimation:

Enlisting Expert Estimators 

Using a model such as the COCOMO model (which is encoding how you compare it to other experiences)

Utilizing function points

Notes about the social side of estimation:

Having in-person communication skills are just as important as your programming skills

The better you can balance a concern for the needs of self, the needs of the other, and the needs of the context, the better things will be (even if the other person is not doing a good job of balancing them)

 

Mentioned in this Episode:

George Dinwiddie

Software Estimation Without Guessing: Effective Planning in an Imperfect World, by George Dinwiddie

Agile Estimating and Planning, by Mike Cohn

Planning PokerFibonacci Sequence

Agile2020 Conference

James Grenning

Software Estimation: Demystifying the Black Art (Developer Best Practices), by Steve McConnell

COCOMO Model

Burn Up Chart

Gerald Weinberg

Donald Rumsfeld — Unknown Unknowns

Virginia Satir’s Concept of Congruence

The Fifth Discipline: The Art & Practice of The Learning Organization, by Peter M. Senge

 

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 George Dinwiddie, an Independent Software Consultant and Coach who works with organizations both large and small to develop software more effectively. He strives to help organizations, managers, and teams solve the problems they face by providing consulting, coaching, mentoring, and training at all levels

In this episode of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: Is there anything wrong with the Scrum Master scheduling and running all the Scrum events?

Today’s question came up in a discussion about the perception that a Scrum Master’s responsibility includes scheduling all the Scrum events and running them all. Is there anything wrong with that being the Scrum Master’s responsibility? After all, the Scrum Guide says that one of the Scrum Masters’ services to the Product Owner and to the Development team includes “Facilitating Scrum Events as requested or needed.”

Danger 1: Scrum Master as Admin Assistant

While that’s true, I think there are hidden dangers in assuming that “as requested or needed” means “always.”

The first danger is that it risks turning the Scrum Master into an administrative assistant to the team. Remember that a Scrum Master is also supposed to provide other services to the Scrum Team and to the organization at large. When a Scrum Master’s primary responsibility is to schedule meetings and run them, it necessarily means that the Scrum Master has to limit other activities that may provide higher value.

Danger 2: Teams Will Not Self-Organize

The second danger, and the more significant one, is that it may impair the team’s ability to self-organize. This is especially true in the case of the Daily Scrum. The Daily Scrum is a tool for the Development Team to self-organize around solving problems, and the Development Team is explicitly given responsibility for conducting the Daily Scrum. When this responsibility is shifted onto the Scrum Master’s shoulders, the Daily Scrum often transforms from a collaboration session into a round-robin status report of Development Team members to the Scrum Master. For the other events, it is valuable for everyone on the Scrum Team to develop the skills necessary to facilitate the Sprint Planning, Sprint Review, and Sprint Retrospective events.

Conclusion

There’s nothing wrong with a Scrum Master facilitating events “as requested or needed,” but if the Scrum Master is always needed and is always requested, it’s a sign that the Scrum Team needs to work on its self-organization.

Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at [email protected].

Want to Learn More or Get in Touch?

Register for our upcoming web meeting "Staying Focused in a Remote Work World."

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 of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: Is there anything wrong with the Scrum Master scheduling and running all the Scrum events?

Joining Dan Neumann today is Andrea Floyd, an Enterprise Agile Transformation Consultant within AgileThought! Andrea has 25 years of experience in software development and project management. She’s been an innovator that has a ton of experience leading multiple organization-wide Scaled Agile implementations as well as architecting innovative solutions, strategies, and roadmaps across many frameworks (including Scrum, Kanban, and Scaled Agile Framework).

 

Today, Dan and Andrea will be taking a look at some of the reasons why Agile transformations don’t stick! Sometimes transformations get announced with fanfare… but then die off with whimpers. Tune in so that you can reduce the chance of failure and give your teams the best chance of success!

 

Key Takeaways

Top reasons why Agile transformations don’t stick:

If the organization doesn’t understand why they’re doing a transformation and how it is going to impact them on an individual level there will be resistance (which will erode the intention behind the transformation)

There is a lack of identifying a team of champions throughout the organization

The train goes off the track; i.e. the ‘rubber-band theory:’ if you don’t continually reinforce positive behaviors and have a deep understanding of the ‘why’ behind the changes being made, it often becomes a series of checking off the boxes, which leads to a breakdown

If someone is not looking for anti-patterns and helping to coach others about the transformation, individuals will go back to their old ways

If you don’t put the right investment in your transformation or the change that you’re trying to create, you’re not going to see the results that you’re looking for

How to ensure that your Agile transformations stick:

You need to have an awareness of why you’re doing a transformation and it needs to be shared enterprise-wide

The transformation should be done holistically and in small pockets where you can actually start to demonstrate the value of the transformation

You need a perfect marriage between having enterprise-wide support and individuals who are fully on board

The message of how the transformation is going to impact individuals in a positive way needs to be reinforced often

You want to make sure there is transparency

Make what the transformation is trying to achieve and the progress that is being made towards that visible and known

Foster a community of believers who turn into supporters

Identifying a team of champions throughout the organization, which helps set up the transformation for sustainability (five is usually a good number)

Having someone to monitor or provide ongoing awareness around the transformation (i.e. a trusted advisor who can provide support to individuals who are wary about the changes)

It’s important for the organization to also take responsibility for moving things forward

Show the value and improvement of the transformation sooner rather than later

Get people excited about the changes by showing other teams’ success

Create a sustainable environment with sustainable practices and people that can actually continue after you leave

 

Mentioned in this Episode:

Andrea Floyd

Real-World Kanban: Do Less, Accomplish More with Lean Thinking, by Mattias Skarin

Training from the Back of the Room!, by Sharon L. Bowman

 

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!

Joining Dan Neumann today is Andrea Floyd, an Enterprise Agile Transformation Consultant within AgileThought! Andrea has 25 years of experience in software development and project management. She’s been an innovator that has a ton of experience leading multiple organization-wide Scaled Agile implementations as well as architecting innovative solutions, strategies, and roadmaps across many frameworks (including Scrum, Kanban, and Scaled Agile Framework)

In this episode of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: How do you that in the first Sprint? Don’t you have to build out all your infrastructure first?”

Prove Your Infrastructure Works One common question I hear from students in my Professional Scrum Master classes is, “How do you deliver business functionality every Sprint, including the first one? Don’t you have to build out all your infrastructure first?”

It’s true that on a new software development initiative, there’s a lot of architectural and infrastructure work to be done at the beginning. But infrastructure alone doesn’t give stakeholders the information they need to decide whether to continue funding the project. You need to deliver some kind of business functionality to prove that the infrastructure you’ve built actually works. Stakeholders need to know that work they care about is happening.

Deliver Business Functionality

What might that look like? There’s a great example in Ken Schwaber’s book Software in 30 Days. He describes a project to build a mobile banking app. In the first sprint, the development team did a lot of work on architecture and infrastructure, but they also provided a way to connect to a web portal, designed a basic front end, and created a landing page where customers would ultimately be able to log in. They didn’t even build the capability to log in—all you could do was hit the front page.

Obviously, you wouldn’t want to release that as a product, but it still provides some small slice of business value. It provides something for stakeholders to evaluate and collaborate on with the Scrum Team. What’s the response time? Does the design look good? What might customers want to see once they log in? Was it worth continuing this project? They decided that it was. And if they hadn’t, the team wouldn’t have wasted time building out a platform that was never going to be used.

Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at [email protected].

Want to Learn More or Get in Touch?

Register for our upcoming web meeting "Virtual Lean Coffee | How To Thrive In A New Virtual World"

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!