Garbage In, Gorilla Out- An Agile Business Planning methodology
•Als PPTX, PDF herunterladen•
1 gefällt mir•1,066 views
No matter how good your agile development team is, when you feed them garbage requirements they will give you a garbage product. If you ask them to build something the customers doesn't want, you'll end up with a warehouse full of New Coke. The GiGo Planning loop take Agile up the value chain and maps out a process for creating a customer focused backlog for your developers to build to.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Garbage In, Gorilla Out- An Agile Business Planning methodology
- 1. © 2012 J Bancroft-Connors
- 2. © 2012 J Bancroft-Connors
- 3. © 2012 J Bancroft-Connors
- 4. © 2012 J Bancroft-Connors FORD Edsel
- 5. © 2012 J Bancroft-Connors
- 6. © 2012 J Bancroft-Connors
- 7. © 2012 J Bancroft-Connors
- 8. © 2012 J Bancroft-Connors
- 9. © 2012 J Bancroft-Connors
- 10. © 2012 J Bancroft-Connors
- 11. © 2012 J Bancroft-Connors
- 12. © 2012 J Bancroft-Connors "If I have seen further, it is by standing on the shoulders of giants” - Isaac Newton
- 13. © 2012 J Bancroft-Connors 3.4) The product shall have a gasoline- powered engine. 3.5) The product shall have four wheels. 3.5.1) The product shall have a rubber tire mounted to each wheel. 3.6) The product shall have a steering wheel. 3.7) The product shall have a steel body. 3.8) The product shall be red
- 14. © 2012 J Bancroft-Connors
- 15. © 2012 J Bancroft-Connors
- 16. © 2012 J Bancroft-Connors
- 17. © 2012 J Bancroft-Connors
- 18. © 2012 J Bancroft-Connors
- 19. © 2012 J Bancroft-Connors
- 20. © 2012 J Bancroft-Connors
- 21. © 2012 J Bancroft-Connors
- 22. © 2012 J Bancroft-Connors
- 23. © 2012 J Bancroft-Connors
- 24. © 2012 J Bancroft-Connors
- 25. © 2012 J Bancroft-Connors
- 26. © 2012 J Bancroft-Connors
- 27. © 2012 J Bancroft-Connors
- 28. © 2012 J Bancroft-Connors
- 29. © 2012 J Bancroft-Connors
- 30. © 2012 J Bancroft-Connors Funchal Forest Starr & Kim Starr
- 31. © 2012 J Bancroft-Connors
- 32. © 2012 J Bancroft-Connors
- 33. © 2012 J Bancroft-Connors
- 34. © 2011 J Bancroft-Connors
- 35. © 2011 J Bancroft-Connors
- 36. © 2011 J Bancroft-Connors
- 37. © 2011 J Bancroft-Connors
- 38. © 2011 J Bancroft-Connors
- 39. © 2011 J Bancroft-Connors Bev Sykes
- 40. © 2012 J Bancroft-Connors
- 41. © 2012 J Bancroft-Connors
- 42. © 2012 J Bancroft-Connors
- 43. © 2012 J Bancroft-Connors
- 44. © 2012 J Bancroft-Connors
- 45. © 2012 J Bancroft-Connors
- 46. © 2012 J Bancroft-Connors
- 47. © 2012 J Bancroft-Connors
- 48. © 2012 J Bancroft-Connors
- 49. © 2012 J Bancroft-Connors
- 50. © 2012 J Bancroft-Connors
- 51. © 2012 J Bancroft-Connors
- 52. © 2012 J Bancroft-Connors
- 53. © 2012 J Bancroft-Connors
- 54. © 2012 J Bancroft-Connors
- 55. © 2012 J Bancroft-Connors
- 56. © 2012 J Bancroft-Connors
- 57. © 2012 J Bancroft-Connors
- 58. © 2012 J Bancroft-Connors FlickrLickr` carpetcleaninglosangeles.net/ Ildar SagdejevCitizen D
- 60. • As a stressed traveler, I want to have my body relaxed, so that I can enjoy the rest of my trip. © 2012 J Bancroft-Connors
- 61. © 2012 J Bancroft-Connors
- 62. © 2012 J Bancroft-Connors
- 63. © 2012 J Bancroft-Connors
- 64. REFERENCES: “Users Stories Applied”, Mike Cohen “Agile Estimating and Planning”, Mike Cohen “Agile Project Management”, Jim Highsmith User Stories: http://www.mountaingoatsoftware.com/topics/user-stories http://www.agilemodeling.com/artifacts/userStory.htm http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories- for-requirements Personas: http://www.agilemodeling.com/artifacts/personas.htm Other: http://www.agilelearninglabs.com Joel and Hogarth can be found at: http://thegorillacoach.com jbancroftconnors@gmail.com © 2012 J Bancroft-Connors
Hinweis der Redaktion
- <END SLIDE INTRO>Welcome to the graveyard of failed products. The tragic, final, resting place of so many good products. I mean, who wouldn't want to drink Coors brand sparkling water, while giving your dog some nice beef flavored Thirsty Dog brand bottled water? So what's notable about these products? What do New Coke and the HP tablet share in common? Technically they did exactly what they were supposed to do. Unlike say the RJ Reynolds' smokeless cigarettes, which reportedly "produced a smell and a flavor that left users retching," the HP Tablet was remarkably well put together. PC World even gave it a nod as the best audio in a tablet. The problem, with all of these, was one of requirements. Whether it was a lack of need - did we really need to go through the whole New Coke episode - or if it was a misunderstanding of the customer's want - the Apple Newton tried to do too much when what the customer really wanted was just contacts and calendar - or just plain bad design - you can't build an unsinkable ship when your watertight compartments only go part way up the hull - all of these failed before any work was done to build the actual product. The logical next question, is why?
- Garbage in, Garbage Out: No matter how awesome your developers are, when you feed garbage requirements into the team, you are going to get a garbage product out. <Pause> Though if you have this team, you might have bigger worries. Their so clean cut I get papercuts just looking at them.
- Before we can continue I must acknowledge that all the principles of my talk are based on the work of those who have blazed the trail before us. I haven’t invented the wheel and certainly not a new management philosophy. Just as Lego blocks are infinitely variable, I’ve taken the buildings blocks agile trailblazers have given us and assembled them together to create something new. And with that public service announcement, let’s talk about why the classic approach to requirements doesn’t really work.
- Mike Cohn, in User Stories Applied, gives us an excellent example of how requirements can lead to a perfect product, that's a perfect failure. Let's consider the following requirements: [Read From Slide]3.4) The product shall have a gasoline-powered engine. 3.5) The product shall have four wheels. 3.5.1) The product shall have a rubber tire mounted to each wheel. 3.6) The product shall have a steering wheel. 3.7) The product shall have a steel body. 3.8) The product shall be red.Well I don't know about what you all think of. Me, I'm an optimist, here's what I want to build.
- Oh, yeah… Of course, the problem is that it doesn't matter what I want to build. It matter's what the customer wanted built.
- The sports car fit the requirements just fine. It certainly is well put together and probably fun to drive. And it was a failure because it didn't give the user what they wanted. A blade to cut the lawn. Garbage In, Garbage out. There in lies one of the failures of new product development. One that has even come to roost in the disciplines of agile. Take Scrum for example. The seventeen page “official” guide devotes roughly a page to backlog. It assumes you have a well ordered backlog and this is primarily focused on "the product owner owns it, grooms it and you find more detail towards the top." Yet, as we can see, knowing what you are building is just as important as how. You can have the best development team in the world and if you hand them bad requirements, you get a bad product. If you tell your engineers to build something the customer doesn't want, you end up with a warehouse full of New Coke.
- So what do we do? We pull agile up the value chain. As Jim Highsmith advocates in his book, Agile Project Management, we create an agile enterprise framework. More specifically we tackle the creation of requirements with the same focus and dedication we have done in tackling product creation in the development teams. We need to create a new agile team, one where the shipping product is not something tangible. It is instead a well ordered backlog.
- What I am proposing is a new agile framework specifically for taking a product from ideation to well ordered backlog. From "I have a great idea." to "All right team, let’s build this."
- I think we are all familiar with the Scrum big loop, small loop iteration cycle. The GiGo cycle extends this out to recognize the growing trend of a release iteration cycle, where a product is made up of multiple releases which may or may not ship to the customers, and then to the GiGo product planning iteration cycle. We start by defining the product in broad strokes. We then layout a timeline or outline, to look for what's missing and how it all fits. Then we move to creating the detailed user stories. From there we estimate, both the effort required and the value of the stories. We then come to the final ordering of the backlog. Take it to the team, plan and iterate, reflect, rinse and repeat.
- Before you can create a new model, you need the team to do it. Who defines the product? Who fleshes out the vision? Who sets the business priority?
- They say no man is an island. This is never more true than for the Product Owner. The product owner is not an island. He doesn't sit in some ivory tower and imagine great ideas, which he then transports to the development team in a puff of smoke smelling faintly of brimstone.
- Our product owner, still called a product manager by many companies, instead is sometimes nearly reduced to the level of a scribe collecting all the inputs from other parties and trying to justify how to have the product be "fast", "ultra-secure" and "cheap." The product owner must work and take inputs from a wide variety of sources in an often dizzying array of inputs and conflicting priorities. When every organization is clamoring for their little slice of the feature pie, you can end up with a product that looks m
- You wouldn't design the architecture and features without the agile development team, why design the business plan without an agile business team? As with an agile development team, you need to get the agile business team all moving in the same direction and working collaboratively.
- Who should be on the team? Other than the product owner, again it depends. This is a list of common team members based on the most common roles to contribute to traditional requirements documents. While the product owner is the final decision maker, she is not the only person to have input into the creation process. When the PO works with a village, they prevent the customer, sponsor and team from getting PO'd at them.
- Okay, so you've got your Agile Business Team. Now let's build that backlog! Tell me, do you know what you are building? More importantly, do you know what he thinks you are building? Let's say that you're making a car. Whew, that was easy, let's jump to the user stories now, right? No. The engineering team wants to build a Ford F150.
- Unfortunately the sales VP thinks they should be building a BugatiVeron. Even at this level, you need a basic set of understanding in order to move forward. The team needs to agree on what kind of car you are making, in order to all be working on the same page for the rest of the planning.
- For this stage I draw on Jim Highsmith and the Envisioning chapter of his book Agile Project Management: Creating Innovative Products. HIs Product Vision Box exercise is powerful. Not only can it ensure everyone is on the same page, it can reveal gaps and even opportunities for the product.
- The Elevator Test Statement I tend to think of like a set of acceptance criteria for the product vision. With it you need to test that you know your target customer, key benefits and competitive advantage.The key CONCPET is that It’s about asking questions, communicating and even having arguments. I’d rather argue about if the room should be painted blue or white before we buy the paint, then argue about why Bob painted it yellow.
- “How did we forget that feature?” has been a long asked question, typically so far into the development process as to require derailing the project to get the feature in. I worked on a software project forget to build the installer until we were three quarters of the way through the project. Whoops. Story Mapping is a process that discovers the users, the end to end experience and then allows you to drive into the highest level of user stories but doing vertical break downs.
- User Identification: This is a simple exercise to identify the users of the product and flesh them out into personas. It starts with post-it brainstorming to identify user roles, both external and internal and then dives into questions to identify the who/ what of the users. Mike Cohn’s, User Stories Applied and Mulder/Yaar’s, The User is Always Right are good places to dig into the details of building a user persona. That or just do a Web Search for “Creating User Personas” for over 1.6 million web hits. These represent the persona pictures for a hypothetical project of to create a Tropical Beach Resort.
- Ever heard of the “Peanut Butter Rule”? It’s the only real rule to effective brainstorming. When a team is brainstorming, everything goes and nothing is wrong. If you’re brainstorming on how to reacrhitect the database and someone yells out “peanut butter” then you write it down. Brainstorming is about getting ideas to flow, not judging them for their relative worth.That’s the basis for Story Brainstorming. It’s a free form post-it brainstorming to get you high-level user experiences, or “stories”, captured. So for our Tropical Beach Resort, stories are at the level of “Day Spa,” “Airport to Hotel Transportation,” “Snorkeling excursion,” etc. No order to the postings, just get them up on the wall. A tip: Known stories can be added to the wall, but should be added after the brainstorming to keep them from distracting new ideas.
- Once you have all your high level stories, you need to start figuring out how they fit together. I think the next two exercises are part of the real “secret” sauce of a successful planning process. I learned these concepts when I took Chris Sims’ Product Owner training and they served as the germ of the entire GiGo process. You start with a horizontal activity timeline. Whether you’re designing a beach resort, a new social media game or the interior of the next supersized aircraft, you can walk through the user experience from beginning to end. This is where you take the mass of user stories and put them into a semblance of order. The Agile Business Team is guided to lay out the story cards in a logical progression from left to right. For example, if you were mapping out a Tropical Resort you might start with “breakfast on the veranda,” progress through “guided tour of the rain forest sanctuary,” and end with “dinner on the floating barge surrounded by fire jugglers.” Once the existing stories are laid out, the team then walks through the experience to see if anything stands out as missing in the user experience. Perhaps the Tropical Resort team completely overlooked the need for lunchtime food service, or the software team may have forgotten how the product will be upgraded. This will also be when you weed out the stories that obviously don’t fit with the project. Peanut butter cookies may taste great, they don’t fit in with upgrading your SQL database so you can take that story and put it in the round file.
- With the top-level user experience mapped out. Now it is time to dive into each story. What does it take to get your user from their bed to their scuba experience and back again? You know what they want to be able to do at a high level, now you need to figure out the step by step. The team brainstorms on what is needed for that story to happen and then puts them into a timeline progression from top to bottom. This essentially replicates the Horizontal timeline with a focus on each individual user experience. These then form the basis of your first generation user epics or stories.
- “The operation was a complete success, unfortunately the patient died.”A poorly written user story can lead to the implementation of something that is technically perfect and a complete failure as it doesn’t meet the needs of the user. Of course we could spend hours on just user stories. And let’s not since there are tons of books and other talks that focus on the value and need for user stories. So let’s just give just the barest of foundation, from which to work from for the GiGo framework.
- The Invest framework helps us to make sure we have all the makings of a good user story.INDEPENDENT- Avoid dependencies on other stories.Write stories to establish the system foundationNEGOTIABLE-Stories are not a contractVALUABLE-Show what the value of the story is for the customers and other stakeholdersESTIMABLE- Sufficient detail needs to be present to estimate the work effortSIZED RIGHT-Stories should be small enough to complete in a sprint (2 weeks)TESTABLE-Acceptance criteria should be apparent in the user story
- As critical as it is to make sure you have a well-crafted story. It is also important to recognize what it is not.
- User Stories are also not a one-size affair, typically you hear about Epics, User Stories and Tasks. I’ve found it can get very confusing if you don’t provide a good set of definitions. I also believe that this is an area where more is better. The definitions I’ve found work are: Vision: A concept or direction. “Let’s make a portable music player.” Use Case/Feature: a fuzzy, client‐valued capability of the system. A Feature typically contains many stories… Epics Represents something that provides externally visible benefit to the project. Is too big for one sprint or even release. There can be more than one level of Epics. You keep breaking them down until you get to User Stories. User Story: The fundamental unit of work, represents something that provides externally visible benefit, that can be done in an iteration. Developer Story: Developers often want more detail, or just to put their stamp on it. Let them. Task: The actual work that individuals do in order to make the story “come true” –many Tasks per Story
- Now the problem with Use Cases and Epics is they are like Mount Everest, too big to climb in a single day. The challenge is to break down the Epic in the same way climbers have broken down the climb up the world’s tallest mountain. <point at slides> I’m sure many of you have heard these arguments.
- This is one of the largest challenges in the creation of a backlog. You have to go just far enough with the details of a user’s experience and not to far that you’re creating a functional feature spec. Product Managers often struggle to not provide so much data that they are directing the engineers to a specific implementation – which can both stifle a creative new idea and can upset the engineers who feel they are being dictated to. Engineers who get too vague a story are faced with challenges, not the least being “what exactly are we building,” “If I’d know that originally, I would have estimated this as a much bigger story,” and “This will take at least six weeks, I can’t do it in a four week sprint.” By breaking user stories down to iteration manageable levels the team is able to better estimate value and cost (time to complete), removes confusions that can result in a feature that doesn’t match the vision of the product owner, allows for shorter iterations – which itself improves the overall development process by allowing more chances to apply the “inspect and adapt” philosophy of agile. Agile Learning Labs, Product Owner Training taught me this four-step method that has so far been successful in breaking down even the largest of challenges. Like cleaning my thirteen year-old son’s bedroom. Find the Conjunctions: This is the first stage to user story break down. Take an existing story and find all the conjoining phrases (and, for, or, so, but, either, both, after, before, until, etc.). At each conjunction, break the story. Flesh out the one before the conjunction and find the next conjunction. You can end up with several new stories from just a single user story. Generic Words: “The user Logs In” can be a very generic statement. If your product supports multiple OS types and even mobile devices, then each one of those is its own user story. Anytime there is ambiguity in a word “Large,” “Easy,” or something you can’t test for, then narrow down the ambiguity. Often this will result in conjunctions (As a user I want to log in from my iPhone, iPad, Android, Mac and PC) and then you can break them down into their own stories. Reverse the Acceptance Criteria: One of the advantages of applying acceptance criteria on even the vaguest user story is you then have a basis to dive into more information. Exploring having a masseuse for your day spa could quickly lead to two new users – As a private person I want the masseuse to come to my room, as an active person I want the day spa close to the beach and other water sports – and new stories – Mobile masseuses, Satellite location by the beach. The truly helpful result is when the acceptance test gives you even more detailed user stories. The “Facial Treatment” acceptance criteria can lead to user stories to cover mineral treatments, mud masks, acupressure massage and so on. Each of these becomes the foundation of a new user story. Time Line: The last in the line, this technique is particularly useful if you haven’t done Story Mapping on the product. Time line looks at a user story from the perspective of it being done and the team is asked to envision how it would work when done. This creates a timeline of events. Each event can then be turned into a user story.
- Here’s one of my secret sauces for User Stories. No matter if you are at Vision or Task, it is critical to have an acceptance test to validate against. Even a high level epic can have an acceptance test. Acceptance tests are simply a verifiable way to prove that the story is done. Take the user story “As a overworked mom, I want a day spa, so that I can relax on my vacation” then acceptance tests can be “Has a Masseuse,” “Has a sauna,” “Offers Facials.” These are clearly measurable tests. As opposed to say “is soothing”, is “is relaxing”. Every story in the backlog, no matter how far down the list and undefined they are, should have basic acceptance tests identified.
- If you’re attending an Agile Trends and Leadership meetup, then I think you probably already understand the basics of estimating stories for how much effort it will be to do them.
- Story point estimating is one of the foundational principles of agile development. Done well, story estimating can create an incredible level of predictability and transparency. A high performing team can look at a set of requirements and provide a high confidence assessment of when they will done.
- And estimating shouldn’t just be for the people doing the work. If I have one hundred perfectly defined stories what do I do with them now? Sure, I can hand them off to the development team and they can give me a level of effort so I know how long it will take to build all one hundred features. That's great, and I still don't know which ones to do first.How many of you have seen this as a solution?
- I remember one project where we had roughly fifty features. Of those, thirty were P0 and twenty were P1. I can’t even remember the last time I ever say a P3 in a requirements document. When everything is a P0, how do you decide what gets built? Well if you ask a traditional product manager, they’ll cheerfully reply “Everything is a must ship feature.”
- Which is why we need to do Business Value story point estimating. What is the value of this benefit to the customer and/or the business? This can also be asked in reverse, "what will it cost us to not implement this?" If you can’t break out of the P0 trap, then you’re going to end up with your engineering manager saying to you, "Just give me the list of what you want, I'll figure out what I have time to build."Technically perfect and customer flawed.If everything is a P0, then what gets built will be decided based on the level of effort and the risk. Which brings us back to
- We want to estimate both the Business Value and Cost for every user story. I think we can all agree with this? So next we break out the planning poker cards, right?
- What? Come on, I'd be a lousy gorilla talker if I wasn't willing to tackle tough subjects head on. I do absolutely think story point estimating is the right thing. I just think planning poker is not the best way to do it. Naturally this begs the question of "why?" I have three reason for my concerns on the use of planning poker:
- Each user story (feature, tasks, item) is evaluated on its own. When you do planning poker you are just looking at how long it will take to paint the garage door. You are hard pressed to look at it in relation to putting a new latch on the back gate. I think the mind is hard pressed not to assign a physical value to the estimate. "I think this will take two hours, that's about a 3." At the end of the day, the planning poker process occurs in an individuals head. Yes, there is a discussion among the team, but only after each person has drawn a line in the sand. Once the human mind draws a line, it finds it hard to move that line. The devil is in the details. And at this stage in planning, we don’t want to get into the details. The problem I see with Planning Poker is that the conversation disagreements tend to dive deep into implementation details. When you are trying to decide how big an effort the DB schema change is, you can end up pretty deep in the technical drak before you are done. When you evaluate each feature on its own, it is very hard for the human mind to not associate time with it.So don't…
- Steve Bockman, of Agile Unlimited, developed an estimating process called "The Team Estimating Game." He and Agile Learning Labs had been using the game for years, teaching teams and companies this new way of estimating story points. In 2012, Agile Learning Lab's Laura Powers realized that it could be used for assigning Business Value and they further refined the game for use in their Product Owner training.The game addresses the issues of Planning Poker head on and make it something that is completely practical to use with business suits or engineering flip flops. We don’t really have the time to do a fully interactive demo, though if you really want to learn this in depth, I suggest inviting Steve Bockman down to teach it. So let me give you the cliff notes version. Before I do, an Important piece of advice. If you are planning to have these stories estimated for cost (time to develop), it is recommended that the business value not be shared with the team doing the level of effort estimating until after they’ve done their estimating. This prevents the cost estimating being skewed by the Business Value.
- And here is an, in process, example of a Business Value estimating game. Here the business suits are deciding what are the most valuable things to have on the houses they are trying to resell on a flooded market.
- “One backlog to rule them all, one backlog to list them; One backlog for stories all and in the team we define them.” <cock head> Okay, maybe a little to dramatic. Still, that’s essentially what we get at the end of the process.
- Here is what the front of a finished user story would look like. Your User Story ends up with three values: Business Value: What is the benefit of this story to the business? Often by understanding what the benefit of the story to the customer.Experimental value: We didn’t cover this, however it is important. It’s from Highsmith’s book I referenced before. At the high level this is a numeric value that maps to how hard what you want to do is. Building a hot mud bath has been done thousands of times. Building an underwater, hydro powered massage theater hasn’t ever been done and the technology may not even work. The higher the number, the more experimental it is. This is essentially your technical risk score. Cost Value: What will it take to implement this user story? Generally expressed in the level of effort by the team creating it. With the stories in the backlog defined to this level, the product owner has the information he needs to complete the GiGo loop and get the team on to the important “Doing” of the project. The product owner uses their judgment and skill to create the ordered product backlog. They do this by weighing the business value against the cost of a implementing a story. A Note: In agile development, best practice is to groom the backlog once per iteration with the product team. This is where cost can be reevaluated, better definitions of stories can be done and the product backlog reordered as a result.
- So let’s see where we are now. We started with definition. Everyone now knows we are really building a Ford F150 and we’ve validated our Elevator Test. We all know what we want to do. Then we created the outline for our project. We identified users, their stories, and put it all together in a timeline to make sure we didn’t miss anything. From their we went into estimating, both Business Value and Cost to Create. By working with both the Agile Business Team and the Doing Team we defined and estimated the user stories or at least the top-level epics. Finally the product owner puts it all together into the starting backlog and we’re ready to go from “Business to Do.” We step out of the GiGo Planning loop and into the Release Planning loop of the doers. The doers plan out the release and then they start the actual doing in the iterations. We rinse and repeat through our agile/lean model of choice.
- Oh, I’m sorry. Did I say agile/ lean? The GiGo planning loop can be used with any kind of development cycle. Even if your development team is the most died in the wool obstructionist waterfallers, there is nothing preventing you from using this process to make darn sure what they are working on is what the business wants, not want engineering wants to deliver.
- So before I thank you all for putting up with my lame jokes, poor segues and bad clip art, we just need to look at the naming. Now I’m terribly partial to GiGo. I also know if you were to tell your director of product management, “we’re going to use the garbage in, gorilla out planning process”, he’d probably give you as much credence as the boy who cried wolf got from the town’s people. For want of a better term, I guess the “Agile Business Planning Loop” will work for now. If my ideas catch on, I’m sure someone will come up with something much better. Probably about the time they create a training program around it and start charging companies tens of thousands of dollars for “their” great idea.
- So now we’ve come to where I thank you all for putting up with my lamejokes, poor segues and bad clip art.Thank you. I’ve enjoyed the opportunity to share my passions and ideas with you and I hope you took away something of value today. If you didn’t, you can at least go home tonight and ask the question, “Did you know Bic Pen made underwear?”