A very merry unplan to me!

As an Agile Coach I need to help my client understand that planning a transformation is not productive use of time so we can collaborate, experiment, inspect and adapt to achieve a successful transformation.

Generally, I am hired to come in and coach delivery teams in how to be Agile so they can deliver things faster and hopefully with better quality. This is actually what the leaders who bring me in say to me. The problem with this approach of course if that Agile is not and never has been about delivering faster. Quality has always been a focus however, so they're only half confused.

If you are applying lean concepts and eliminating waste (not doing things that don't provide value) as well as incorporating other concepts like self-organizing, cross-functional teams; short iterations; and collaborating with the customer to ensure you're on the right path, then it may feel like you're delivering faster. But the reality is, if it takes 6 weeks to code and test a feature it will always take 6 weeks to code and test that feature. It's just that we all know we're doing the right thing because we got the necessary feedback; and hopefully we're delivering it in small increments if possible to continue that feedback loop.

But if other units or groups in your organization are bottlenecks delaying or obstructing the flow of something necessary to those teams, then it doesn't matter how good the plan is or how Agile we're being; we won't achieve the outcome we're looking for in the time our customer needs it.

Although the concept of holistic Agile has been tickling the edges of my consciousness for some time, it's only within the last six months that I started committing time and brain space to figure out what that actually looks like--researching who is doing it and how they made the case. How did they "sell" that to companies and leaders who believe Agile is only for their IT and software development teams? How did they convince those leaders that they might need to change what they do or how they do it in their HR and Finance and Sales and Marketing groups? Were they just lucky?

It's not easy to map this out into a plan, especially with some of the organizations I've worked with in the last 6-8 years. They're really big ships that are actively moving forward with years of momentum pushing them along, and pockets of resistance that are hard to engage since they believe it's all about delivery teams and/or they're 'busy and don't have time.'

But the plan to transform only delivery teams is flawed because it gives us the illusion that this is what will happen, but doesn't take into account what happens when someone quits because they got a bad review even though their team delivered consistently and delighted the customer every time. Why did they get a bad review you ask? Well because outdated business practices say managers can't give everyone glowing reviews; someone has to have a lower ranking or "needs to improve."

The plan doesn't take into account what happens when we can't fill open positions because the HR process takes six months to find the skilled person we need, or Accounting balks at paying more than they believe is warranted or is "industry standard" for the title.

Even a coach can plan how to implement Agile practices and concepts for a client and find on day one or two that the plan is already off track for many reasons--including those mentioned above.

We want our plans to tell us how we will do something and how long it will take but without knowledge of all people and events beforehand (or a crystal ball) that's just not possible. So we start with what we know and continue from there experimenting and reviewing the empirical evidence. At least that's the hope.

This has worked to a certain degree with most of the transformations I've worked on, but the next thing I hear from my clients is how do we measure where we are and/or how well we're doing? Which is a whole other post, and right now I'm pretty consumed with trying to create a plan that isn't a plan but will satisfy the needs of my client today. It's a little Alice Through the Looking Glass; I need to create an unplan.

Let's Make a Meal!

As an Agile Coach I need to find a way to help people practice the concepts I'm teaching in a way that makes it relevant and easy to understand and apply so they can start using those concepts immediately in their daily work.

I wrote about using games to help teach recently and wanted to share a game I created because I think it's so helpful with illustrating the reason we have to work so closely with our customer/product owner and team; and it's relevant to all cultures.

It's essentially a planning session where the team is working on something they are all familiar with and all consume.

I called it "Let's Make a Meal" because I am nothing if not a child of American culture; there once was a television game show called "Let's Make a Deal" and in looking for the link to share I discovered--to my surprise--it's still airing.

Bad puns aside, the game is actually fun and quite good at helping people practice multiple Agile concepts. But don't just take my word for it! Read on...

Let's Make a Meal!

Teams work together to plan an event which includes food. Cards with food names written on them are provided along with other materials: sharpies, post its, pens, and blank paper. The time box is about ~1.5 hours; though it can take up to 2 hours depending on the number of people.

If there are really good conversations happening I'll encourage them to continue just to help drive that message a little deeper into their psyches.

INSTRUCTIONS

• Break group into teams of 5-7 people and select a Product Owner and Scrum Master (2-3 mins)
• The Product Owner decides what the event is (the vision); decides on a menu using the cards provided; the Scrum Master helps the Product Owner get organized and the team listens (5-10 mins)
• The team works with the Product Owner to start writing stories (10-20 mins)
• The team discusses and decides what the Definition of Done is for the event (5-10 mins)
• The team and the Product Owner discuss stories and edit them for clarity and to identify/understand acceptance criteria (30 mins)
• Then the team estimates each item with story points and breaks the stories down into tasks to estimate the time to Done; Product Owner provides clarity as needed (5-10 mins)
• The Scrum Master keeps everyone on track for time; ensuring they keep the game outcome in mind--each team should have:
• an event description; artwork/posters are optional
• a menu
• stories complete with acceptance criteria 
• the definition of done
• total story points and estimated duration
• When all are done each team reads the event description, menu, definition of done, and totals to other teams; if there is time they can possibly share a story or two with acceptance criteria.

The most awesome part of this exercise is seeing the light bulb go on for the people who said at the beginning of the class that they thought there was no value in story writing or planning sessions. 

In the game, these teams spend about an hour and a half planning an imaginary event with food they're not going to eat and they are serious about it. I've seen arguments (albeit good-natured) about how to cook a specific item; that's how serious some people take it.

When I point this out, and ask how they think (hypothetically) the event might have turned out without the discussion and clarification they almost all say something along the lines of "It will be better because we did that."

It turns out there are some people who know how to cook and others who don't. Those who don't make assumptions about the time it takes and what the ingredients might include. There are food items no one has ever heard of and they have to figure out what to do about that; some of them decided for themselves what it was and others Googled them.

There was one team whose Product Owner chose to plan an event for her elderly grandmother and wanted to include a dish that everyone was familiar with but there was a twist; her grandmother always made it a certain way with extra ingredients. 

Her team would have planned to make it the way they knew how if they hadn't discussed it with her. Because although she'd written it in the story and acceptance criteria they just thought she didn't know how to make it; they would have ignored what she wrote.

Then there are the story point estimates and duration estimates. Many times have I heard the claims that story points are a waste of time, or should have time attached to them, or should be "normalized" so everyone understands what they mean across teams.

When the teams in this exercise look around at the differences in the estimates and realizes that each team has widely varied expertise in event planning and catering the penny drops. The sudden realization is sometimes comical, but always electrifying.

I've had very excited students come up to me after the class asking for the game instructions and copies of the food cards so they can share it with their team at work.

What I point out to them at the end is this: we all eat food and we all hold or attend parties but we don't do it exactly the same. Our experiences and knowledge may be similar but are not the same. We all may know what tira misu is but not necessarily what's in it or how to make it. 

We all know what a wedding is but they are culturally vastly different--an American wedding generally lasts about half a day; an Indian wedding can go three days--that's a lot more food and planning.

We have to talk to come to an understanding of what we're doing, when, why and how. This game is a fun way of getting people to see that. 

As a side note, the reality and creativity people bring to this exercise consistently blows me away. It's really their energetic participation that makes it so much fun and resonate so deeply. 

I often tell the students they should take the same energy to their teams and they're often a little sheepish about that, telling me they didn't realize they could.

That is why I'm sharing this with all of you. Because we all should have that kind of fun with our teams... every day.

Blogging and tweeting and Facebook... oy vay!

As an Agile Coach I need to maintain a social media presence so that I can keep up to date on my chosen field, learn from, share and maintain contact with my colleagues, be aware of relevant events, and show up on the radar of potential colleagues/clients.

While trying to keep up with social media personally is usually fun--though can easily turn into a huge time sink--trying to maintain a professional presence while tracking other professionals I admire and/or want to learn from can be daunting.

I want to keep up with the latest in my field and see what others are doing and experiencing and sharing but the beast requires that you feed it as well and that takes a LOT of time. One of the reasons I stopped blogging after nearly a year in the Philippines was because there just wasn't enough time.

Now granted, I was also trying to maintain family and friend relationships with people in the US while creating and nurturing new acquaintances in Manila, learning a new skill (scuba diving) which took me all over the Philippines, and actually work 40 hours per week (not to mention factoring in the traffic and increased travel time for even short distances).

But now that I'm back in the US and things are a little more 'normal' schedule wise, I still find it a large investment of time to maintain social accounts. There's:

• Facebook with family and friends; keeping up with what they're all doing and sharing our lives, photos, personal highs/lows, and political woes. As well as following my agency and other business pages (including my own which is in indefinite hiatus), etc.

• Twitter; a little more personally removed but no less relevant to my life and those aforementioned political woes. I have two Twitter accounts because I thought it would be smart not to share personal feelings/beliefs with my professional world, since for me it equals possible working relationships and clients. But it's more than twice the work; there's the emotional weight of not remembering which account I'm logged into and then deleting tweets sent from the wrong account and resending from the right one. (And I know by doing that I'm not being my whole self with those potential clients and working relationships, but that's a whole other can o' worms. A girl's gotta eat and pay her bills and keep her stress levels down.)

• Instagram; a place where I can follow people I admire or am interested in and share my own updates with family, friends, and complete strangers--which sounds weird, but I find it oddly comforting. That we can all connect over photographs of nature or other shared interests but maintain that distance... like a gallery or museum. Plus, as an amateur photographer it's validating to have people like and comment on my photos.

• LinkedIn; where I want to be more active--I currently check the feed about once a week, 'like' posts and sometimes comment--but feel reticent about say, publishing articles since it's more professional in nature and topics, and my first instinct is I don't have anything new to add, or better or more enlightening to say than others. (Yes, I have impostor syndrome; I'm working on that.)

• Slack; where I am most active--mainly reading what others have posted; though that's great for me. Learning and understanding how other people are viewing the same things I see in our chosen field of work as well as those who are struggling and how they solved for those issues. I do try to participate and share--it's one of my goals toward dispensing with that impostor thought process. But I have six active Slack work spaces; one that I own and maintain.

• My personal blog; which I started thinking it would be about the transformation I was working on in Manila but more often than not blurred into personal posts. I realized that the whole culture shift was just as important as what I was doing as a coach during working hours; because I was working with people in that culture and needed to understand that if I was to understand them. (And now that I'm trying to get back to consistently posting to the blog, I think I should just go with the flow and not try to force it into a mold.)

I generally only use Twitter, LinkedIn and Slack for business, but all of it takes time; not just to read through the feeds and linked articles but to follow up, respond, or post requires thought and sometimes research.

And since it's the nature of the game I try to maintain a steady stream of timely and relevant content--depending on the account--which means looking ahead and scheduling (Hootsuite is great for this), as well as keeping my eyes and ears open for the new and yet unknown, which takes yet more time. It can be a huge mental lift, but can also be mentally exhausting too.

Sometimes I think back to the day when we didn't have this access to each other and to the world at large and wonder if it makes a difference to be so connected and to spend the time. If I stopped doing all of it what would happen? Would it really affect my day to day life and work opportunities?

But then I think about how I feel to see a post from someone across the world who feels the way I do about something and feel connected. A stranger likes a photo I posted on Instagram and maybe comments simply, "That's stunning" and I feel pretty good about that. I see updates from family and friends who live far from me and feel a little closer.

And I know that people have followed me professionally on Twitter because I offer something that most do not. My tweets are usually centered around lifting others up. I didn't set out to do that and didn't even realize I was doing it until I saw the responses I got from those tweets; likes, retweets and follows. I thought my brand was "agile coach" but I think now it's 140 character comments about how awesome others are; especially when said peeps are live. (Though I have no clue what that might be called, in terms of a brand.)

I think its important to stay connected; I think it makes the whole world a better place and feel a little smaller. I think sharing our hopes, photos, wonder, and the feelings those evoke are all good and truthfully Agile. I have said before, and will continue to say, I think Agile is all about humanity.

So for now, I'll carve out an hour or two a day (that's my new target) to read and respond, find new and interesting to share, post my photos, like my family's silliness, write about my professional challenges or thoughts and just generally participate in the sprawling, sometimes chaotic, hubbub.

Telling stories and playing games

As an Agile Coach I need to find a way to help people practice the concepts I'm teaching in a way that makes it relevant and easy to understand and apply so they can start using those concepts immediately in their daily work.

I've trained hundreds of people, spending thousands of hours doing it in three countries over the last 6 years. I learned pretty quickly that training had to be: 1) interactive--because otherwise I lost people after the first 20 minutes of a 4 hour class and really couldn't get them back, 2) culturally relevant--otherwise it made no sense to them; Agile is an easy concept to understand but not to apply, and 3) fun--because that's how you keep them awake and engaged for the other 3 hours and 40 minutes.

I started out using the penny game--and still use it because it's amazing how it makes a connection for people almost immediately and is fun--and some other well known and useful Agile games. (Shout out to Tasty Cupcakes, the best ongoing Agile game repository!). But the aftermath of my classes was that people really couldn't make the connection to working together with their Product Owner on writing stories--let alone write good stories.

I thought about this quite a bit early on and did tons of research and experimentation but many times I was trying something that I didn't fully understand myself or wasn't relevant to my life so my heart wasn't engaged. And I knew this was the case for my students too; I could see it in their faces.

But necessity and all that research and experimentation led me to creating a few great games/tools I use now whenever I have clients who need some practice. Here's one example:

Story Telling

This is a tweak on a game I found somewhere (I honestly can't remember where so if you know please comment and I'll add the attribute) to help illustrate why it's better to have whole knowledge of what you're trying to build and to work together to do it. It's best with at least 5-10 people participating; more people can make it take longer but is no less fun. 

The group selects the story elements together; depending on your group this could be time-consuming if they're all reticent to speak so I call out whatever culturally relevant ideas I can to get things going (Jon Snow or Elsa anyone?)

INSTRUCTIONS

Create a story by speaking only one word at a time. The story must include the following elements:

Story Elements:

• a character (can be a name)
• a household object
• a location

Rules:

• The story must “flow"
• Players can add the words “full stop” to indicate a new sentence (that's their word)
• The story elements the team chose must be used

I usually ask someone in the room to be the recorder so we can read it back at the end; I stress they should only capture each word spoken, not fill in the blanks or edit.

I don't give the group time to confer or allow them to talk while in the game, other than to say their one word each. They invariably try to help one another and I gently dissuade them.

Generally, it takes a few minutes for everyone to warm up and commit to being vulnerable and participate. And the resulting story is nonsense and might include some of the story elements the group chose but many times not all or they're stuck in there as an afterthought to be sure they meet the rules. 

After we laugh about the silly story, I ask the group, would you have created a better story if I told you what I was looking for--for example, a bedtime story, a scary story, a romantic story? 

Inevitably, they say yes, because they had no idea what story they were trying to tell and only piggybacking on whatever they remembered moments before they had to add a word. And not everyone knew the character or was familiar with the location chosen so had little idea how to contribute.

I have had a couple groups, already long time team members, do a passable job of constructing something that made sense but even their stories had no plot and held no interest.

Then, I ask them, if you knew what type of story I wanted AND I gave you time to chat about it would you have created a better story? Again, the answer is yes and a bit louder this time.

Some have told me they're great storytellers and if they have time to think about it they can weave a story that holds rapt little children and adults alike. Others have told me they need a chance to collaborate and talk it through before they tell it; they just can't come up with the idea on their own.

Pride starts to win out over reticence and they want me to know they can do better.

I don't have to tell you what I say next, right? (If I do, contact me and we'll chat.)

I could talk their ears off about how important it is to have the discussion with their team, Product Owner, leaders, etc about what they're creating/building and why, but this simple game--which takes 10-20 minutes depending on the number of people--illustrates it so beautifully and simply I don't have to go that route. They get it and it resonates.

I include other games in my sessions but this is usually the first one we play; I generally use it as an ice breaker as well as a segue into why everyone should care about the stories they're working on and who wrote them and what they actually say. At the first break of the day, the feedback is usually something about how fun it was and how it made them think. 

And that is really all I could ask for from people who give me some of their time. Please think about what we're doing and talking about so you an apply it in your life.

Check out the next post for some other games I use including one I created myself.

Holistic Agile

ho·lis·tic hōˈlistik/ adjective

characterized by comprehension of the parts of something as intimately interconnected and explicable only by reference to the whole.

What do you think scaling means?

Is it okay that only IT and software delivery teams are Agile?

Does it matter if HR and Finance, Sales and Marketing and other business units still do things the way they always have?

The truth is, without change throughout the whole organization it cannot truly be Agile. (Unless it started out that way; kudos to you if your organization did.)

But there is an assumption in many cases that Agile is only for software development teams or IT.

We have to open our minds to the possibilities of Agile and understand it's not a prescriptive set of steps but a different way of looking at things; a different way of doing what we do.

When we talk about scaling many of us think of starting with a pilot team and then scaling to the rest of the teams within the group--that's product delivery scaling--or we think of scaling to other groups within the organization--platform scaling, or we might think of scaling to leadership and helping them become more Agile in their thinking and interactions--vertical scaling.

There are frameworks out there to assist with those types of scaling--LeSS, DaD, SAFe, Nexus, etc. But they're all focused on software development to a certain extent. There is another form of scaling we're starting to hear more about.

Horizontal scaling or scaling outside software. I've heard it called holistic Agile and I like that because it deals with the whole not parts.

Most companies think that Agile is all about the development and delivery of their product and that it doesn't apply to anyone outside the teams delivering that product and maybe internal groups like IT. The truth is Agile is a complete cultural and mind set that must be implemented in all areas for true success and benefits. The great news for everyone is it works. Companies whose names you will recognize have done it and are reaping those benefits.

One example is Gap Inc. They adopted Agile in their HR department because, among other things, they wanted to cut down the time it took from resumes received in house to a candidate being hired. And many times not the best candidate; they were losing the best candidates to other companies, because it took them at minimum anywhere from 10-54 days and with maximum delays anywhere from 31-123 days!

That's a huge problem, especially if you need that person for critical development on a product that must meet a market timeline. It could mean the difference between success and failure for that product and maybe the company. And they're not the only company with this challenge.

The Gap HR team goal was to completely revamp their process and cut down the time it took to screen, interview, and hire a candidate by about 2/3 of the shortest time it took them currently. The amount they accomplished in three months might make your head spin. But that's what happens when you look at what you're doing in a new way.

Because many organizations think about Agile as a prescriptive methodology, they believe they just follow the steps and voila! they will be Agile. 

Just as looking through polarized lenses give you a different perception of color, and certain drawings change when looked at from different angles or by squinting your eyes, Agile helps you view things in a novel way.

Once you look at something through the Agile lens, you'll start seeing things you missed before. Think about those magic eye pictures with the hidden 3D picture. If you slightly unfocus your eyes the hidden picture jumps out at you. What you see completely changes. But the truth is, the thing itself--the picture--hasn't changed; only what we see or how we see it.

There's a reason MBAs predictably fail at the marshmallow challenge while kindergartners best them every time. The years of training to see things a certain way has rendered them unable to do anything else… to see it any other way. Participants in the exercise are given 20 sticks of spaghetti, one yard of rope, one yard of tape, and one marshmallow; then they're asked to build the tallest free-standing structure they can using these items in ~18 minutes. Oh, and the marshmallow must be on top.

The MBAs spend about 30% of the time they're given planning the perfect structure and allocating roles. They end up with a structure about 10 inches tall; the average structure is about 20 inches tall with kindergartners achieving that along with architects and engineers.

How can this be?

Innovation can't be taught. If you're taught that everything can be planned, and must be planned in advance of beginning, you are killing innovation. If innovation is dead then you can't see things in a new way, a new light, or with new eyes. Creativity and innovation are critical for companies to achieve the ability to pivot and change.

Those MBAs aren't stupid people and they might be creative in other areas of their life, but they have been inculcated with the belief that in work the plan is the thing--the plan is right and the plan will get them through. So much so that they spend about 60% of their time implementing the plan they created to build their structure and only at the end do they place the marshmallow at the top… only to watch the whole thing bend or crumble under the weight. They leave themselves little or no time, or thought space, to pivot and try something else. They worked on their plan in a vacuum.

The kindergartners on the other hand build something small and stable with the marshmallow on top in just a few minutes. They play and experiment with the rest of their time. They don't believe there is one right way to accomplish the goal. In the same time it takes the MBAs to build one structure the kindergartners build 4-5 different attempts. They don't know going in what it will look like or what will work but they end up figuring it out.

So what does all this have to do with scaling Agile outside software? Well, executing on a flawed plan is a guarantee of failure. Flawed plans occur when we don't take into account--or even know--all the variables, or more importantly, allow ourselves to experiment.

Innovation is part of the answer. We must believe that innovation is more important than the plan. Because IT IS. Sure, you need a starting point and a shared understanding of where you're headed but innovation isn't about being a fortune teller or seeing the future. It's about figuring it out as you go.

In nearly ten years of experience in Agile environments, I have seen many companies saying they want to "be Agile." They hire coaches and spend money on training to get everyone in software development to be and do and think and act Agile. Many times when they look back a year or two later they are confused about why they aren't experiencing the huge leaps in ROI they expected or seeing droves of customers adopting their offering. Some of them say 'well Agile doesn't work.' Rarely do they say, 'we need to figure out why this didn't work for us.'

When I talk with executives and ask them whether they think they night need to change their approach and look at how they do things in the rest of the company, they tell me 'oh things are working just fine in [insert department here].' The problem is they think they're working just fine because they aren't looking for what isn't working.

One of the things I tell people when I begin coaching them is once you start doing this thing called Agile you will see the things that don't work. They will be illuminated very quickly and clearly. The choice is to acknowledge them and address them… or leave them as is.

So what do you need to scale to the rest of the company? There is no special adjustment or implementation. Make the decision and then do the same thing with those other departments/areas as we do with software development and IT. It's not exactly the same but it's not that different.

We know what one what The Gap did with hiring in HR; the next step would be to start changing how we approach compensation and increases. How do we incent teams rather than individuals? Annual individual reviews create friction because it pits people against one another and that is anathema to Agile teams.

How about Finance? How do we fund teams or products rather than projects? Doing this removes a lot of up front guessing, negotiating, and jostling for supremacy in the money wars, as well as the creative financing on the back end when there is money left in other projects but not the one that we really need to finish and release. If we decide as a company what our highest priority is and everyone knows that and then fund that priority we don't have the problems the current status quo creates.

How about security and networks? Yes, it's absolutely critical to our company health to meet all the regulatory and compliance laws and rules, but we don't have to accept the bottleneck created when the security/network group is inundated and unable to review pending releases. How about we build those reviews into the overall roadmap/timeline and process rather than think of them as an afterthought? Remember when testing used to be the afterthought? Or how about we ensure that we build in the compliance and regulatory items in by adding someone from that group to the team?

The most important thing to do is to focus on building that cohesive, collaborative team feeling with everyone across the organization. Provide safety so everyone feels comfortable sharing their ideas--from the cleaning crew to the c-suite; provide clarity of vision and purpose so everyone knows what is most important to the company and understands their part in making it happen. This will foster a culture where dependability is de rigueur; no one wants to be the bottleneck or considered unreliable.

None of this is rocket science and you may have heard other people talking about these concepts. It's also important to know that you can't wait for someone else. You must step up and advocate for the change.

So if you're an team member, you need to ask the question, "Are we going to implement Agile to other departments outside IT/software development?" Back it up with some data; "There is a 6-week delay while we wait for approval from finance or network/security. If we were all collaborating from the get go we might be able to cut that in half or completely remove it." And you need to push back when you're handed an unrealistic deadline or given 5 number one priority items to work on; use real data as back up because that's what gets leader's attention and response.

If you’re a manager, you need to listen to your teams, look at your group and ask yourself what changes will make a beneficial impact, pull your colleagues together to talk about how you can get started; hold a stand up with them to keep track of how things are going and discover when and where you may need to tweak. Find a mechanism for sharing the impediments you encounter with your leadership so you can get help from them. Talk with your leaders about how you can get faster decisions; maybe outline a new paradigm where some decisions are made without executive input--share those decisions and results in full transparency so we can continue to build the relationships and trust we need to make it work.

If you're an executive, you need to start listening more and working with your people to figure out what should go into the vision and goals and how to make them crystal clear so everyone knows what they are. If deploying the product is the most important thing, then HR must fill the open headcount and Finance must approve the funding and not be bottlenecks. Sometimes that means cutting down the number of initiatives on the roadmap; maybe focusing on 1-2 instead of 5-10. You need to allow room for failure and encourage innovation and make time for both. You also need to learn how Agile really works; you can't cook without a recipe unless you have some experience as a chef.

If you're in Product Management you better be working with the customer every day to be sure what you're giving them is what they need and that the 1-2 items the organization is focusing on are the right things. And when that changes make sure everyone knows so we stop spending time and money on the wrong things.

Agile can be applied everywhere. It can and does work outside software development and IT.

It doesn't happen overnight; however, it does create short term wins while you strive for the long term change.

And this kind of environment creates joy, as Rich Sheridan talks about. Who doesn't want to work in a place filled with joy?

You should get started today looking at things in a new way and helping your organization do that too.