Agile Development Blog

Matt Phillips is a Senior Project Manager who has spent the last few years helping shape the Agile development process at Lulu.com. He currently heads up the Lulu Project Management Office and has spent several months setting up Agile practices in Lulu’s India office, based in Bangalore. In advance of his executive panel discussion at Rally’s Agile Success Tour in Raleigh, NC, we sat down with Matt to ask him 5 questions about Agile.

1. How have you implemented Agile across your organization?

We’ve rolled Agile out among all of our distributed teams, which are located in Raleigh, NC, the Ukraine and India. The time zones have historically been a challenge, so we had our remote teams spend several weeks in the Raleigh office working through daily Scrums. Now, they’re essentially as included in the process as possible. We use video conferencing for daily Scrums and to schedule iteration planning. All the teams collaborate to define stories, determine velocity, and plan iterations. We use Rally to make projections, track our velocity, and get visibility into the health of our projects. The metrics have become indispensible for judging how we’re doing, making accurate projections, and delivering upon our commitments.

2. What was your #1 reason for adopting Agile development?

Lulu adopted Agile at a point where the company was very much in start-up mode. The ideas were coming at a frenetic pace and the engineering team size was poised to expand. Agile methodologies were a good fit for Lulu’s culture and environment. The concepts of short iterations and regular release cycles paired with Scrum provided a quick time-to-market period for new ideas. At the same time, by adopting Agile methodologies, Lulu gained increased insight into the development team’s progress and performance as the team grew and feature sets became more complex.

3. What has been the biggest benefit of adopting Agile?

The metrics and amazing visibility we have into development projects. This is especially important for a team that’s 9,000 miles away. We have visibility into how they’re progressing on features, what’s coming next in the roadmap, and really flushing out what the product backlog looks like and where we’re headed.  Prior to implementing Agile, it was very hard to sync-up  (because of the 9 ½ hour time difference), maintain a feedback loop and foster collaboration with teams so far away.

4. What one piece of advice would you give to new Agile teams?

My advice would be to ease into it – kind of like steering a cruise ship, not turning on a dime. Start with familiar concepts and gradually introduce Agile practices over time. We started with familiar ideas like release dates, associated task lists, estimations, and tracking criteria. Then, we used a phased approach to introduce the concepts of iterations, story points and relative sizing, velocity, and ranking. We continue to work toward more granular inputs to smoothly coordinate roles, tools and dependencies within Rally as we go along to continuously perform at higher levels and get better outputs.

5. How can you tell that Agile is successful at Lulu.com?

One of top ways I can tell that Agile is successful in our organization is that people, even outside of engineering, are speaking in story points. That tells me that Agile has really taken hold. Using story points and velocity for our release planning makes it easy to arrive at a date that everyone is comfortable with. On top of that, our track record since adopting Agile shows that we’ve been delivering on our commitments every time.

Managing the right goals in software development can have a major impact on your team’s success. You get what you measure. In this regard, the goals you choose can be a defining factor in whether your organization’s Agile adoption thrives or dives. So, what are your choices?

A story about goal-setting

Imagine you are a runner. You have a running coach defining targets for you. Your coach chooses miles and seconds in order to measure you. These metrics turn out to be useful; they are universally understood by you, your coach and your competitors. That’s a good thing. A target goal exchange around these metrics might look like the following:

Coach: “I need you to run a 2-minute mile.”

You: “Uh, I’m not sure I can do that. In fact I don’t think it has ever been done before by any land animal other than a wildebeest, a pronghorn antelope or a cheetah. And, I’m not a wildebeest.”

Coach: “You’re not listening. I already told Sports Illustrated you will. Don’t make me look bad.”

You: “Seriously I’m pretty sure that’s just not humanly possible. I’m no Usain Bolt and I’m not sure even he could sustain a 2-minute mile.”

Coach: “Hey, I set the goals. Run that mile in 2 minutes. Just hunker down and work harder. 2-minutes is the target goal. If you don’t meet it, I’m kicking you off the team.”

You: (muttering under your breath to self, “I can’t do it, you aren’t listening to me, and you are a moron. Why do I even bother to open my mouth?”)

Why goals matter

Get the idea? I’ve been reading John Seddon’s Freedom from Command and Control: Rethinking Management for Lean Service. My colleague Alan Atlas recommended the book. Then my manager Ryan Martens became very interested which led to a book appearing on my desk. Soon after, Karl Scotland mentioned it in an informal conversation about Lean and Kanban. Time to pop it to the top of my reading stack!

Seddon sets a context about Purpose driving Measures that then drive Methods. The combination of purpose and measures start to look like goals. And Seddon breaks goals into two types: Target Goals and Capability Goals. While John’s book is not specifically about software, I could see how we use and abuse goals in our software world. So I decided to delve deeper.

Target goals are arbitrary and doom-laden

Target goals are set to measure hopeful results, often an arbitrary number. Think about our runner story and the 2-minute mile. That target goal was  set by someone else. A target goal typically does not account for your strengths, capabilities , availability and skills. Target goals don’t serve you. They don’t serve organizations either. And yet we cling to them. Consider if, as a developer, I hear the following from my manager:

“Jean! You missed the release deadline we gave you. We told marketing and sales who then told our customers that dev would deliver this specific functionality on this specific date. You’re ruining everything. We’re doomed I tell you, doomed! And all because YOU didn’t hit YOUR deadline.”

Uh, it wasn’t my deadline. And yet, missing that goal is now rippling negatively through the organization. This is a lose-lose situation all due to expectations hinged to an arbitrary target goal.

So why do target goals exist?

In many hierarchical, command-and-control software organizations, target goals are how deadlines are set. As Seddon points out, use of ineffective target goals usually arises due to an impossible purpose coupled with non-value add methods. The measures (or goals) are meant to drive teams to the impossible purpose. A command-and-control organization believes that goals must be set top down. The negative impact of these goals is inextricably woven into unrealistic expectations, death marches, and non-value add methods for controlling the work toward the goals.

Enter the capability goal

Let’s replay the runner scenario again.

Coach: “There is a race coming up, a half marathon. That means we need to start training now. What is your time currently?”

You: “I haven’t been really running lately. Rather than guess my times, I’ll start running now. Do you want to know in terms of how long it takes me to run a mile, or how far I can run in a specific timebox?”

Coach: “Let’s start with how you finish a mile. What is your typical way of getting going?”

You: “First, I do a walk/run combination. Then I can give you my actual mile capability in a week.”

Coach: “Okay, let’s set up a plan and together set some sort of goals based on your capabilities. That will help me guide you and figure out when we are faltering. I know you can do this. I’m going to work with you starting right now.”

You: (muttering under your breath, “This is amazing; yea me! I am going to finally put my passion for running to work, keep improving, and run my first half marathon. I love my coach!)

Capability goals are based on real data

Together, the runner and the coach watch the capabilities of the runner to define goals. The purpose of the goal is clear. Measures are set up that usefully help determine the runner’s progress. The method (or running regimen) for attaining the goal is then applied. Simple.

We use this same approach in Agile teams. A team lead or project manager does not set an arbitrary target goal. Rather, the Product Owner sets an overall purpose/vision. The Agile lead, often referred to as the ScrumMaster, works with the team to assess what goals can be reached based on a team’s capabilities and availability. From iteration to iteration, the team provides feedback on what it is able to complete based on its capabilities. The Product Owner absorbs this information and sets expectations outside the team. The process of continuous improvement continues. The team declares, “Based on what we tend to complete, and given the purpose from the Product Owner, we are going to improve our methods in the following ways.”

When good capability goals go bad

There’s a Gary Larsen “Far Side” cartoon of an open refrigerator with a bowl of glop inside holding a gun. The caption? “When good potato salad goes bad”.

Unfortunately, I’ve seen good capability goals go bad in a number of organizations. Listen to this conversation:

Program Director: “I see that our Agile teams are all now using these things called story points to track their work.”

Me: “Yes, it’s working well. Each team has a good sense of what it is capable of delivering iteration over iteration. That helps me figure out how to help remove impediments, where bottlenecks are, and where any team may need us to better resource them. It’s great!”

Program Director: “Hmmmm.”

Me: (muttering under my breath: “That ‘Hmmmm’ just doesn’t sound good. I think I’m about to get sick.”)

Program Director: “So, what’s the highest story point commitment a team has made?”

Me: “27.”

Program Director: “Great!  I’m setting 27 points as the target goal for all teams to commit to for each iteration. Every point will represent 3 hours of work. This precision will help me calculate exactly what we’ll deliver when. Plus, I’ll know which teams are really working and which ones are slackers.”

Me: “Hmmmm.”

Program Manager: “So, let’s get out there and commit! This Agile stuff is great!”

Me: (muttering under my breath, “We’re doomed, I tell you doomed!”)

What just happened must not be allowed

As you roll out your organizational Agile adoption, you’ll encounter many challenges. Pay attention to the usefulness of capability goals. Insist on using them.  Non-Agile organizations won’t like this. At times, you may feel like Sisyphus pushing a rock up hill for all eternity. Be strong. Don’t allow Agile measurement abuse. Create team and organizational trust.  Remove target goals and embrace the incredible value of capability goals. And, don’t allow any backslide. Don’t let your capability goals devolve slowly into target goals in sheep’s clothing.

You: (muttering under your breath, “You know? This MAY just work. Capability goals versus target goals. For the sake of my team, our organization, and the value we deliver to our customers, I’m going to do it!”)

Yesterday Forrester Research, Inc. issued the most comprehensive, independent analysis of the Agile development tools market and 10 Agile ALM providers.

The Forrester Wave: Agile Development Management Tools, Q2 2010

Here are some highlights but what I really recommend is that you read the report titled “The Forrester Wave™: Agile Development Management Tools, Q2, 2010, Forrester Research, Inc., May, 2010″ 

• The report says, “Rally offers the best combination of capability and strategy.”
• It goes on to say Rally “has a strong services group with lots of experience around enterprise Agile adoption, benchmarking and assessment.”
• Thanks to Forrester’s deep analysis, there is a lot of other great information on Agile adoption (currently at 35%) and where this market is headed.

See the full report for details.

For me, this is a culmination of 6 years of hard work building a great product, roughly 32 product releases (that’s just on our core ALM product),  countless demos to our now 96,000 users to get the features right, and the company evolving from just me to 165 phenomenal team members at Rally. Wow, I am a proud Rally-er today.

Last week, 10 of us from Rally product development, sales and coaching attended the Lean Software and Systems Consortium’s 2010 conference in Atlanta.  For me, the learning highlights of the conference were in the Systems Engineering track  led by James Sutton. To kick-off his talk on Lean Systems Engineering, James used a number of compelling stories around different systems and what guide them.  As part of his introduction to systems, he played this hilarious Dave Snowden video about how you plan or act based on one of 3 systems in which you might find yourself -- Chaotic, Ordered and Complex.

David Snowden -- Cognitive-Edge -- Ways to Plan a Party

James, a Systems Engineer, Principal with Lockheed Martin, is an invested member of the Lean SSC board as well as a technical advisory member.  He is the deepest expert that I have ever met in the field of systems engineering. And he has a wonderful gift for bringing multiple resources to bear in helping people understand and care about systems. For a Civil Engineer and Computer Science major like myself his talk and track were the definition of a prop-spinning geek nirvana.

Systems are guided by the pressures that form them

The point of view that James imparted on us was to understand that there are fundamental systems in which we operate. They are not value-based; one is not better than the other. They just help us set context and inform us about the world around us. Why should we care about this? How you approach your product and project development depends on which system  you find yourself in. And, as it turns out, the system you find yourself in is largely guided by one of four compelling pressures. That is, you will recognize the system in which you operate based on what is driving you to act.

There are four fundamental pressures that guide us: abundance, scarcity, desperation, or conformity. And each leads to a different system context. To illustrate this, James led us through the story of four different nations following the second World War.  Each nation, responding to different drivers, led to advances in different types of systems management approaches in use today.

• United States -- Abundance -- Systems Engineering

• Japan -- Scarcity -- Lean

• England -- Desperation -- Chaos Theory

• USSR -- Creativity and Conformity -- Patterns of Inventiveness
  

The Four Systems

Given this sense of what guides particular systems, James explained that we live in a world of four fundamental systems: Simple, Complicated, Complex, Chaos.

Cynefin

Once you recognize what system you are in, you discover what principles and practices will best serve you in that system. But systems tend to not be static. So, James presented what agent or pressure might cause you to move to a different system and therefore what tools and practices would guide your thinking and actions for transition.

For instance,  if you are in a Simple system and are moving into a Complicated system, Lean Manufacturing and Analytical Systems Engineering are your best tools and guides. If, however, you are in a Complex system verging on Chaos, you’ll work best relying on the perspective originated by Dave Snowden: Cynefin, the Welsh word for “the place where you hold multiple things.” Cynefin serves Complex systems well as it emphasizes emergent behaviors and, what Snowden refers to as “sense-making.”

The history and vision from this talk became almost a grand unifying theory for me. It all made great sense. If you are a  systems engineering fan, do not miss the recorded version of this talk when it becomes available.

Thanks Lean SSC

While 6 speakers and several attendees from Europe were prevented from attending the conference due to the Icelandic volcanic ash cloud, the Lean SSC rolled with the punches and pulled off an excellent event. The folks able to attend and the over 40 sessions offered created an electric buzz both in the air and on Twitter. Given the caliber of sessions, hallway discussions, and Open Space,  I am sure there will be many posts that emanate from attendees. And no doubt new ideas will be growing that were nurtured by the conference. Kudo’s to the Lean SSC board for creating a space for this excitement and emergence.

About the Authors:

For 2010, lets find ways to focus on teaching our craft and growing the world of skilled software development professionals instead of trying to figure out who is “right.”

I believe much of the “Escalation” that Jean is seeing was correctly titled by Regina Mullen as a battle to be “right.” (see and read Escalation is Killing Agile – Can We Please Stop It? and Escalation is Killing our Healthy Conflict in Agile). That behavior focuses on carving up the pie instead of growing the pie.   There has been so much added to the field of software development methods, tools and techniques from the guiding ideas of Agile.  Now is not the time to stop and eat.

For me, 2010 is about continuing to grow the Agile software development pie’s reach and innovations.

I believe one of the key fixes to the problem of escalation can be found through increased professionalism and certification in Agile. By raising the bar through “difficult and skills-based certification,” as Brian Marick and the board at the Agile Alliance described, we can advance the Agile discourse through :

• a defined a bar that is deep in skill, knowledge and practice
• a significant enough bar to engage College and University study and examination
• research and curriculum that explore the tough questions in a scientific method
• development of more flexible or “T” shaped individuals that can see and work beyond silo roles.

With this back-drop, I am motivated by the notion of creating a  A Community of Thinkers,:

I am a member of a community of thinkers and I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

A Community of Thinkers creates more leadership in our profession. I see the expanding certification efforts in 2010 as great steps in these directions:

• Lean Software and System Professional – new certification emerging
• Agile Developer Certification – that is also emerging
• Certified Scrum Practitioner – especially as it intertwines with the PMI’s Agile Community of Practice

I encourage everyone in our community to figure out how to put energy toward one or more of these efforts.  The benefit of actively learning, teaching and reflecting on our work should lead us all to expanding civil dialogue that works to understand all points of view and keep expanding our thinking.  Thus broader education and difficult certification helps create a “Community of Thinkers.”  And, a Community of Thinkers will create a virtuous cycle of win/win and thus a larger pie for all.

That is my hope for 2010 in our profession.

About the Author: Ryan Martens is a happy father,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

It has come to my attention that there are two software development approaches hanging around the water cooler these days, one of which is inaptly yclept (I’ve been waiting most of my life to use that phrase!).

The first approach is called Waterfall and the other, called Agile, has a name that I think is all wrong. If Agile is the opposite of Waterfall, then I think it should be called Pond. Yes, Pond. To understand why, let’s first think about what a Waterfall project is like:

In this metaphor, the Waterfall project will be represented by the activity of riding a boat over a … do I see any hands? … no?… ok then, I’ll tell you … A waterfall.

So what is this ride down the waterfall like?

Well, it starts off very exciting. You get in the boat and head toward the waterfall. There’s never any question of where the waterfall is, you just go the way everybody else is pointing. It starts off kind of fast, but it’s a fun kind of fast and everybody in the boat is up for the challenge. Then, as the current gets going to about 40 miles an hour, you decide to change direction. Well, that doesn’t go so well, does it? Zooooop, and you’re over the falls just like that. Waterfalls are not about change.

On the way down (where we’re doing our project in this metaphor) there is lots of noise in the boat. People are screaming at one another but it doesn’t make any difference. Nobody is doing what they said they’d do back when the trip was planned, and nothing anybody tries makes a difference in the direction or stability of the boat. There is steam and a loud crashing noise coming from the bottom of the waterfall, but nobody can accurately see what’s below. Nobody is entirely sure what is going to happen, but everybody is positive that it is going to involve a lot of pain and maybe death.

sounds fun right?

Every now and then, a boat makes it through this journey and pops out into the river below. The people on these boats likely will suffer from Post Traumatic Stress Disorder but by gosh, they made it! Commendable considering most boats do not survive this journey.

Now let’s move over to the Pond approach:

A project in Pond is represented by taking a boat out onto the pond and getting to a different side of the pond from where you’re starting out. Did I say a different side? Whoa, that’s not very goal-oriented, is it? Well, yes and no.

The goal is expressed with just enough detail to enable us to achieve it and at the same time have room to be creative and take advantage of any opportunities that arise. I figure we’ll decide where we want to land when we get closer. We can certainly make a better decision at the last minute, and it’ll be based on the best information possible (For instance, I have a bad back and I don’t want to have my picnic someplace where there isn’t a convenient place to sit).

So we set out onto the placid water. Everybody is calm. Nobody is stressed. We go to a different side of the pond and take a look at the shore. In unison, we turn to the person called the Pond Owner (or PO, for short) who just shakes her head. So, we turn away and go searching again (when the PO says No, she means No). To keep us from getting tired, we stop rowing every now and then to just sit back and listen to the breeze. Maybe we have a conversation about where to look next, or maybe we just nap. Sometimes somebody will clean up the boat just to make it a little nicer.

Eventually, we find a place that everyone agrees looks nice and we pull the boat up on shore. Our project is complete in a way that we couldn’t have predicted exactly because we’ve never been on this particular pond before. We’re ready to set out again just as soon as we’re done with the picnic. In Pond, you always have a picnic at the end of the project.

So now you know why I think the opposite of Waterfall should be called Pond.

In case you’re wondering, I’m a Pond guy.

About the Author: Alan Atlas is a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

I believe that Agile project management in small, co-located teams crossed into the mainstream back at the sold-out Agile 2007 conference, but Agile program management at scale is just now heating up. Last week’s article on eBay’s Agile adoption in Business Week (combined with other recent news) shows us that organizational agility is becoming a mainstream topic at the highest levels.

The market is no longer asking, “Can we scale Agile across the enterprise and large distributed teams?” and instead is asking, “How do I get there?” and “Who can help me?”

BusinessWeek asks, “Can eBay Get Its Tech Savvy Back?”

Watch the video of eBay's Mark Carges on BusinessWeek.com

Author Douglas MacMillan says: “Carges’ plan for eBay is to take the “agile” method of software development epitomized by the daily deal widget and expand it to other areas of the site. New product pages will be customized to better accommodate different categories, such as jewelry and clothing. And the company is helping third-party developers create applications for eBay’s site such as a UPS-branded terminal for monitoring shipments” Read the full article >>

Author Note: Mark Carges was my boss and mentor at BEA.  I know a good bit about his current efforts and they are really going for it at eBay and PayPal.  It is great that their enterprise agility efforts will unfold in public eyes.

In other mainstream signs of Agile…

I was excited to see a couple of other great articles on Agile this week, including:

• Marketers often say you’ve reached the mainstream market when you notice your peers are doing it, and you feel behind enough to move. InfoWorld’s Paul Krill noted in his article Software Companies Jump on Agile Programming Bandwagon how many providers are “eager to hop on the agile development train.” (Clearly, we have an early mainstream market now.) See my post about traditional providers, including IBM, entering the space.
• Gantthead’s Bob Weinstein handily made the case for transitioning to Agile development in his article on Making a Case for Agile Project Management. He says:

“If ever there were an ideal time to make the leap from a traditional to an agile project management approach, it’s now. In this tense, uncertain, cost-cutting environment where CIOs are watching their bottom lines like hawks, the concept unfailingly proves successful. It not only delivers consistent, excellent results on time, but often under budget.”

• Finally, David Rubenstein from SD Times tackles the issue of Agile Development Built to Scale. I agree with Robert Holler that scaling anything across an entire organization is tough, and that sometimes Agile just gets a bad rap for something that is universally a challenge. It does take commitment from the team, a bit of training and a lot of inspecting and adapting to be the best Agile organization you can be.

The question these days is: how good do you want to be, by when, and who’s the best partner to get you there?

The Agile Blog is proud to present the first post from our newest contributor, Agile Coach Ken Clyne

If a team member doesn't take accountability, things can get messy

With a four year old and a six year old, familiar sayings around our house are “pick up your toys,” “pick up your clothes,” “brush your teeth,” “get dressed.” Of course, as parents we could get our short-term objectives met much faster if we just did these tasks ourselves… but we don’t.

We understand the importance of our children developing their own awareness of basic hygiene, cleanliness and developing their own skills that will one day help them become independent.

Giora Morein takes somewhat the opposite view in a recent Agile Tip of the Month article. He proposes that ScrumMasters (or, in my extreme analogy, the “parents”) should track hours remaining on a sprint on behalf of the team members (the “kids”). Giora says:

“Team members are focused on completing tasks and delivering value. The time-tracking is a nuisance and a distraction for these motivated folks. To the ScrumMaster and the team, however, it is extremely important. As such, the ScrumMaster should take on the responsibility of updating burndown data.“

While I don’t question Giora’s good intentions and there is no doubt this approach is expeditious, I believe it is worth striving to have the team update their own hours remaining. There are many benefits to being a member of a self-organizing, self-managing team, but with those benefits also comes responsibility and accountability.

Here are some dangers I see in a team not taking responsibility for their hours:

• They become less accountable for the number they provide

• They don’t understand the mechanisms of the self-managing, self-organizing team

• They become dependent on the ScrumMaster

• The ScrumMaster becomes frustrated and disillusioned

• The ScrumMaster morphs from a leadership role to a management role

• The team starts to revert to form

How does your team update its remaining hours? Have you tried one method that worked better than another?

#5 in our list of the Top 10 characteristics of an Agile organization is about the importance of practicing both Bottom-up and Top-down decision making.

In this 4 minute video, I talk about how successful Agile organizations embrace a notion of the ‘knowledge-creating company.’ In Agile, knowledge-creation can use “5 Levels of Planning” to ensure they are engaging in this whole organization practice. In sum, the highest level of planning, the vision, feeds and is fed by all subsequent levels, down to the lowest level of planning, the detailed daily work.

Watch my video for more about why I truly believe in both Bottom-up and Top-down decision making as a key success factor.

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8  Sustainable and Successful, #7 Contributing to the Community and the Company and #6 Collaborative and Smart. Stay tuned for #4 in our series, Personal Flexibility and Rhythm.

Okay, I must be obsessed with Agile and PMOs lately. Well, Lean, too, as long as we are talking about obsessions.

Recently, I posted two blogs on the PMO topic: “Are PMOs Obsolete in Agile?” and “8 Ways to Re-tool a PMO in an Agile Environment“.

Now, in the upcoming Better Software Conference June 8 through 12, I will be presenting “Agile, Lean and the PMO”.

To summarize and entice, let me give you a quick preview.

PMOs usually think they are out of a job when Agile comes to town. But the truth is that a PMO can play a pivotal role in successful Agile adoption in large organizations.  In this presentation, I bring my experiences guiding organizations in how to engage their PMOs for successful Agile Adoption.

Enter three primary Lean Principles:

• Eliminate Waste
• See the Whole
• Amplify Learning

I intend to give examples of how PMO members act as the “systems thinkers” for their organizations, pulling Agile success outside of the engineering group alone and into the entire enterprise.

As I’ve stated before, there is a fundamental shift of the role of the PMO with Agile.

Simply stated, the PMO pulls standards versus pushing them;  the PMO provides product backlog prioritization guidance with regard to architecture and governance; and the PMO serves its Agile community by facilitating release planning across teams and creating and maintaining product councils.

In short, I contend that a truly Agile PMO brings “shocking openness” to the organization. This ensures deep, wide Agile adoption.

Let’s get together in Vegas to talk about PMOs and Agile and how Lean can guide us to take “what happens in Vegas” back to our organizations!