School of Systems and Enterprises Stevens Institute of Technology, USA

1. ES/SDOE 678Reconfigurable Agile Systems and EnterprisesFundamentals of Analysis, Synthesis, and PerformanceSession 6 – Synthesis: Design Exercise and Strategy Refinement School of Systems and Enterprises Stevens Institute of Technology, USA

2. FEEDBACK REVIEW The last exercise you completed will not be reviewed until you have a chance to take a second pass through it later. To prepare for that second pass, we will look at an agile development processand then do a practice run (team trial).

3. File50-60 Transcript Guest Speaker: Joe JusticeHallway Open Q&ARecorded at Agile2012 Dallas, TX, 13-17Aug2012 TX, 13-17Aug. Keynote Speaker Joe Justice brought his very first,100 MPG WIKISPEED X PRIZE race-car with him to Agile2012! This is the X PRIZE competition race-car that a volunteer team from around the world built, using agile methods and practices, free collaborative tools, and the driving motivation of a much greater humanitarian dream. In a fun and engaging hallway Q & A -- Joe meets with attendees in a casual unscripted hour of sharing practical Agile knowledge, pointers, and experience. He uses the x-prize car as a case study in excellence, and his experience as an agile coach to speak in practical agile terms across both hardware and software industries. The result is an awesomely insightful and engaging dialogue. You'll find actionable insights you can use to build successful teams for software, or hardware -- for applications or automobiles. Video at: www.agilealliance.org/resources/learning-center/wikispeed-q-and-a

4. Joe’s WikiSpeed Concept Base16-18 May 2011 Global Scrum Gathering, Seattle, Our Process, Video: http://bcove.me/zcryseb7 • Interfaces for modules were specified up front – physical location of bolt holes for instance – no welding. • Could evolve all the systems independently of each other. • Iterations on designs until test requirements are met. • Distributed collaborative team – some working that never had face-to-face contact. • From common sense to manufacturing to software and back to manufacturing. • Agile: reducing cost to make changes. Iterative development. • TDD: clear success criteria and rapid course change. • XP: Pairing and swarming. • Scrum: clearly defined roles and responsibilities. • OOP: clearly defined modules and interfaces. • Kanban: work in progress limits (make sure someone’s not overloaded).

5. Principles of Joe’s WikiSpeed Approach16-18 May 2011 Global Scrum Gathering, Seattle, Our Process, Video: http://bcove.me/zcryseb7 • By minimizing cost to make changes we innovate quickly – changes in team members (new member with new skills), tooling, materials, components, even goals (which kept changing as to the type of competition track to be driven to win). • By loosely coupling modules we make changes in parallel (many people working on alternate approaches to modules). • By working collaboratively in shared space we unblock quickly (you see another person get blocked through body language, a pair starts getting quieter, team sees this and “swarms” early to help). • By first automating tests we quickly know if we have improved (regression tests, test driven, metrics are important with measures of success criteria – red/green light). • Tests are the success criteria. • Team morale is a multiplier for velocity (large part of progress success). • Iterations and stubs (temporary stand-ins that occupy the space a future module will need so people can work around it instead of waiting for it to materialize) make for constant successes (ask intelligent questions on-line to solve and attracted “deep nerds” with solutions).

6. Joe: What Are We Giving UP?16-18 May 2011 Global Scrum Gathering, Seattle, Our Process, Video: http://bcove.me/zcryseb7 • By eliminating cost to make changes we innovate quickly, changing components and even goals when appropriate: • We add time and cost to design coupling points and make that time back each time we change a module. • By loosely coupling modules we make changes in parallel: • Requires multiple people with project manager skills. • By working collaboratively in shared space we unblock quickly: • Some folks think it will be distracting, we found dramatically increased velocity. • By first automating tests we quickly know if we’ve improved: • We add time and cost to design before we even start work and solving problems. We get that time back by killing work that is damaging our success metrics, and it also boosts morale which boosts velocity. • Tests are success criteria: • No downside. • Team morale is multiplier for velocity: • No downside. • Iterations and stubs make for constant successes: • Folks might see rapidly replaced modules as waste. Actually less waste and less delaying of an enhancement until the next vehicle build.

7. Observations • Agile development people are focused on brand-specific procedurals. • Many people are trying to reach “accommodation” between CMMI and Agile. • CMMI measured by repeatability of the process. • Agile development is measured by speed and quality of the result. • How to migrate to Agile Development is a major & critical issue for many. • Reality: • Requirements uncertainty on the increase? • Deadlines coming sooner? • Systems complexity on the increase? • Management wants plan-driven predictability, but need agile-driven quality? • Govt customers want plan-driven predictability, but need agile-driven quality? • Questions: • What are your specific issues with plan-driven vs agile-driven, • for customer, management, supervisor, yourself? • Are CMMI and Agile Development • compatible, complimentary, anathema? • Is Agile Development dependent on human skills of team leadership?

8. Deferred Commitment • “Real Options" Underlie Agile [Software Development] Practices • Whether people realize it or not, "freedom to choose" is the underlying principle behind many of the agile practices. We call this principle Real Options. An understanding of Real Options allows us to develop and refine new agile practices and take agile into directions it hasn't gone before. • Real Options also help us understand why some people resist some of the practices. • To use a familiar phrase, Real Options is about "deferring decisions to the last responsible moment," which is an explicit principle in the Lean Software approach. By avoiding early commitments, you gain flexibility in the choices you have later. • Chris and Olav have collaborated on a book about Real Options and how they really work. “Real Options” Underlie Agile Practices, Chris Matts and Olav Maassen, Jun 08,2007, http://www.infoq.com/articles/real-options-enhance-agility

9. Not said: avoid investment in work that won’t be used Deferred Commitment • Viewing Agile [SW] Engineering Processes through Real Options • Real Options are everywhere in agile practices. To illustrate this let's look at some agile practices and point out where commitments are avoided as long as possible. These are just a few examples. Once you become aware of Real Options you will discover a lot more. • Behaviour Driven Development and Test Driven Development provide many options, especially "the option to change the software, knowing when you have broken it." Without test driven development, there would be no refactoring. In other words, test driven development removes the need for design commitments, the choice of design can be deferred until after the coding has started. More subtly, Test Driven Development allows the developer to know with certainty that they have finished, instead of determining beforehand when the programming is done. Test driven development requires no decision at all, simply stop coding when all the tests are green. Similarly mock objects allow the developer to defer the decision on how to implement a class until a later time when they have more information on what is required from the class. They also create a nice recursive implementation pattern. • XP and Scrum defer the decision about which story to develop until just before the coding starts. This allows the team to incorporate information that arrives at the last moment, such as a new client request. The Scrum Backlog provides a forum where any idea for functionality can be recorded without requiring an immediate commitment to build it. • At the project Chris is working on, the development is prioritized based on client requests. In effect, sales drive the prioritisation process by stating the relative importance of a client. The team doesn't start working on a feature until the clients have requested it. "Strategy" meetings were cancelled several months ago because they were just crystal ball gazing about the features the team thought the clients liked. Now the team waits to see what the clients actually request. • By delaying commitment on the features built, the team is able to reduce time-to-market for new features requested. When the client requests a feature the team is free to act, because they are not tied up working on unwanted features. This is only possible with short iterations and a fast turnaround on regression testing. “Real Options” Underlie Agile Practices, Chris Matts and Olav Maassen , Jun 08, 2007, http://www.infoq.com/articles/real-options-enhance-agility

10. In-Class Tool Applications • Class Warm-ups Team Trials Team Project • Unit 2 • Unit 3 • Unit 4 • Unit 5 • Unit 6 • Unit 7 • Unit 8 • Unit 9 • Unit 10 AAPAnalysis: Case ConOps: Objectives RA Analysis: Case Reactive/Proactive RA Analysis: TWS RS Analysis RRS Analysis: Case Framework/Modules TeamWikiSpeed RRSAnalysis RRS Reality Factors Reality + Activities Integrity: TWS Closure

11. Exercise – RRS Analysis of Agile Engineering Process • Continuing from yesterday’s analysis of response issues for managing the Team WikiSpeed (TWS) agile engineering process, you will now show the use of RRS principles to address those issues with an agile management solution. • Your knowledge base is the Joe Justice videos. If you have additional appropriate knowledge, from any domain, that’s a plus and should be brought to bear, but it isn’t necessary. You will have to think about the principles that Joe doesn’t articulate. • Discuss what you saw in the videos and compare notes amongst your team. • Generate:Slide 1: Drag and Drop AAPSlide 2: RRS Framework Analyses: 10 Principles Add these slides to your work file: ExAEP-teamname.pptx (or ppt). Two slidesfor brief out This exercise is about the principle-based solutions that must address the issues previously identified for a distributed development project which occurs in an unpredictable and uncertain environment – where project requirements, goals, budget, and time may be discovered and may change during the development effort. You are identifying fundamental RRS-based solution elements that your agile process must employ.

12. Agile Engineering Process Graphic template for your modification into your system needs Components/Modules Integrity Management eee fff bbb ccc ddd aaa Who? Module mix Who? Module inventory Who? System assembly who Infrastructure evolution Active Infrastructure Passive Config 2 Config 1 Config n www xxx yyy zzz Standards / Rules

13. RRS Principles for System: ________________________ (Think: Plug-and-Play, Drag-and-drop) Evolving Standards (Framework)Component interaction standards, responsibilities/processes for evolving the standards. x Self-Contained Units (Modules) Components are distinct, separable, loosely-coupled, self-sufficient units. x Plug Compatibility (Facilitated Interfacing) Components easily inserted/removed, component evolution responsibility designated. x Redundancy and Diversity Duplicate components provides fail-soft & capacity options; diversity provides functional options. x Reusable Scalable Facilitated ReuseComponents are reusable and replicable; with responsibilities designated for inventory ready-for-use availability. x Elastic Capacity Component populations and functional capacity may be increased and decreased widely within the existing framework. x Reconfigurable Flat Interaction Components communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. x Distributed Control and Information Decisions made at point of maximum knowledge; information accessible globally but kept locally. x Deferred Commitment Component relationships are transient when possible; decisions & fixed bindings are postponed until necessary. x Self-Organization Component relationships are self-determined; and component interaction is self-adjusting or negotiated. x

14. BREAK

15. FEEDBACK REVIEW

16. Midterm Homework Prep Important – You are responsible for: Reading the Project Guide and following its instructions Emailing completed mid-term homework to the Instructorby Monday 2 weeks after this class session

17. You Are There – Inside The System Looking Out 678 Operational Story, Oct. 2007 Nicole Long Vince TurRojos

18. The Value of Thought Frameworksin Creativity (Design) and Communication (Engineering) “…perhaps ‘creativity’ can be taught. Perhaps even novices with no creative experience — could produce better ideas if they understood the templates. The Israeli researchers, curious about the ability to teach creativity, decided to see just how far a template could take someone. They brought in three Groups of novices and gave each group some background information about three products: a shampoo, a diet-food item, and a sneaker. One group received the background information on the products and immediately started generating ads, with no training. An experienced creative director, who didn't know how the group had been trained, selected its top fifteen ads. Then those ads were tested by consumers. Consumers rated them as ‘annoying.’ A second group was trained for two hours by an experienced creativity instructor who showed the participants how to use a free association brainstorming method. This technique is a standard method for teaching creativity; it's supposed to broaden associations, spark unexpected connections, and get lots of creative ideas on the table so that people can select the very best. If you've ever sat in a class on brainstorming great ideas, this method is probably the one you were taught. Again, the fifteen best ads were selected by the same creative director, who didn't know how the group had been trained, and the ads were then tested by consumers. This group's ads were rated as less annoying than those of the untrained group but no more creative. The final group was trained for two hours on how to use the six creative templates. Once again, the fifteen best ads were selected by the creative director and tested with consumers. Suddenly these novices sprouted creativity. Their ads were rated as 50 percent more creative and produced a 55 percent more positive attitude toward the products advertised. This is a stunning improvement for a two-hour investment in learning a few basic templates!It appears that there are indeed systematic ways to produce creative ideas. Random House, 2007 www.madetostick.com/thebook/

19. The Curse of Knowledge www.madetostick.com/thebook/ • “In 1990, Elizabeth Newton earned a Ph.D. in psychology at Stanford by studying a simple game in which she assigned people to one of two roles: "tappers" or "listeners." Tappers received a list of twenty-five well-known songs, such as "Happy Birthday to You" and "The Star Spangled Banner." Each tapper was asked to pick a song and tap out the rhythm to a listener (by knocking on a table). The listener's job was to guess the song, based on the rhythm being tapped. • The listener's job in this game is quite difficult. Over the course of Newton's experiment, 120 songs were tapped out. Listeners guessed only 2.5 percent of the songs: 3 out of 120. • But here's what made the result worthy of a dissertation in psychology. Before the listeners guessed the name of the song, Newton asked the tappers to predict the odds that the listeners would guess correctly. They predicted that the odds were 50 percent. The tappers got their message across 1 time in 40, but they thought they were getting their message across 1 time in 2. Why? • When a tapper taps, she is hearing the song in her head. Go ahead and try it for yourself — tap out "The Star-Spangled Banner." It's impossible to avoid hearing the tune in your head. Meanwhile, the listeners can't hear that tune — all they can hear is a bunch of disconnected taps, like a kind of bizarre Morse Code. • In the experiment, tappers are flabbergasted at how hard the listeners seem to be working to pick up the tune. Isn't the song obvious? The tappers' expressions, when a listener guesses "Happy Birthday to You" for "The Star-Spangled Banner," are priceless: How could you be so stupid? • It's hard to be a tapper. The problem is that tappers have been given knowledge (the song title) that makes it impossible for them to imagine what it's like to lack that knowledge. When they're tapping, they can't imagine what it's like for the listeners to hear isolated taps rather than a song. This is the Curse of Knowledge. Once we know something, we find it hard to imagine what it was like not to know it. Our knowledge has "cursed" us. And it becomes difficult for us to share our knowledge with others, because we can't readily re-create our listeners' state of mind. Random House, 2007

20. Your Operational Story Should be Sticky • Simplicity: the idea must be stripped to its core, and the most important concepts should jump out. • Unexpectedness: the idea must destroy preconceived notions about something. This forces people to stop, think, and remember. • Concreteness: avoid statistics, use real-world analogies to help people understand complex ideas. • Credibility: if people don't trust you, they'll ignore you. In some cases, they will be openly hostile, which means they'll actively try to dispute your message! • Emotional: information makes people think, but emotion makes them act. Appeal to emotional needs, sometimes even way up on Maslow's hierarchy. • Stories: telling a story [gets] people into paying closer attention, and feeling more connected. Remember the Jared Subway commercials? www.madetostick.com/thebook/ Random House, 2007

21. Unforgettable Stories • A friend of mine is a frequent business traveler. A few years ago Let's call him Dave. Dave was recently in Atlantic City for an important meeting with clients. Afterward, he had some time to kill before his flight, so he went to a local bar for a drink. • He'd just finished one drink when an attractive woman approached and asked if she could buy him another. He was surprised but flattered. Sure, he said. The woman walked to the bar and brought back two more drinks — one for her and one for him. He thanked her and took a sip. And that was the last thing he remembered. • Rather, that was the last thing he remembered until he woke up, disoriented, lying in a hotel bathtub, his body submerged in ice. He looked around frantically, trying to figure out where he was and how he got there. Then he spotted the note: don't move. call 911. • A cell phone rested on a small table beside the bathtub. He picked it up and called 911, his fingers numb and clumsy from the ice. The operator seemed oddly familiar with his situation. She said, "Sir, I want you to reach behind you, slowly and carefully. Is there a tube protruding from your lower back?" • Anxious, he felt around behind him. Sure enough, there was a tube. The operator said, "Sir, don't panic, but one of your kidneys has been harvested. There's a ring of organ thieves operating in this city, and they got to you. Paramedics are on their way. Don't move until they arrive.“ • From: Made to Stick, Chip Heath and Dan Heath, Random House, 2007, pg 3, http://www.madetostick.com/thebook/

22. Grading (For-Credit Students) • 10% on class participation: • Peer review presentations: demonstration of relevant knowledge application. • Peer review contributions: collaborative engagement with projects of others. • Evidence of study: knowledgeable reference to the readings. • 30% on operational model – Midterm deliverable • Three-element response ability model: relevance and clarity of key concepts in RS Analysis, RRS Principles, and Architectural Concept Pattern diagram. • Two-page operational story: clear evidence of an agile system in operation demonstrated with response objectives, requirements, values, response enabling principles, and operational/integrity management. • Evidence of study: knowledgeable reference to the literature and readings. • 60% on conceptual design report – Final deliverable • Articulate a comprehensive new conceptual design, or analysis of an existing design: response objectives, issues with metrics, and enabling principles; strategic themes and activity web; closure matrix with descriptions; and operational management and responsibilities – see 678 Project Guidance document for the definitive word. • Evidence of study: knowledgeable reference to the literature and readings. due nlt Monday 2 weeks after class due nltMonday 6 weeks after class Reality: The first deliverable is key. Your true understanding of necessary fundamentals is illuminated here. Feedback on this will put your train back on the rails.

23. A newly built custom assembly line for each and every small-batch run, every time, just in time. Course Project (For-Credit Students)(always refer to www.parshift.com/AgileSysAndEnt/ProjGuide/678ProjGuideCurrent.pdf for current requirements) 5 Page Operational Model - Due as deliverable #1 Includes strategic objectives/themes RRS - JIT Assembly Lines Operational Story DetailedConceptual DesignDocumentation ---------------- Comprehensive to one Skilled in the Arts Life with System X – Agility in Action By Rick Dove, Paradigm Shift International, e-mail: dove@well.com, 505-586-1536, Senior Fellow, Agility Forum Look through Fred Mauck's eyes for a moment. You work in a GM stamping plant outside of Pittsburgh that specializes in after-model-year body parts. Your principal customer is GM's Service Parts Organization. They might order '73 Chevelle hoods quantity 50, '84 Chevy Impala right fenders quantity 100, or '89 Cutlass Supreme right front doors quantity 300. Your plant stamps the sheet metal and then assembles a deliverable product. Small lots, high variety, hard-to-make-a-buck stuff. Every new part that the plant takes on came from a production process at an OEM plant that occupied some thousands of square feet on the average; and the part was made with specialized equipment optimized for high volume runs and custom built for that part geometry. To stamp a new deck lid (trunk door) part you bring in a new die set - maybe six or seven dies, each the size of a full grown automobile, but weighing considerably more. And you bring in assembly equipment from an OEM line that might consist of a hemmer to fold edges of the metal, perhaps a pre-hemmer for a two-stage process, dedicated welding apparatus for joining the inner lid to the outer lid, adhesive equipment for applying mastic at part-specific locations, piercer units for part-specific holes, and automated custom material handling equipment for moving work between process workstations. You got a call a few weeks ago that said your plant will start making the Celebrity deck lids, and production has to start in 21 days. Not too bad - sometimes you only have four days. For new business like this your job is to get the necessary assembly equipment from the OEM plant, reconfigure the equipment and process to fit your plant, and have people ready to produce quality parts in the next three weeks. Others are responsible for the die sets and stamping end of the production process. In the last 12 months this happened 300 times. In the last five years you've recycled some 800,000 square feet of floor space in OEM plants for new model production. At this point you have assembly equipment and process for some 1000 different parts - but no extra floor space ever came with any of it. high-variety production - in a business that is traditionally based on high volume economics - and you've learned to do it without the usual capital budget. Eight years at this has evolved some pretty unique techniques - and a pretty unique culture as well. You don't do this by yourself - you're a team leader that may use almost anyone from anywhere in the plant. At this point almost everyone is qualified to help bring in new work - surviving under these conditions has developed a can-do/let-me-at-it attitude almost everywhere, and a shared understanding of how to do it. Eight years ago the plant went to a single job classification in production, cross training everyone on everything - a press operator one day might change dies as well, the next day work in the assembly area building hoods in the morning and fenders in the afternoon - and the following day go off to another plant to review a piece of equipment or part for how to bring it back. For this new business Jim Lesniewski wanted to do the initial recon. He went on the last trip too, experimenting with his video camera. Now he thinks he's ready to do a perfect taping job. He got the idea himself while trying to bring several jobs at once back from another GM facility. This environment encourages self initiative. In addition to taping the operational assembly process he added close-ups of key equipment pieces this time. In the debrief review everyone saw the same thing at the same time - there was almost no debate over what to bring back and what to ignore - and you got a jump on the equipment modifications by seeing what was needed in advance. Some time ago the value of having a good cross section represented in these reviews became evident: nobody gets surprised, everyone shares their knowledge, and when the eqchine, two welding robots, the welding fixtures, two press piercers, the shuttles, the press welders, and the three automated material handling fixtures. Basically bringing back a foot print of 200 square feet from a process that covered 2500 square feet. The rest will go to salvage disposition while the hemmer goes to "hemmer heaven" - that place in your plant where some 200 different hemmers hang out until needed. That you only need the hemmer is where a key part of the plant's unique core competency comes to play. Rather than build a growing variety of product on some ACP - JIT Assembly Lines • Problem/Opportunity • Response Objectives • Response Issues/Metrics • Strategic Activity Web • Architecture & Integrity • Applied Principles • Closure Matrix • Conclusion & References RSA - JIT Assembly Lines Response Ability Model 3 MS PowerPoint Slides Operational Story ~ 2 MS Word Pages ~ 20-30 Pages Due as Deliverable #2

24. D1 Page 1-2: Operational Story • Note: All D1 pages 1-5 are about the system IN OPERATION. You MUST tell an after-deployment operational story or your RS Analysis (page 3) will probably be WRONG. This will then make your Closure Matrix (in the final) also WRONG. • Note: Unlike the older examples of operational stories – start your 2-page story with a one paragraph System Description, that clearly shows the system objectives, which address uncertain situations, and does so through reconfiguration while deployed. <system name> <authors name> <system description paragraph> xxxx xxx xxxxxxxxxxxxxxxxxxxxxxxx xxx xxxxx. <operational story> xxxxxxxxxxx xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxx xx etc xxxxxxxxxxx xxx xxxxxxxxxxxx xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxx xx etc

25. REVIEW Nov2011: www.tassimodirect.com/home-brewing-machines/hot-beverage-brewers

26. RSA for TassimoBrewBotIn-Operation System Creation Improve-ment Migration Modification (Capability) Correction Variation Expansion (Capacity) Reconfig-uration Response Issues (D1 Page 3: Remove example bullets and use this tool form or one exactly like it) Response Type Response Situations • What must the system be creating in the course of its operational activity? • Make different types of hot coffee and tea drinks (t,q,s) • What performance characteristics will the system be expected to improve during operational life cycle? • Match drink flavor to user taste (t,s) Proactive • What major events coming down the road will require a change in the system infrastructure? • Multi-lingual display text option (c,s) • Larger size water container capacity option (t,s) • Water filtration option (c) • Cold drinks? • What modifications in resources-employed might need made as the system is used? • Accommodate new drink discs (t,q,s) • Accommodate new drink brewing recipes ((t,q,s) • User wants manual recipe capability (q,s) • What can go wrong that will need an automatic systemic detection and response? • Available disc selection not satisfactory to user (t) • Improperly place disc and/or RFID registration (q) • What process variables will range across what values and need accommodation? • Amount of water called for by recipe (t,q) • Pressure of water called for by recipe (q,s) • Temperature of water called for by recipe (t,q,s) • User intelligence (q,s) Reactive • What are the key resource and/or performance bounds on necessary system response? • Small to large drink quantity (t,q,s) • Cup size physically accommodated (t,c,s) • What types of resource relationship configurations will need changed during operation? • Recipe brewing steps and sequence (t) • Multiple discs for a single drink (t,q)

27. RRS Principles for TassimoBrewbot In-Operation System (D1 Page 4: Remove example bullets and use this tool form or one exactly like it) • Evolving Standards (Framework)Component interaction standards, responsibilities/processes for evolving the standards. • Brewing sub-systems • Water quality standards • Recipe code • Product eng mgr responsible for evolution • Self-Contained Units (Modules) Components are distinct, separable, loosely-coupled, self-sufficient units. • Base units • Flavor discs • Display language • Recipes • RFID reader • Plug Compatibility (Facilitated Interfacing) Components easily inserted/removed, component evolution responsibility designated. • RFID recipe designator on bottom of disc • Product eng mgr responsible for module evolution • Redundancy and Diversity Duplicate components provides fail-soft & capacity options; diversity provides functional options. • Many different types of discs • User inventories as many duplicates as desired Reusable Scalable • Facilitated ReuseComponents are reusable and replicable; with responsibilities designated for inventory ready-for-use availability. • Foolproof easy in-and-out of discs • Product mktng mgr responsible for module inventory • Elastic Capacity Component populations and functional capacity be increased and decreased widely within the existing framework. • Recipe designates small to large amount of water • Cup size is adjustable with base elevator • No limit to variety of discs • Alternate base unit capabilities may be added Reconfigurable • Flat Interaction Components communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. • Recipes drive brew subsystems directly step by step • Distributed Control and Information Decisions made at point of maximum knowledge; information accessible globally but kept locally. • Control is in each RFID recipe, not in the base unit • Deferred Commitment Component relationships are transient when possible; decisions & fixed bindings are postponed until necessary. • Brew is determined by disc-inserted RFID recipe • Self-Organization Component relationships are self-determined; and component interaction is self-adjusting or negotiated. • Recipe reorganizes brewing steps Items here generally address issues on RS Analysis directly and indirectly

28. AAP for TassimoBrewBot In-Operation System (D1 Page 5: Remove example or use an appropriate form tool like it) Components Integrity Management brew steps discs recipes display text base units Product eng mgr Component mix Product mktng mgr Component inventory Automated recipe System assembly Prod eng mgr Infrastructure evolution Active Infrastructure espresso crème 2-step latte chocolate Passive Brew sub-sys protocol Water standards Recipe code RFID reader multilingual display Rules/Standards large water container

29. Last Planner Agile Project Management (D1 Page 5: another example) Active management of the anticipated schedule and work flow to ensure there isalways a buffer of “quality” jobs ready to work on and matched with resources. Components mastersched CPM tasks productionunits Integrity Management activitydefinitions tools materials equipment Project Manager Task elements: • Key Practices: • Rules 1-2-3 and • Lookahead • Make ready • Learn & Correct Supes/Foremen/Expediters Task readiness: Supes/Foreman Task assembly: Last Planner Process Manager Infrastructure evolution: week weekweekweekweekweek 65432 1 Active Infrastructure Passive Task Backlog Buffer Work Task Task Lookahead Window QR1: Definition QR2: Soundness QR3: Sequence QR4: Size QR = Task Quality Requirement Architectural Concept Pattern based on: (Ballard 1997) Lookahead Planning: the Missing Link in Production Control (Ballard 1998) Shielding Production: an Essential Step in Production Control (Ballard 1999) Improving Work Flow Reliability (Ballard 2000) The Last Planner System of Production Control-PhD Thesis Standards www.parshift.com/s/130624Last Planner.pdf rick.dove@stevens.edu, attributed copies permitted

30. First Pass: 12 O'clock Clockwise (if comfortable)Then Think-Across Until Consistent & Complete Projected Operational Story "When I am working on a problem, I never think about beauty, but when I have finished, if the solution is not beautiful, I know it is wrong." -- R. Buckminster Fuller Quality Evaluation Architectural Concept & Integrity Closure Matrix (Design) Response Situation Analysis Response AbilityTools & Process Reality Factors Identified RRS Principles Synthesis “Quality is practical, and factories and airlines and hospital labs must be practical. But it is also moral and aesthetic. And it is also perceptual and subjective.” -- Tom Peters ConOps Objectives & Activities

31. Avoid This Mid-Term Feedback • The Operational Story: Imagine yourself as the person who IS DOING the dragging-and-dropping to make the system respond to all manner of interesting “issues” in real time. Imagine you are a playing an instrument. You are the musician. Make some music – and describe how the instrument responds! • The Reactive and Proactive issues you listed are not from the operational-system point of view, but rather from the system-design point-of-view. You have listed the issues you will deal with as the designer rather than the issues the system will deal with in operation. What will the system have to create, for instance, not what you the designer has to create. • The Proactive and Reactive issues (problems) you listed are in fact solutions you expect to be using. This will become a problem when your closure matrix discussion describes how the application of "RRS principles" solves an "issue" (problem) within an "activity" – that discussion should be viewing these "issues" as things that have to be responded to, on the fly in an uncertain environment. • Migration issues are anticipated or likely changes to the infrastructure (framework) that will permit next-generation capability. Thus, anticipating IPv6 Internet protocol as an eventual replacement for IPv4 is proper, whereas anticipating a new type of node on the Internet is not, unless that new node type will also require a new infrastructure rule/protocol/standard for the Internet. • Your topic appears irrelevant to systems of interest in your professional employment. IF THIS IS CONFUSING…NOW IS THE TIME TO CLEAR IT UP

32. Avoid This Mid-Term Feedback • You forgot to show the metrics (tcqs) on your proactive/reactive issues. • The metrics you show for the “improvement” issues are simply a repeat of the improvement that has to be made. Page 74+ in the Text Book describes metrics as applying to the act of change, rather than the performance to be improved. Perhaps the cost of your process does have to be improved, but the metric to show on that issue is more likely time (t), if it has to be improved fast because you are bleeding dollars, or maybe scope (s), because your costs are 3x tolerable, or quality (q), because it has to be no more than 50% of the fixed-fee you will receive. • Your deliverable does not include one or more of the following:- Operational story – with strategic themes/objectives clearly stated- RS Analysis- RRS Principles applied- Architectural Concept PatternUseful feedback cannot be given without all of these present. Please complete the missing parts and resubmit asap. • You’ve got a mixed systems focus here and a confused picture emerges of what is being analyzed in the tools. The tools should analyze the system in the story, and the story should be clear about bounded system mission and methods. • You appear to have taken the quick and dirty rout – winging it on remembered or forgotten class hours and the words in the templates, with no real understanding of what they mean – study of the text book is expected, but apparently you’ve chosen to postpone that? IF THIS IS CONFUSING…NOW IS THE TIME TO CLEAR IT UP

33. From L3 Student • Thanks again for the great class. • It took a couple of days, but it finally occurred to me what agility was all about with regard to systems engineering. • I realized that when your developing an agile system, you’re really developing the “erector set” that can be assembled into a Farris wheel, as opposed to just building a Farris wheel. • ---------------- • You should think of design of an agile system as a design of a Lego set or erector set so that a user can assemble whatever they need whenever they need to in response to whatever the current situation requires.

34. Getting it Right • Download Unit 11, linked on your class page, and read it – it is a small collection of the slides from the 10 class units that pertain to the expectations for mid-term and final deliverables. • Read the Project Guidance document, linked on your class page, before you start your mid-term and final project, and again before you submit your mid-term and final project.

35. 4 Integrity Management Responsibilities(Agile Software Engineering Process Example) The “active” (governance) part of the infrastructure Module Mix/Evolution: New module addition and upgrade as new capabilities are needed (new developer skills, newly developed code modules, new test suites for new code, new procedures as indicated by a changing situation, user representatives intimate with next stage feature development needs, etc). • System assembly: configure modules into on-demand system configurations suitable for changing response needs (successive iterations in the development process). • Module Inventory Readiness: Maintaining sufficient inventory of modules ready for use (development people, team leaders, engagement procedures, reusable code modules, reusable test suites, etc). Infrastructure evolution: improvements to existing rules and standards, new rules and standards. Paper at: www.parshift.com/Files/PsiDocs/Pap080614GloGift08-LifeCycleMigration.pdf

36. In-Class Tool Applications • Class Warm-ups Team Trials Team Project • Unit 2 • Unit 3 • Unit 4 • Unit 5 • Unit 6 • Unit 7 • Unit 8 • Unit 9 • Unit 10 AAPAnalysis: Case ConOps: Objectives RA Analysis: Case Reactive/Proactive RA Analysis: TWS RS Analysis RRS Analysis: Case Framework/Modules RRS Analysis: TWS RRS + Integrity Reality Factors: Case Reality + Activities Integrity: TWS Closure

37. Exercise Make ready for presentation start of next session Generate one new slide, refine another • Ideas for how the 10 RRS principles might be employedon your team project. • Refine previous architectural concept diagram andadd 4 integrity management responsibilities.

38. RRS Principles for System: ________________________ (Think: Plug-and-Play, Drag-and-drop) Evolving Standards (Framework)Component interaction standards, responsibilities/processes for evolving the standards. x Self-Contained Units (Modules) Components are distinct, separable, loosely-coupled, self-sufficient units. x Plug Compatibility (Facilitated Interfacing) Components easily inserted/removed, component evolution responsibility designated. x Redundancy and Diversity Duplicate components provides fail-soft & capacity options; diversity provides functional options. x Reusable Scalable Facilitated ReuseComponents are reusable and replicable; with responsibilities designated for inventory ready-for-use availability. x Elastic Capacity Component populations and functional capacity may be increased and decreased widely within the existing framework. x Reconfigurable Flat Interaction Components communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. x Distributed Control and Information Decisions made at point of maximum knowledge; information accessible globally but kept locally. x Deferred Commitment Component relationships are transient when possible; decisions & fixed bindings are postponed until necessary. x Self-Organization Component relationships are self-determined; and component interaction is self-adjusting or negotiated. x