Jan 27, 2022

Agile transformations in organizations have been occurring since before the Agile Manifesto made clear what many of us saw as gaps in our management. As we have seen over time these transformations continue to grow and evolve throughout any organization’s history and as methodologies and frameworks change and adapt. There will be setbacks, new management, new initiatives for the company, major budget cuts, etc… The nature of these ever-changing landscapes challenges even the most well-formed launches.

So what do we do about it? How do we get through a stale transformation? How do we light the fires of change or overcome the biggest roadblocks to continued success?

The following are my steps and corresponding principles that guide me when coming into an organization that feels stuck. As is the case with most Agile implementations and guides, the focus here is on the principles. The actions themselves will vary depending on your group, role, and the previous steps taken during the initial transformation.

A little disclaimer, this post is from the perspective of an internal or external coach coming in and working with an organization that feels like they are not progressing. The ideal situation is that the organization feels stuck, and uses existing retrospective and adaption ceremonies to evolve. However, in the effort to stay accurate to the real world, I am taking the perspective of the more common practice of bringing in external or internal coaches to help organizations.

How do you know this organization is stuck?

When referencing the Implementation Roadmap, the following points can be a helpful guide for determining when an organization might be stuck.

“The organization is stuck when…”

• They do not know where they logically fit on this roadmap.
• The Measure and Grow points along the roadmap provide little to no value.
• They are not moving along this roadmap or any other transformation roadmap.
• They cannot record measurable change.

In summary, if the organization is not moving down a transformation roadmap, not able to measure change, and/or is not seeing increases in their fundamental business results, then they are stuck.

Common Reasons Why Organizations “Get Stuck”.

When interacting with an organization you suspect is stuck, it is important to understand generally why organizations stop transforming in the first place.

Here are some of the most common reasons I’ve experienced in the industry:

• Changes in management or leadership
• Lack of movement on previous I&A items or retrospective ideas
• Lack of prioritization of relentless improvement
• Frustrated change agents and LACE members
• Lack of training or knowledge across the organization

I am sure every well-renowned coach has seen each of these reasons in detail and you will too; however, my Principle for Understanding is:

“Find the Sour Spots in the Transformation”

• Sour Spots in a Transformation are foundational steps that were either missed, skipped, thought too risky, or difficult at the beginning or mid-transformation that has allowed dysfunction to fester.
• Sour Spots are people, processes, products, technologies, and culture that will take more time, energy, and careful conversations than other team or organizational transformative actions.

Will all reasons be sour spots? Of course not. However, it is important to see what might qualify as sour spots and decide your best course of action for both visualizing and addressing those within the organization.

One sour spot I regularly see while coaching stalling organizations is a lack of understanding around the Value Stream Identification workshop and its outputs. This can be a tough and tiresome exercise for organizations, with little help in the beginning, and oftentimes are led by new coaches or individuals without an objective view of the organization. There are a lot of parts of that workshop that, if not done correctly, can cause scaling dysfunction. Additionally, this workshop is supposedly regularly evaluated when introducing new Epics, new product lines, and when understanding any halts in the flow of value.

If the organization had a negative or grueling experience with the initial workshop, they may be very resistant to attempt it again or put it into a regular practice. You will have to take extra time to empathize with those that feel resistant and with leadership that may feel this workshop will change their current structure or realm of control.

Evolving – Taking a Systems Thinking Approach

Now that you know how to identify an organization that’s stuck, what steps can you take to identify the key reasons/issues for the dysfunction? How do you visualize to make clear what is holding them back? It is time to bring them into a state of organizational evolution.

The steps for organizational evolution are…

1. Research this organization’s transformation past, present, and future.
   • Research: Track down the Transformation Goals and Strategic Themes to uncover the real reasons the organization had for “going Agile”.
   • Question: What is their top priority that they are not seeing measurable growth in? Does the relationship between their goals and what they are measuring match?
   • Summarize: If you could summarize their Transformation in one paragraph, what would you say?
   • Dive In: Dig into each level as its own transformation: Portfolio to Teams to Program and maybe Solution, if they have that level. Create a layout of this portfolio. I commonly take a people, process, and technology perspective here. Invite yourself to key events to see if roles match activities performed. Try to look for visible agreements, metrics, and information.
   • Listen: Everything tells you something so, don’t be afraid to gather all the information you can.
   • Re-Evaluate: Continually be on the lookout for additional sour spots within the organization or transformation. Bring them into your Empathy Interviews.
2. Conduct Empathy Interviews
   • What is an Empathy Interview?
     • Empathy interviews are about asking key coaching questions to prompt them to think about themselves and their teams within the context of the transformation.
       • What is most important to them?
       • What keeps them up at night?
       • What is lurking beneath the surface?
   • Who to Interview?
     • Find your current LACE or lead change agents. If unsure, ask around for who they may be – try to keep the number of people interviewed to as few as possible to start.
   • Why conduct interviews?
     • Interviews will tell you what the data can not. They allow you to build trust while also getting the opinions of others on the potential organizational sour spots you might discover.
3. Identify Meaningful Assessment Categories
   • Assessment Categories are highly variable between coaches, implementation, or organizational preference/goals.
   • Choose what will resonate with that organization and those leaders while embracing our Evolving Principle.
   • The output of this should be the start of a data-based assessment you can introduce to the organization.

   Some Examples:

   • Agile Values & Principles
   • SAFe Business Agility Assessment/Core Competencies
   • Portfolio vs. Program vs. Team
   • Culture vs. Product vs. System vs. Process Implementation
4. Organize Your Results
   • Choose what will resonate with that organization and those leaders.
   • Create a mix of anecdotal observations and summaries with a measurable data-based assessment.

   Some Examples:

   • Spider graphs
   • Bar charts
   • Word clouds from Empathy interviews
   • Excel sheet
   • PowerPoint
   • Interactive post-it boards
   • Mural boards

Your specific actions and ways you organize your assessments may change, however, keep in mind my Principle for Evolving:

Focus your assessments, research, and discussions on the value of “being” Agile over “doing” Agile.

There are lots of ways to do Agile Assessments or take a comprehensive view of an organization’s struggles. You may want to just grab something off the shelf and use it for any organization. However, the objective is to focus an organization on improving and humbling yourself and the processes in place to the values, principles, and needs of the organization you are working with.

It was brought up when I gave this as a presentation that some organizations are not going to care about “being” Agile, they’ll just want to check the boxes and do the ceremonies right. Us Agilists know the earth-shattering impact that Agile mindsets can have on the individuals and teams within a transformation. However, sometimes, emphasizing “being” Agile over “doing” Agile comes with time, trust, empathy, and taking a holistic and economic view. Choose the best and most focused way to get that across to your organization even if it means they continue to make some mistakes or work suboptimally.

Now that you have assessed and have a lot of very organized data, what do you do with it to make real, sustainable relentless improvements?

Transforming – Bringing in the change agents/LACE

Depending on your organization’s maturity level you might be working with a LACE (Lean-Agile Center of Excellence), part of a LACE, or a small group of change agents from that transformation. You may even be working solely with the Scrum Masters of a team(s). Regardless of the structure, it is important to find that team of individuals and start to enable them to lead their organization forward.

This organization can kick start its new transformation after you…

1. Present results to change agents/LACE and gain initial feedback.
   • Present: Time to shine! Present your results either to the LACE or respective change agents and at different organizational levels as necessary.
   • Identify: different teams depending on if it is a DevOps transformation vs. a Product Management focused transformation.
   • Ask for Feedback: Be what you preach and ask for feedback!
   • Coach: Start to coach negative organizational habits.

   It is important to note that, when you start to introduce categories and assessments and make visible the different impediments in the organization, you are going to start influencing people’s ideas or feelings on their organization’s people, processes, and technology. The sour spots are now visible, and this will not be a welcome message to some individuals or departments. It is best to continue to make these assessments visible using empathy, compassion, and humility.

2. Input results into the Inspect and Adapt, or current retrospective ceremonies of this organization.
   • Transformation Backlog: All items, regardless of priority, go into the Backlog.
   • Transformation Funnel: Start a funnel for all transformation assessment opportunities to feed back into the portfolio, program, and team improvement ceremonies where possible.

   It is important for programs and teams to start taking responsibility or asking for support on these transformative opportunities for improvement. They need to determine how to address them and when. Internal or external coaches are there to make the problems visible and help to coach change, not dictate it. So let the funnel begin!

   
3. Kick-off a Culture for Relentless Improvement.
   • Empower: Coach the LACE or Transformation group to own the transformation – My best advice here is to have the organization’s leadership or management drive the message that Relentless Improvement is the goal of the organization moving forward, and that this LACE or Transformation group are the agents of that improvement. Leadership buy-in and approval of this group, to me, is paramount.
   • Create the “Principles for Relentless Improvement”: This document should serve as a working agreement for the new/improved group of change agents. They should be able to answer how they will work together and how they plan to keep the momentum going over time.
   • Retrospect: More than likely you are performing this activity as one person or a small subset of persons. With that comes bias, preferences, and mistakes. One of the first goals of this new/improved group will be to retrospect on how they will do better with future assessments or funneling of retrospective items.

This article has included a lot of information and a lot of steps that you may or may not agree with depending on the structure of your organization, or the walls you will need to break down to get there. I will leave you with my Principle for Transforming since regardless of your structure, culture, sour spots, LACE, or Agile practices one statement remains true for instilling a culture for Relentless Improvement and continued transformation:

“The goal of any retrospective activity is grassroot change by enabling individuals, teams, and organizations to problem solve for themselves and their organization to the mutual benefit of employees and customers.”

Need additional help evolving your Agile Transformation? Learn how to improve and continuously adapt your companies strategies, plans, and outcomes by contacting one of our experts today.

Or “Is there value in assigning Business Value to PI Objectives?”

Dec 14, 2021

Now by way of context, the coaches I am talking with are all very experienced coaches, having worked with many organizations on their move to Agile, and particularly Agile at Scale. The conversation is not the result of a lack of knowledge or experience but rather based on a keen understanding of both the purpose of the practice, the why, and the organizational dynamics in which it will be applied.

So to review, the reason that SAFe suggests the practice of both PI Objectives and the assignment of Business Value is to:

My experience has been that you can use both PI Objectives and Business Value assessment effectively. But I’ve also seen the practice get in the way of progressing true change or, worse still, seen organizations simply go through the motions, with no collaboration or feedback.

I suspect that this in the end is the root cause of the different perspectives. I’ve seen the practice used very effectively. For example, I attended a PI System Demo recently and, as they went through the demonstrations, the Business Owner really closed the feedback loop by talking about what the original PI Objective’s expectation was, what happened in the meantime, and what the resultant effect was. She was clear about how we were all in this together and took pains to stress where the Program troika and the management team had contributed to (especially) less than expected results. The resultant actual Business Value assessment made sense.

But if this is not happening, then you should not force the practice. What this means is that you will need to revisit the purpose of the practice, and determine how you will get the same outcome if you do not use this particular part of the framework. For example, can the organization agree that the feedback loop is based on features being delivered and what does it mean if we do this? Can we evaluate the predictability of Business Value delivered through more direct means, such as a result of the telemetry of released product? Should we use PI Objectives without assigning Business Value so we can establish this important feedback loop? And so on.

Like all changes that affect the organization, context matters. And sometimes even experienced coaches will have to agree to disagree.

Need additional help?

PI Planning can get messy! If you find yourself in a bind, then drop us a line. We’d love to help you with your PI Planning. Let us know your concerns, and we’ll set up a consultation with an experienced SPC in your industry.

Read more about PI Planning on our Blog:

5 Things to Know Before Your First PI Planning

The Synergistic Nature of PI Objectives

Pitching PI Objectives to the Sharks

Dec 1, 2021

Length: 9min. 03sec

Leadership fads come and go, but Agile has endured beyond fads and has become the de facto standard for how value gets delivered and how work gets done. In Episode 1 of this video series, ICON Coach, Dan James, gives an executive summary of the reasons competitive organizations seek to transform to Agile values, principles, and practices. This video series will help you build leadership support and allow leaders to recognize the ROI that follows a transformation.

Take our 3-minute survey to see if your team is ready
for an Agile Transformation

Dec 1, 2021

Length: 16min. 01sec

In Episode 2 of this video series, ICON Coach, Dan James, cuts to the chase on what Agile actually is, which may come as a surprise to many leaders. If your goal is to scale Business Agility throughout your organization, this video will help you understand exactly what you’re scaling. That understanding is the prerequisite to the adoption of any popular framework. This video series will help you build leadership support and allow leaders to recognize the ROI that follows a transformation.

Take our 3-minute survey to see if your team is ready
for an Agile Transformation

Nov 15, 2021

Mental health is another thing that agile leaders need to support. When your team is happy and mentally well, they can increase productivity and improve project outputs. While you don’t need to play therapist, it will help to provide team members tools that can help them manage anxiety and relieve emotional distress. The online resources listed below can empower employees to take care of their mental wellbeing.

Psycom Quizzes

Psycom.net provides online self-evaluation tools for common mental health disorders such as depression, generalized anxiety disorder, bipolar disorders, and substance abuse. Though the results of these quizzes cannot be used in place of a clinical diagnosis, they can help individuals recognize problem points and determine whether further assessment is necessary. This way, the team gets to detect issues before they get too severe. Additionally, the website provides resources for mental health support, such as fact sheets, articles, and self-help guides.

Radical Acceptance

Self-evaluation and improvement is a key part of agile project management, as stated by the twelfth principle of the agile manifesto. However, self-evaluation can become unproductive when it turns into excessive self-criticism. Agile team members can learn to overcome their self-judgments by studying the concepts taught in Radical Acceptance – Embracing Your Life With The Heart of a Buddha. Here, famous psychologist and spiritual teacher Tara Brach gives readers stories and guided meditations that can help them develop the self-compassion needed to overcome shame. The book is available in both e-book and audiobook form.

Headspace

Meditation helps teams become more mindful and focused, which, in turn, helps them adapt to industry changes quicker. In the e-book The Headspace Guide to Meditation and Mindfulness, former Buddhist monk Andy Puddicombe unravels the science behind meditation. The resource contains a wide variety of meditative exercises readers can use to cope with different emotions, such as stress and anger.

Additionally, readers can try Andy Puddicombe’s Headspace mobile app to gain access to a comprehensive library of meditative exercises. Because most meditations last less than a minute, agile team members can easily work Headspace exercises into their work routines. Doing these exercises consistently can help agile team members improve every aspect of their minds, including work productivity, concentration, and stress relief.

Youper

Chatbot app Youper uses AI technology to put mental health management right at the user’s fingertips. When users open Youper, they’re led to a chatroom, where they’re encouraged to share their thoughts and their current emotional state. Then, Youper analyzes the data the user offers and prescribes appropriate treatments, ranging from cognitive behavioral therapy techniques to breathing exercises.

The app also contains a journal log that users can use to record thoughts and emotions, and additional screening tools that help identify risk factors for depression, anxiety, bipolar disorder, and other mental health issues. These additional tools can help users track their progress when it comes to mental health. According to Dr. Jose Hamilton, the creator of Youper, 80% of Youper users report a decrease in negative moods after talking to the AI.

Agile team members are the backbone of any product development project. By providing them with the resources they need to protect their mental wellbeing, agile team members can reduce stress, improve concentration, and increase efficiency for agile projects.

Sept 23, 2021

Here are some of the most common Agile terms used in the industry. But remember, being Agile requires a lot more than just common terms. It is a shift in culture and mindset for most companies which requires guidance from someone who has made that shift. So, get help from an ICON Coach or mentor who has experience making the Agile transition to ensure success in your own.

Agile Lexicon / Glossary

Acceptance Test

An acceptance test confirms that a story is complete by matching a user action scenario with a desired outcome. In other words, does the delivered solution meet the customer/user expectations? Acceptance testing is also called beta testing, application testing, and end user testing.

Agile Retrospective

In Scrum, the second half of the  Sprint Review Meeting is a retrospective for the Scrum team that is led by the ScrumMaster. The team assesses the way they worked together in the sprint and identifies positive ways of working together that can be encouraged as future practice. The team also identifies the things that could work better and develops strategies for improvement.

Agile Software Development

Agile software development is a methodology for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product. Agile software development focuses on keeping code simple, testing often, getting frequent customer/user feedback, and delivering functional bits of the application as soon as they are ready.

Burndown Chart

The burndown chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress.

Customer

In agile software development, a customer is a person with an understanding of both the business needs and operational constraints for a project. The customer provides guidance during development on what priorities should be emphasized. (Called a Product Owner in Scrum.)

Daily Scrum

Each day the ScrumMaster facilitates a fifteen-minute meeting designed to clarify the state of the Scrum. Each team member speaks to three questions: what did I do yesterday, what did I do today, and what impediments got in my way? While anyone can attend this meeting, only team members who have committed to deliver work to the Scrum are allowed to speak. The goal is to share the state of the work, discover any new dependencies, address any personal needs of committed individuals, and adjust the work plan in real time to the needs of the day.

Iteration

An iteration is a single development cycle, usually measured as one week or two weeks. An iteration may also be defined as the elapsed time between iteration planning sessions. (Called a Sprint in Scrum.)

Planning Board

A planning board is used to track the progress of an agile development project. After iteration planning, stories are written on cards and pinned up in priority order on a planning board located in the development area. Development progress is marked on story cards during the week and reviewed daily. (Also called a Team or Kanban Board.)

Planning Game (XP) or Planning Poker (Scrum)

A planning game is a meeting attended by both IT and business teams that is focused on choosing stories for a release or iteration. Story selection is based upon the stories that will provide the most business value and the estimate of development effort provided by the team.

Product Backlog

The product backlog is a high-level document for the entire project. It contains product backlog items: broad descriptions of all required features, wish-list items, etc. It is the “What” that will be built. It contains rough estimates, of both business value and development effort.

Product Owner

The Product Owner is a Scrum role that represents the voice of the customer. They ensure that the Scrum Team works with the right things from a business perspective. The Product Owner writes User Stories, prioritizes them, and then places them in the Product Backlog.

Release

A release is a deployable software package that is culmination of one or more iterations of development.

Release Plan

A release plan is an evolving flowchart that describes which features will be delivered in upcoming releases. Each story in a release plan has a rough size estimate associated with it.

Scrum

An agile method proposed by Ken Schwaber and Jeff Sutherland. Scrum is an agile, lightweight process that can be used to manage and control software and product development. Wrapping existing engineering practices, including XP, Scrum generates the benefits of agile development with the advantages of a simple implementation.

ScrumMaster

Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended.

Sprint

“Sprint” is the Scrum term for “iteration,” a time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.

Sprint Backlog

The sprint backlog contains information about how the team is going to implement the requirements for the upcoming sprint. User stories represent what the customer/user wants, and Tasks are used to break stories into actions focused on how to deliver each story.

Sprint Planning Meeting

A Sprint Planning Meeting is used to develop a common understanding of the desired work plan at the beginning of an iteration. The team decides how much work it can successfully take into the sprint based on team size, available hours, and level of team productivity.

Sprint Review Meeting

At the end of a sprint, a Sprint Review Meeting is held. This meeting is time-boxed to a maximum of four hours. The first half of the meeting is set aside to demonstrate to the Product Owner the potentially shippable code that has been developed during the Sprint. The second half of the Sprint Review Meeting is a  retrospective for the Scrum team that is led by the ScrumMaster.

Spike

A spike is a story that cannot be estimated until a development team runs a time-boxed investigation. The goal of a spike is to gain enough knowledge to understand if/how a user story may be delivered. The output of a spike story is an estimate for the original story.

Stand-up

A stand-up is a daily progress meeting, traditionally held within a development area. Business customers may attend for the purpose of gathering information. The term “standup” is derived from the way it is run all attendees must remain standing to keep it short and the team engaged. (Called a  Daily Scrum in Scrum.)

Story / User Story

A story is a particular business need assigned to the software development team. Stories must be broken down into small enough components that they may be delivered in a single development iteration.

Team

The team has the responsibility to deliver the product. A small team of 5-9 people with cross- functional skills (designer, developer, tester, etc.) work together to design, develop, and test user stories in the iteration backlog.

Timebox

A timebox is a defined period of time during which a story or task must be accomplished. Timeboxes are commonly used in agile software development to manage software development risk. Development teams are repeatedly tasked with producing a releasable improvement to software, timeboxed to a specific number of weeks.

Velocity

Velocity is the number of story points used as a guide for planning the next iteration of a development project. Velocity is based on measurements taken during previous iteration cycles. Velocity is calculated by averaging the original point estimates of the stories that were successfully delivered in the previous 3-5 iterations.

Here are links to some other examples of Agile glossaries:

• https://www.scaledagileframework.com/glossary/
• https://www.agilealliance.org/agile101/agile-glossary/
• https://www.scrum.org/resources/scrum-glossary

---

Looking for guidance in your Agile Transformation? For nearly 3 decades, our experienced coaches have mentored clients in their digital transformations.