Uncategorized

Your organization doesn’t have a change problem. It has an experience problem.

chriswmoodyLeave a comment

Most transformation efforts focus on processes and tools. Culture change actually starts somewhere else entirely.

I was first introduced to the change pyramid in 2013, and it fundamentally shifted how I think about organizational transformation. The idea is deceptively simple: if you want to change culture, you can’t start with culture. You have to start with experiences.

What people experience shapes their beliefs. What they believe drives their behavior. Enough changed behavior, over time, becomes culture. This sequence is non-negotiable — and it’s exactly why so many transformation efforts fail. They start with process change and wonder why the culture doesn’t follow.

Article content

I’ve seen this play out in organizations of every size. Leaders invest heavily in new frameworks, tools, and playbooks. They announce the change. They train people. And then they wait for hearts and minds to follow. They rarely do — at least not through that path.

The approach I keep coming back to — across teams, programs, and enterprise-wide efforts — is what I call an Experimentation Framework. The psychological mechanic underneath it is what makes it work:

The experimentation framework

  1. Identify the opportunity. Name the specific friction point or growth area — not a vague goal, a concrete one.
  2. Build an actionable hypothesis. “We believe that if we try X, we will see Y.”
  3. Quantify how you will measure success. Define what “working” looks like before you start — not after.
  4. Set a timebox. A defined end creates safety. People try harder when they know they can revert.
  5. Measure the results. Honestly. Without predetermined conclusions.
  6. Accept, reject, or pivot. This is the most important step most organizations skip entirely.
Article content
The Experiment Framework

What makes this different from just “running a pilot” is the setup. When you present someone with a process change, resistance often follows — especially if their existing experiences don’t align with what’s being proposed. But when you frame the same idea as an experiment with a timebox and a real exit ramp, something shifts. The permanence factor disappears. People are willing to try things they’d otherwise push back on when they don’t feel trapped by the outcome.

Experiments also activate a growth mindset in a way mandates never can. When someone is a participant in the problem-solving process — not just a recipient of a change initiative — they become a stakeholder in the outcome. That’s a fundamentally different relationship to have with the work.

How an experience changed my own beliefs

I was leading a transformation effort at a large online retailer. The organization had a proven model they’d used across hundreds of teams — training, role adoption, change management, hands-on coaching — and for most groups, it worked reasonably well. I was tasked with bringing the last holdout group into the fold: the data science organization.

Day one, I walked into a room of PhDs who immediately started asking questions I wasn’t fully prepared for. Do you have empirical data showing why this approach prevents the problems you’re describing? What’s the evidence that this method is better than what we’re doing now? These weren’t hostile questions — they were the natural language of people who live and breathe data. But our standard playbook had no good answers for them.

I went back to my director and said: I don’t think our cookie-cutter approach is going to work here. And that’s when it clicked for me. These were people who ran experiments for a living. The way to work with this group wasn’t to bring them a solution — it was to bring them a framework they already trusted.

Instead of presenting a change plan, I ran workshops to surface the challenges they were actually experiencing. What’s getting in the way of doing your best work? What have you tried? What’s worked and what hasn’t? We used voting exercises to prioritize the themes that resonated most across the department. Then, rather than prescribing solutions, I crowdsourced their participation in designing experiments — framing each one with a clear hypothesis, defined success criteria, an agreed-upon timeline, and an intentional plan to measure results.

The results were mind-blowing. This group went from high resistance and deep skepticism to high adoption and high value — faster than any group I’d worked with using the standard model.

What made it work was that they could feel real problems getting better. Problems from their actual day-to-day work, not abstract transformation objectives handed down from leadership. Getting better meant they could do more of what they loved — the data science work — with more clarity and less friction. As a change leader, I was able to weave the enterprise transformation goals into the bottom-up challenges they had identified themselves. They were onboard because they owned it.

The moment that still sticks with me: members of that team eventually stood up at an all-hands and spoke about the impact the transformation initiative had on their work. Voluntarily. Enthusiastically. It doesn’t get better than that — and it happened because they built new experiences, not because we handed them a new process.

This is why the framework matters — and why it maps so directly back to the change pyramid. Culture didn’t change in that group because we trained them on something new. It changed because they experienced something better. The experiment was the vehicle. The experience was the point.

This is way too relevant to the AI space

This brings me to what’s happening with AI right now.

The pattern I’m seeing in AI adoption is almost identical to every major transformation wave I’ve lived through. Organizations deploy tools. They train people. They wait. They wonder why adoption is stalling, why teams are reverting to old behaviors, and why the ROI isn’t materializing. In most cases, AI is being treated as a technology deployment problem when it’s actually a culture change problem.

The organizations achieving meaningful AI adoption share a common thread: they’re not just giving people tools — they’re engineering the experiences that make people want to use them.

An experimentation approach reframes the whole effort. Instead of “we are rolling out AI tools,” the question becomes: what’s one thing we could try, for four weeks, with a clear hypothesis and a way to measure whether it’s working? That question is far easier for a skeptical team to engage with. And when the experiment works — when someone experiences firsthand that AI made their work faster, clearer, or more impactful — that experience does the culture-change work that no mandate ever could.

Some key learnings

A few things I’ve learned about running these well:

  • The hypothesis matters more than the tool. Don’t start with “let’s try this AI feature.” Start with a real friction point, and then ask whether AI could reduce it. The specificity of the problem determines the quality of the experiment.
  • The “reject” option has to be real. If there’s no genuine possibility of reverting, you’ve built a disguised rollout. People will know the difference, and you’ll lose the trust that makes the next experiment possible.
  • Celebrate the learning, not just the wins. Some of the most valuable experiments I’ve run are ones where we proved an assumption wrong. That’s data. That’s progress. A team willing to call a failed experiment a learning moment has already done the cultural work that makes transformation possible.

The organizations I’ve watched successfully navigate large-scale transformation — in agile adoption, in operating model redesign, in AI integration — stopped trying to change culture directly and started engineering the experiences that let culture change itself.

That’s still the most reliable path I know.

What’s one experiment your team could run in the next 30 days? I’d love to hear what you’re working on.

Change The Culture, Change The Game

chriswmoodyLeave a comment

I was first exposed to the change pyramid in 2013 and still think of it often. I’ve had a fascination with how people interact with change and what makes it succeed or fail. I firmly believe that organizational change approaches for Agile transformations (or any effort) need to be flexible and responsive while allowing stakeholders, change agents, and change participants to pragmatically start from where they are. Many organizations want to change the culture. That’s a step in the right direction—getting warmer! But they focus on processes—getting colder. Processes are dynamic and change often. Culture is a behemoth that can outlast the cleverest of tactics.

In 2014, I spoke at the Global Scrum Gathering about the concept outlined in this pyramid. In essence, if you want to change the culture, you have to start by creating new experiences. What people experience builds their belief system (hot pan = ouch). Someone’s beliefs determine how they will act (hot pan = ouch = don’t touch). The sum of a group’s, department’s, or organization’s actions establishes a culture. So, rather than focusing on changing processes, which can result in severe resistance, try to create new experiences for employees. Demonstrate to them that they are capable of achieving something new. Help them connect the dots on how an iterative approach could help solve their most pressing problems. The result of the session at the Scrum Gathering was a packed room with attendees standing along the back and side walls. We were met with a standing ovation, which completely took me off guard, but it made me realize that we might be onto something.

Therefore, I now approach change through an Agile Experimentation Framework. I’ve found that this framework can be applied from a single team up to an enterprise. The Agile Experimentation Framework is simply this:

  • Identify the opportunity
  • Build an actionable hypothesis
  • Quantify how you will measure success
  • Set a timebox
  • Measure the results
  • Accept, reject, or pivot on the results.

How does this relate to the change pyramid, though? Actionable experiments tap into an employee’s growth mindset by making them a part of the problem-solving process. Presenting an employee with a process change has a much higher likelihood of being met with resistance if their experiences and beliefs don’t align with what is being proposed. Approaching it as an experiment can relieve apprehension for someone who is not open or aligned with a process change. Setting a timebox and measures for the experiment affords a legitimate option to “revert” or to keep inspecting and adapting with precision.

I believe that establishing an experimentation framework is an effective way to accelerate work culture advancement that will support visionary ways of working.

Team Roles Visualization Exercise

chriswmoody1 Comment

When working with a new agile team or when a role like the Product Owner or the Scrum Master changes, I’ve found that it is prudent to visualize the specific team responsibilities. If the majority of the team has a basic understanding of the role of Product Owner and Scrum Master this method could be especially useful. Much more so than the alternative of teaching the group about generic guidelines and hoping they figure it out. (However, as a facilitator you should coach the group on which responsibilities could be ideal for thier role-based “standard” agile practices.)  Another factor for Scrum centric organizations is that the Scrum Guide doesn’t have details about managers, so this is a good opportunity to codify that for your team(s). 

I’ve used this method to help out dozens of teams, and it typically aids in sorting out if everyone is doing the right things, and allows for grey areas to be accounted for.

Team Roles Visualization Exercise
Timebox: (30min for established teams, 60min for new teams)
Purpose: Bring clarity and alignment for the roles on an agile team.

  1. On a whiteboard draw out columns for the core roles for the team (PO, SM, Devs, Mgr, etc)
  2. Have each individual in that role write in the various responsibilities, processes, and even meetings they feel they’re responsible for.
  3. You now have an inventory of likely most of the things that comprise the teams rhythm of operation. As a facilitator/coach, write down any gaps you are seeing.
  4. Now go through each column and make sure the group is aligned, or if certain things should be moved to a different person. Also, help ensure the gaps you may have written down are addressed.
  5. Document the results with a picture or transcribe to a document that can be posted on your team portal.
  6. It’s suggested to distribute the results to the entire team.

For brand new teams or for teams that do not have an agile background, this similar exercise may be another option to help nudge along this activity.  Scrum Roles and Responsibilities Game

Tips for an awesome daily standup

chriswmoodyLeave a comment

1lf1r4

If you are a part of an agile team, you probably are doing daily standups (daily scrum), right?  As many things in life go, repetition can cause something to be less and less enjoyable, even to the point of dread. If the grind of the 3 questions (what did you do yesterday, today, and what are your blockers?) has got you down, here are some tips to optimize your daily standups.

1.) Start on time – Even if everyone is not there on time.  This may seem counter-productive, but who wants to wait around every day for 2-5 min while people wander in with their Starbucks or like to take a bathroom break every day before standup?  If you consistently start on time, people will get the hint that they need to be on time or will always be late.  Also, This rewards those who tend to be on time more often than not.  If you really want to have fun with it, start a standup tip jar.  every minute late you have to throw in a dollar to pay for the team’s beer run. 🙂

2.) Standup – There is a temptation to walk into a room, put down and open up your laptop, and settle in with a warm beverage.  This is a sure fire way to drag out your standups. By standing up people are slightly less cozy and more apt to get down to business and move on with their day.

3.) Do not turn standup into a status reporting session – In my opinion, the standup should be more focused on the plan forward than going over what took place in the past. There is often value to sharing what you’ve done if it helps share knowledge and communicate that you’ve completed something.  I always try to go by the 80/20 rule for standups. Let me explain: Only 20% focused on the past and 80% of your update focused on the present and future. another way of saying it is to spend 80% of your time discussing your plan forward and any impediments in your way. the #1 problem I’ve observed with most standups is that they spend 80% of their time on question 1 which erodes the intent on the standup.

4.) Be inclusive of remote team members – This could be a completely separate blog post, but here a few of the most important suggestions I can make.  First, use video if at all humanly possible. You lose so much in translation without seeing someone’s face. Next, consider having someone at the location where the team is mostly co-located be on point to making sure the remote folks are considered.  I’ve worked on many distributed team, and it’s very challenging to keep them in mind unless you are intentional about it. This article from Leading Agile has more great tips.

5.) Utilize a parking lot – if you or your team has a challenge with going deep into solutions at standup, it’s probably time to start using a parking lot.  Or as I’ve heard some people dub it, “The after party”.  If a conversation has gone too far into the weeds someone should propose it get’s added to the parking lot.  Quickly write it down on a sticky note, etc.  Then after everyone has given their update have the folks who need to keep discussing the parking lot item stick around.  I’ve worked with some coaches/scrum masters who are very legalistic about the parking lot. I say, use common sense.  If the team wanders into the weeds once and a while it’s fine, don’t shut it down.  But at the same time, you don’t want 7 team members that don’t need to be involved to have to sit through a conversation that could be had by 2-3 people.

6.) Streamline standup with other agile events if possible – Here is an example: You have a two-hour backlog grooming session from 1PM, then standup at 4PM.  Do you really want the team to go back to their desk to try to work for an hour, then go to standup?  I sure hope not, because context switching is costly and to be taken seriously!  The team should think ahead to try to minimize this context switching when possible.

7.) End on time or early – For a team for 6-12 I highly suggest going NO longer than 15 minutes for standup. And as we know tasks often expand to the time allocated.  This is why it is important to keep the conversation moving so you can finish early or on time, every time.

8.) Try mixing up the format once and a while – I was on a team once that did “third person Thursdays” where you had to give your entire update in the 3rd person.  It still accomplished the goal of standup but it was a fun way to mix things up. Another thing you could try is have team members attempt to give an update for the person standing next to them based on what you think they did and are going to do.  This method is slightly less productive but still fun. If your standup is in the morning, try surprising them with donuts or gourmet coffee once and a while.  Another thing you could do is a brief quiz at the end of standup. “What did Suzie say she was blocked on?” The first person to answer get’s a $5 Starbucks gift card.  I think you get my drift…mix it up!

I’d love to hear your ideas and experiences on how to make standups rock, and keep them from sucking!

The Great Delivery Debate

chriswmoody3 Comments

AAEAAQAAAAAAAAJNAAAAJDgyMGI1ZDczLTAwYTAtNDA4YS1iNGM1LWYwZGUyN2JiODE1Mg

Dr. Winston Royce first described a model for working with large software systems in 1970, which we’ve grown to know as “Waterfall”.  Interestingly enough what many never read in his writings on SW development, is the following quote: “I believe in this concept, but the implementation described above is risky and invites failure.” (Source: Dr. Winston Royce. Proceedings, IEEE WESCON, August 1970)  Why could he have said this? Could it be that many times requirements are emergent? Perhaps it’s that estimating large and complex bodies of work based on a requirements document can be incredibly inaccurate?

While I have a large bias towards Agile methodologies, as a consultant it’s my responsibility to evaluate what truly is the best solution for a client.  I was recently on a project in a marketing organization, and while there certainly were some opportunities for Agile principles to be utilized, a framework like Scrum or Kanban just would not have been possible. I’ve heard some waterfall purists sum agile up to a bunch of people who want to get out of documentation and commitments to timelines.  Ouch.  But I also hear a lot of criticism from agile truthers about anyone who leverages waterfall as being clueless and archaic. Can’t we all just get along?  Yeah, we can actually.  But we have to start to recognize that Agile and Waterfall have value in different ways.

I’d love to have some discussion about what is seemingly a great divide between Agile and Waterfall methodologies. To help those in each “camp” understand why a specific method has value towards solving their business problems. What are some examples where you think a Waterfall process was truly the best solution for a project?  What were some of the identifiers you had to come to that conclusion? Have you had success with using a “ScrumerFall” model where the Requirements, and design is all done up front, but Execution is done in sprints?

Do You Lean Coffee?

chriswmoody1 Comment

Have you ever used the Lean Coffee format for a meeting?   It’s a tool I’ve been so pleased to use in a variety of formats in recent years.  I’ve used it for governance meetings, team retrospectives, and open agenda meetings where there is no pre-existing agenda other than to do Lean Coffee.

What is the Lean Coffee format?

The following content is copied from http://leancoffee.org/  “Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated.”

1. Set up a Personal Kanban

Simple Personal Kanban for Lean Coffee

In this Personal Kanban we have the items to discuss, what we are currently discussing, and the discussed columns.

This provides a structure for the conversation. Next we populate it

2. What to Discuss

A Populated Backlog for the Personal Kanban

People all get pads of post-it notes and a pen. They then start to add their topics for conversation into the “to discuss” column. These can be literally whatever people want to discuss or follow a theme. Right now, we want to encourage as many unique ideas as we can.

When the ideas start reach a certain point (an you’ll be the best judge of when that is), each topic gets a 1 to 2 sentence introduction. This way people know what to vote for.

3. Vote and Talk

Stockholm Late Night Lean Coffee

Each participant gets two votes. You can vote twice for the same thing or for two different topics. Simple put a dot on the sticky you are interested in. Tally the dots. Then you are ready to have a conversation.

The power here is that you now have a list of topics everyone at the table is interested in and is motivated to discuss for real.

End of content from leancoffee.org website.

Some benefits of using the Lean Coffee format:

  1. It’s highly collaborative!
  2. It supports the discipline of being a self organizing team.
  3. It helps to crowd-source the agenda. People have skin in the game because they got to vote about what is being discussed
  4. Time boxing helps to keep the meeting from getting stale and boring.
  5. The proof is in the pudding. Some of the best conversations I’ve every been a part of have been while using the Lean Coffee format.

Examples of when Lean Coffee may not be the best idea:

  1. You have a very specific agenda that needs to be adhered too.
  2. There’s only 2-3 participants in the meeting.
  3. You are talking with customers or the participants may have never heard of lean coffee.
  4. Your participants are knowingly “anti agile”.
  5. If you know the majority of the participants of the meeting are not typically not inclined to talk in a group. Dominating personalities will control the conversation and others could become bored and find it a waste of time. (with the right coaching this risk could be avoided)

Need more info still?  Here’s a great video showing a sample lean coffee meeting.

“That’s Not Agile”

chriswmoody3 Comments

right_way_and_wrong_way_sign-other_zps8c090af3

If you work in an organization that utilizes one of the many agile methodologies, you have probably heard the statement “that’s not agile”. It could be about a proposed process change, or a critique of an existing way of doing things. It baffles me to no end when people get lost in the weeds about if something they want to try as a team is agile. This is unfortunately very prevalent in Agile Coaches and Scrum Masters who have a lot of experience.  Since agile is an emerging idea that is really starting to catch some momentum, some who have been advocates for a longer period of time can be standoff-ish about how to do things.  This should be a huge red flag, because there are so many variations of agile and not every organization is the same. You can know all the right things, but completely fail at helping a team adopt agile. That is why it is very important to be flexible, and not have a “better than” mindset.  The principles of agile/scrum are meant to be a guide, not a law that must be perfectly adhered to.  I’m not suggesting you should throw all caution to the wind and try any and everything, because “everything’s agile!”  No.  What I am primarily addressing is the way in which this topic is approached.

So, who’s right?  Maybe saying “that’s not agile” can be valid.  Or maybe we’ve lost sight about what agile is all about.  Let’s just take a quick peek at the Agile Manifesto for a refresher on what it’s all about:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

To be brash: If someone tells you “that’s not agile” and it’s something that could enable one of the 4 agile main points of the manifesto, I would seriously question how well they truly understand agile.  And agile by nature is something that I believe will continue to evolve as people uncover better ways of doing things. (sound familiar?)

If your organization is looking for an Agile Coach or Scrum Master or you are just trying to improve your skills in that realm, here are some suggestions for what not to do, and what to do.

  1. Don’t try to impress anyone with your agile credentials.  Do try to identify things that have been successful on similar teams/organizations.
  2. Don’t be preachy when trying to present new ideas.   Do suggest ideas with a humble and flexible attitude.
  3. Don’t rely solely on past experiences of what worked for other teams.  Do spend a lot of time listening to people’s needs an challenges.
  4. Don’t react when people are critical of agile.  Do find a way to tie what people want back to agile principles and show them how they could enable those things.
  5. Don’t press your own agenda.  Do thoroughly understand how you can support management’s vision.
  6. Don’t treat the agile principles as a law.  Do use them as a guide for making continual improvement.
  7. Don’t be too critical of a team’s existing processes. You never know how much hard work they have put into building what’s there. Do make a point to try to build on existing foundations, and position it as an improvement rather than tearing down.
  8. Don’t be too quick to judge what will work best for  a team.  Do ask a lot of sincere questions and follow the breadcrumbs of how things became the way they are.

 

Hopefully the next time you want to say “That’s not agile” you can remember the big picture and help your teams find the very best solution.  What things are important to you as an agile proponent in these regards?  Do you have any good stories to share?

Agile Certifications…What’s The Value?

chriswmoodyLeave a comment

Scrum certs

Last week I attended an agile training seminar for the Certified Scrum Master (CSM) certification. It got me thinking about what is really the value of going to an agile training session.  Having already attended the Certified Scrum Product Owner (CSPO) training last year I was curious as to how much I would benefit.  When I attended the CSPO training the trainers take was that you needed to learn almost as much about the scrum master role as you do the product owner to be able to understand better. I have to say I was pleasantly surprised with the amount of new knowledge I walked away with. I’ve noticed that each trainer has had a deep background leading and coaching agile teams, and with that comes different nuggets of wisdom. While the first 1-2 hours were mostly review, after that it seems that each session had a life of its own and had tremendous value.

Do you really need an agile certification to be effective on an agile team?  Technically no. But if you are someone who is looking to make a role transition or have an extensive background in waterfall environments, it could be a great tool and demonstration of your ability to make that transition. Obviously time and experience with agile is more valuable, but if I were going to make a statement in the same format of the agile manifesto it would look something like this “Working experience over training seminars and certifications.  That is, while there is still value in certifications, there is more value in working experience.”

Why should you keep going to training seminars like this? For me I realized that when you work in an agile organization you can start to get used to the way you are doing things.  And being with a room full of people talking about what they do gives your copious amounts of inspiration for what you are doing. I was furiously writing out sticky notes with ideas for things to try, and now the challenge will be slowly introducing some of those ideas to the team without being “that overly hyped out conference high let’s change everything” guy.

Something else I was pleased with is that after attending the CSM training I was required to take an exam (open book), that required me to prove my knowledge. It didn’t sit right with me that I could attend a 2 day CSPO training and leave with a certification.  The CSM exam was actually pretty challenging, even with the internet at my disposal.  It was a good exercise all in all.