Agile Coaches' Corner

This week’s Trainer Talk is with Tunde, SAFe Program Consultant (SPC). Tunde shares factors to consider when you are trying to decide if the Scaled Agile Framework is right for your business need.

Key Takeaways:

As a trainer, many people reach out to me and say, “Olatunde, why would you suggest SAFe?” Well, it’s easy:

• Any time you are trying to deliver a large quantity of software into the market
• You need the teams to synchronize and align on what they are delivering
• You want your organization to gain an edge over the competitors in the market!

Finally, if you want your organization to understand the concept of “personas.” In the market that simply means “whom we are building this software for? What are their likes? What are their dislikes? Also, when you have competitors, you know what some of their strengths are, what are some of their weaknesses, what are some of the opportunities and what are some of the threats.

When you have all these criteria in mind, then I would suggest that you go SAFe. SAFe is not for every organization. And every organization is not for SAFe. Nonetheless, I will always suggest SAFe whenever you meet those criteria.

The best time to start your implementation of SAFe in your organization is now! There will never be a perfect time. There will never be a perfect season. You know there will not be. There will never be a perfect budget. Just start. And as you evolve, as you get better, you will start noticing that SAFe has a lot of potentials and a lot of benefits for your organization. So, when in the market, SAFe also has all the benefits that help you gain an edge over the competitors in the market.

Related to this Episode:

A complete list of the current SAFe Training by AgileThought.

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 an internal colleague, Eric Landes, Professional Scrum Trainer and DevOps Coach at Agile Thought, and Brian Wawok, CEO and Co-founder at Listing Mirror, a multichannel e-commerce management platform.

In this episode, they get together to address a question posted by Brian. Brian has been working with Kanban with his team, they are looking to embrace the Scrum framework and are wondering how this transition would impact the CD.

Key Takeaways

• Brian explains what Listing Mirror is and who its customers are. He shares the reasons why they are trying to transition to the Scrum framework.
• • CD was instrumental in the success of the company.
  • Brian explains the two environments they work with at Listing Mirror (development and production).
  • They started differently, thinking in the minimum amount of process to get the best results.
  • Brian explains why they will never have a QA Team.
• Continuous Delivering in the Scrum framework happens at least once a Sprint.
• • Brian explains how he has been tracking metrics in his company.
  • Brian exemplifies their work at a Sprint review.
• Does doing Scrum means having more meetings?
• • Avoid meeting fatigue by reducing them as much as possible and making them shorter than 30 minutes.

Mentioned in this Episode:

Build: An Unorthodox Guide to Making Things Worth Making, by Tony Fadell

Public Scrum Training is available if you want to advance your continuous learning journey!

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, Eric Landes addresses a question about how the Definition of Done impacts Release Planning.

If you are interested in attending Scrum training, check out our public Scrum training courses.

In a recent class, the idea of how the Definition of Done (DoD) affects a release plan and the Product Owner came up!  So, I wanted to walk through what the Scrum Guide says, and impart some practical advice about planning with the DoD. 

The scrum guide states that "The moment a Product Backlog item meets the Definition of Done, an Increment is born".  Couple this with the Increment guidance, "an increment must be usable", this helps the Product Owner in forecasting when the increment gets in customers’ hands. 

The Product Owner uses the team's throughput, or whatever complimentary metric they prefer in their forecasting.  Then during Sprint reviews, the Product Owner shows stakeholders forecasts of when features and functionality can be delivered to customers.  The Product Owner adjusts forecasts as more learning occurs through each Sprint.

The Definition of Done impacts the Product Owner's forecasts when it does not include quality steps to get the increment to that usable state.   Product Owners want actual feedback from customers using the software in the wild, to help guide their goals.  The transparency of the Definition of Done can be used by the Product Owner to help move toward a usable Increment.

For instance, if the team needs a compliance review before something can go to production, the Product Owner should ask how the team can include this in the DoD.  The Developers might suggest collaborating with the compliance group on automated solutions.  This might add some items to the Backlog to get that automation included in the team’s delivery automation.  Now that this is in the Definition of Done the Scrum Team is in control of getting the Increment in front of the customer.   This is one example of how the Product Owner can use the transparency of the Definition of Done to improve the value they deliver.

I’d love to hear what you think. If you have a question or a comment, please email us at [email protected].

For more information on AgileThought's available courses, go to agilethought.com/services/training-certifications.  This information is also available on the page of this podcast.  Thanks for listening!

This week, Dan Neumann is joined by his colleague Quincy Jordan. In today’s episode, they address a fascinating topic: the relationship between Communities of Practice (CoP) and Agile Transformations in an Agile Journey. Quincy shares the components of the typical structure for CoP and its crucial value in an Agile Organization, especially when trying to introduce new ideas and encouraging people to experiment. Dan and Quincy also dive deep into the leadership role in supporting CoP.

Key Takeaways

• An Agile transformation needs to have a level of sustainability to it.
• • Communities of Practice are vital for installing and sustaining an Agile Transformation.
  • A CoP needs to be a structured and intentional group. It needs to be part of the strategy throughout the organization, a mechanism needs to be in place.
• Separate or general communities?
• • It depends on how large the organization is and in which aspect of the Agile Journey each particular organization is.
• How to persuade an organization to invest in a CoP.
• • Sometimes a CoP can be seen as another meeting (on top of many others), which can be a reason for resisting it.
  • Leadership needs to be on board for a successful CoP. A leader has to advocate for the Community of Practice and also has to give permission for people to attend. Leaders must show interest in what happens at the CoP, what people are learning, and how they are experiencing them.
  • A CoP must be a psychologically safe environment.
• What is a typical structure for CoP?
• • Forums: A forum is an event that happens every six weeks.
  • In each Forum, two to three concepts are introduced for people to get familiar with them and understand their benefits and risks. These forums are more of a lecture than a dialogue.
  • In between Forums, there are Core Practice Talks that occur every two to three weeks.
  • Core Practice Talks are a deeper dive into the concepts introduced in the Forums. The Core Practice Talk is where the dialogue takes place, it is a hands-on learning experience.
• CoP are great places to introduce new ideas.
• • A CoP is an excellent place to encourage people to experiment.

Mentioned in this Episode:

Listen to “Communities of Practice with Quincy Jordan” and “Exploring an Experimental Mindset with Adam Ulery”

The Fifth Discipline: The Art & Practice of The Learning Organization, 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 his colleague Eric Landes. Eric is a Professional Scrum Trainer through Scrum.Org.

In this episode, Eric and Dan talk about how Scrum.Org is approaching training. They also dive deep into the classes Agile Thought is offering for Developers, Scrum Teams, Scrum Masters, Product Owners, and Developers to help them improve their skills at the Scrum level.

Key Takeaways

• What does a Scrum.org class look like?
• • Scrum.org offers training thought for adults.
  • While learning the fundamentals of Scrum, the trainees go through an experience.
  • During the exercises, you get to practice Scrum processes.
• Applying professional Scrum for software developers:
• • Scrum for Software developers helps them use their engineering skills in a Scrum framework.
  • Not everyone participating in these classes has technical expertise (but many do).
• APS or Applying Professional Scrum for Software Development?
• • If you are trying to decide between one of these classes, you should first identify your goal.
  • APS will be your best choice if you want to find how a Team works well using Scrum.
  • If you want to know how Scrum uses technical practices in the framework, then the APS-SD is the most suitable option.
• Professional Scrum with Kanban (PSK):
• • Professional Scrum with Kanban is great for Teams who feel stuck.
  • You can try Kanban within the Scrum framework to get your Team to flow and become more predictable.
  • Kanban is a practice that helps bring flow to Scrum Teams.
  • If you are experienced, feel comfortable with Scrum, and have already taken Scrum training, PSK is your recommended training.
• Who would benefit from Scrum.Org training?
• • New people to Scrum should consider APS training as a great place to start to help Teams operate with Scrum.
  • If you are learning independently, this training is a great way to professionalize what you are doing.
• Why should someone consider a Scrum.Org class?
• • Taking courses is the way for most people to learn and get feedback.
  • The insights you can get into training from an experienced instructor are invaluable.
• What does Scrum Training look like?
• • Whiteboard software is used where the Team collaborates.
  • There are both remote and online training.
• Certifications:
• • APS certification qualifies for Professional Scrum Master 1.
  • APS-SD gives you a voucher to take the Professional Scrum Developer 1 Certification.
  • PSK gives you a voucher to take the PSK1 Certification.

Mentioned in this Episode:

Learn more about Agile Thought Training Services

Scrum.Org

Find more about the On-site training in Tampa, Florida, April 25‒26 for APS and 27‒28 for PSK

Industrial DevOps: Nine Principles to Build Better Systems Faster, by Dr. Suzette Johnson and Robin Yeman

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, Eric Landes addresses a question he received while delivering a class on Applying Professional Scrum. The student was a security specialist and was trying to figure out how Scrum teams handle the work needed to maintain security and compliance. 

If you are interested in attending Scrum training, check out our public Scrum training courses.

When conducting Scrum training, teams ask about different roles and how they fit on a team that only has developer, Scrum Master, and Product Owner accountabilities.  It is a valid question, when I introduce the Scrum framework, it can be confusing how current jobs fit into the Scrum framework accountability.

The good news is that the Scrum framework talks about accountabilities, not job descriptions.  So, the writers of the Scrum guide understand that existing job roles are not necessarily supplanted by the accountability.  But Scrum does say that your Scrum team needs to be able to complete their work to make it potentially shippable.   A student asked how it could be shippable without their security group, InfoSec approving this.  This specific organization, had to have a security review before any release could make it to production.

How does the Scrum framework handle these organizational constraints?  The Scrum guide says "Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint."   And the Scrum team self-manages to make sure they have the right capabilities for the team. 

The Scrum guide is lightweight and not very prescriptive as you have probably noticed.  I would answer that question using my experience, letting your team self-manage with this information.  Practically speaking here are four ways your team could practice that self-management to help with this question:

1. Add someone with security expertise to your team - The team would coordinate with the folks in charge of security to add that skill set to the team.  This would involve coordinating when that person would be needed.  
2. Have someone knowledge transfer with security people - Similar to number one, by having a security expert work with the team for a sprint or two, knowledge transfer can happen.  A team member volunteers to learn, the security folks agree on when this can be done, and now your team has someone with the skills to get those security policies implemented.  The security Infosec team can now work with other Scrum teams to help them add these skillsets.
3. Add security policies to your definition of done - Adding security checks to a team’s Definition of Done might help the team by providing guidance as to what can be done.  In combination with 4, this might have the least amount of time spent learning for the team.
4. Security gives teams automation to do security checks. - If your security organization is creating automation to validate security issues, your team should use this.  So, a conversation or two or more, with the security folks is needed to validate what tools are available for your team.  This could be the least intrusive option for your team.

These are 4 options that your team may want to adopt to help with Infosec or security requirements on a Scrum team.  Your team may self-manage to a better option for your organization.  Discussing what can be done within the team is a great first step!

I’d love to hear what you think. If you have a question or a comment, please email us at [email protected].

For more information on AgileThought's available courses, go to agilethought.com/services/training-certifications.  This information is also available on the page of this podcast.  Thanks for listening!

From

This week, Dan Neumann is joined by his colleague and repeated guest, Adam Ulery.

In this episode, Dan and Adam are exploring the true meaning of being Agile, which is often a subject of discussion. Dan recently found the work of two researchers named Corey Baham and Rudy Hirschheim on the theoretical cores of Agile which provides valuable information about the identity of Agile.

Key Takeaways

• What does Agile mean?
• • The four cores of the Theoretical model on Agility in the mentioned research are validity, inspection and adaptation, working collaboratively, and continuous customer involvement.
• Going superficially vs. deeply into Agile:
• • A superficial approach is when people go through the motions or practice Agile behaviors and activities, maybe not fully understanding the reason why they are doing what they are doing or the benefits implied.
  • Going deeper into Agile means seeking a better understanding of the reasons behind your behavior.
• Agility at the Team level:
• • An example of a superficial approach to Agile can be when a person is named the product owner, then he/she gets a list of tasks to do, and maybe even is required to check before doing anything. There are cases when the new product owner also takes on the new role on top of a previous list of accountabilities, resulting in a very superficial approach to the functions.
  • Not going beyond the functions of your role can also be a superficial way to execute a role.
  • A deep way to develop the role is to begin to understand its true purpose and to remove the barriers preventing the achievement of those goals.
  • The whole Team must be aligned when the priorities change.
  • The environment has to add value to the Scrum framework.
  • A tight partner of alignment is discipline; the team has to say no to the things they shouldn’t be working on.
• At the leadership level, the Scrum values have to be deeply understood.
• • Superficially, a leader has a general understanding of Agile, more in terms of a process, another way to manage projects.
  • An Agile Leader has an understanding of Agile as an effective tool to help the organization to achieve the outcomes it wants.
  •  An Agile Leader removes the impediments for the Team to exercise the Agile values.
  • The whole Team must be aligned when the priorities change.
• Change isn’t easy.
• • The whole Team must be aligned when the priorities change.
  • To experience great rewards you have to put in the effort and go through the pain.

Mentioned in this Episode:

“Issues, challenges, and a proposed theoretical core of Agile Software Development Research,” by Corey Baham and Rudy Hirschheim

Lead from the Future: How to Turn Visionary Thinking Into Breakthrough Growth, by Mark W. Johnson and Josh Suskewicz

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 Adam Ulery for the first episode of 2023.

In this episode, they are talking about new beginnings and how they are the perfect opportunity to plan forward and set intentions for the future. Adam and Dan dive deep into the importance of goal setting and how to do it in the most effective way possible.

Key Takeaways

• Goal setting:
• • It is important to set and reset goals when one cycle ends and another begins.
  • Sometimes New Year’s resolutions don’t last long.
  • A key element to achieving goals and being happy with your performance is just being intentional.
  • Even if you don’t achieve the goal, the benefit is the learning opportunities you found through the process.
  • Most of the time, preparing for goal setting is about taking the time to reflect and process your thoughts about what it is that you are trying to achieve.
  • Take action!
  • SMART goals: Specific, Measurable, Achievable, Relevant, and Time-Bound.
• When does a goal need to be reset?
• • Reassess your goals at the end of each cycle.
  • Measure along the way so you know where you are. These metrics are fundamental to knowing where your performance is around the goal.
• How Teams and Individuals can be more effective in reaching their goals:
• • Allocate capacities for each goal.
  • Remember to be intentional about your goals.
  • Team members have to hold each other mutually accountable.
  • Surround yourself with high performers and your performance will elevate as well.

Mentioned in this Episode:

The Way of a Pilgrim and A Pilgrim Continues His Way, Olga Savin

“How agile software development methods reduce work exhaustion: Insights on role perceptions and organizational skills”, Viswanath Venkatesh, James Y. L. Thong, Frank K. Y. Chan, Hartmut Hoehle, and Kai Spohrer

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 Michael O’Reilly, SVP in IT within the financial services industry.

In this episode, Michael, an avid board game player, shares the similarities between Dungeons and Dragons and potentially the Scrum Framework. Michael and Dan explore this interesting analogy. The entertainment world is huge and very profitable; it is a serious business for a lot of people who are employed in this field. Also, some fun games make work much more entertaining and the learning experience easier.

Key Takeaways

• Scrum has a framework and Dungeons and Dragons has rules and infinite possibilities to take.
• Session Zero in Scrum can have a bad reputation due to how it is characterized. In gaming, it also has similar features.
• • Session zero is showing what we need to do before trying to do it, is this planning step really needed?
• Everyone wants everybody to be successful, but there is this expectation of the role each one plays, the abilities, and how each member contributes. A session in DandD is like the increments of value in Scrum.
• Transparency is always valued in Scrum as well as in any “good” constructed game.
• House rules work for games and Scrum:
• • If you don’t follow certain rules, you are not doing Scrum.
  • Table rules and house rules are like the Team’s working agreements.
• The Dungeon Master has a role that goes beyond the fun and the profits; his role is to arbitrate the rules and facilitate the adventure. What role is that in Scrum?
• • The Scrum Master could be the one facilitating the Scrum values on the Team but it is not quite the same as what a Dungeon Master does.
  • What does it take for a Game master to create a sense of agency? Michael explains how.
• How do you plan for your session/sprint?
• • If you are the Game master, you need to make sure you have the characters there that will be introduced or met.
  • Players can prepare ahead for a game; oftentimes there is homework.
  • Everybody could decide to go one way and then change their minds.
• Safety tools:
• • A lot of games provide safety tools for people to check in with their players while they are going.
  • In Scrum, a Team activity is about sharing what each member can offer and what they need, which is an effective way to clarify what each can bring to the Agile Team and in exchange ask for what is needed.
  • In the game, you attack the problem, not the people. In Scrum it is the same, you address a problem together as a Team to solve the challenges in the way to achieve the goal.
• Fun activities are valuable opportunities to learn.

Mentioned in this Episode:

Improv for Gamers, by Karen Twelves

The Art of Agile Development, by James Shore

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 Tarik Smajic from Machine Learning Team and by Justin Thatil, an Agile colleague. Justin and Tarik are both Scrum Masters but Tarik’s work is in Artificial Intelligence or Machine learning. In this episode, they explore together with Dan, the differences and similarities between Scrum and AI as well as how they complement each other by sharing valuable case examples.

Key Takeaways

• What makes AI Teams different from the Scrum framework?
• • Scrum helps to reduce complexity, and certainly, machine learning is a very complex subject.
  • Scrum is a way to start establishing norms in AI teams.
  • In the traditional software development life cycle, there are established phases in order to build software and this includes an exploratory aspect.
• It is more than data.
• • We give the client for free only the data that we are willing to give them, but there is even more data that you can think about that in the past was considered waste data.
  • There are patterns that can be found in data, that is why it is called predictive data.
  • We used to want all the data available but we started to figure out that not all that data is needed, and in case it is necessary to synthesize data that has any predictive implication.
• The beautiful dance Scrum proposes:
• • Scrum works by just enabling the particular accountabilities to do their thing, to be empowered to shine in their field of action.
  • Once you stop trying to solve problems using predictive and prescriptive analytics and start understanding where the value lies and where models need to be built.
• Case: A Team faces a product challenge.
• • Let the Team have the time to research (but it can’t be forever).
  • The Team needs to go through one cycle to establish a baseline.
  • It is better if you adopt Scrum, starting from scratch.
• Sprint reviews in AI:
• • The race to the minimum viable product can look like looking at your data asset and learning from it.
  • Tarik shares several examples.
• It is important to establish what the development phases look like while the ideation and intake Team handles the values assessments and figures out what use cases there are; prioritizing them is the product management Team’s work. Then the research aspects follow; you want the engineers to build the pipelines and then do the testing.
• Scrum of Scrums:
• • Tarik shares how they use one Scrum of Scrums on a weekly basis that only lasts 15 minutes.
  • A necessary question to ask during a Scrum of Scrums meeting is: Am I putting anything in anybody elses’ duties?
  • How realistic are the expectations? The meeting produces a forecast of what can happen.
• Application of Scrum in the AI and ML worlds:
• • Tarik shares his experience.
  • Everything in Scrum is iterative.
  • There are three phases of learning something. It takes a while to master things; patience is required.
  • It is OK to bend the rules, you don’t have to do it all by the book.

Mentioned in this Episode:

Link to a previous episode

Getting Things Done: The Art of Stress-Free Productivity, by David Allen

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!