school of systems and enterprises stevens institute of technology, usa

6:1 [email protected], attributed copies permitted

ES/SDOE 678Reconfigurable Agile Systems and EnterprisesFundamentals of Analysis, Synthesis, and Performance

Session 6 – Synthesis: Design Exercise and Strategy Refinement

School of Systems and EnterprisesStevens Institute of Technology, USA

mailto:[email protected]


NO 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).

This afternoon you should know your term project topic.



Guest Speaker: Joe Justice Hallway Open Q&A

Recorded 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.parshift.com/s/JusticeJoe-Agile2012HallwayQandA-50-60min.mp4Transcript at: www.parshift.com/s/JusticeJoe-Agile2012HallwayQandA-50-60min-Transcript.pdf

File50-60Transcript


http://www.parshift.com/s/JusticeJoe-Agile2012HallwayQandA-50-60min.mp4

http://www.parshift.com/s/JusticeJoe-Agile2012HallwayQandA-50-60min-Transcript.pdf


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. Object Oriented: clearly defined modules and interfaces. Kanban: work in progress limits (make sure someone’s not overloaded).


http://bcove.me/zcryseb7


Principles of Joe’s WikiSpeed Approach16-18 May 2011 Global Scrum Gathering, Seattle, Our Process, Video: http://bcove.me/zcryseb7

1. 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).

2. By loosely coupling modules we make changes in parallel (many people working on alternate approaches to modules).

3. 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).

4. 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).

5. Tests are the success criteria.6. Team morale is a multiplier for velocity (large part of progress success).7. 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).




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.




ObservationsAgile 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?



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


http://www.infoq.com/articles/real-options-enhance-agility


Example: Scrum Agile Architecture Pattern (AAP)Details in www.parshift.com/s/140630IS14-AgileSystemsEngineering-Part1&2.pdf

Infrastructure

Sprint n Sprint RetrospectiveScrum Meeting

Resources

Rules/Standards

IntegrityManagement

Active

Passive

Product OwnersDevelopers/

TestersScrum Masters Stakeholders

Retrospective Change

Product Backlog

SocketsSignalsSecuritySafetyService

Peer-Peer InteractionDaily Scrum InfoTrustworthy TransparencyCollaborative ReviewProcess Rules & ConOps

Situational awareness

Resource mix evolution

Resource readiness

Activity assemblyInfrastructure evolution

PO with Team Collaboration

Product Owner (PO)Self Organizing

Scrum Master, Developers/TestersEverybody


http://www.parshift.com/s/140630IS14-AgileSystemsEngineering-Part1&2.pdf


In-Class Tool Applications

Class Warm-ups Team Trials Team ProjectUnit 2

Unit 3

Unit 4

Unit 5

Unit 6

Unit 7

Unit 8

Unit 9

Unit 10

ConOps: Objectives

CURVE & Reality

RSA Analysis

AAP

RRS Synthesis

RSA Analysis: TWS

RRS Analysis: TWS

Integrity: TWS

Reality Factors: TSA

RSA Analysis: Tassimo

RRS Analysis: Multiple

ConOps: Activities

Closure

AAP Analysis: Football



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.

1. Discuss what you saw in the videos and compare notes amongst your team. 2. 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.



Team Wikispeed Agile Engineering ProcessGraphic template for your modification

aaa cccbbb ddd eee fff

Infrastructure

Config 2 Config nConfig 1

Resources

IntegrityManagement

Active

Passive



Resource mix evolutionResource readiness


Who?

Who?Who?Who?

Who?

What?What?What?What?What?



Reconfigurable

Scal

able

Reusable

Encapsulated Modules Modules are encapsulated independent units loosely coupled through the passive infrastructure.?

Facilitated Interfacing (Pluggable) Modules & infrastructure have features facilitating easy module insertion/removal.?

Facilitated Reuse Modules are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules.?

Peer-Peer Interaction Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. ?

Deferred Commitment Module relationships are transient when possible; decisions & fixed bindings are postponed until necessary.?

Evolving Infrastructure ConOps and module interface and interaction standards and rules that evolve slowly.?

Redundancy and Diversity Duplicate modules provide fail-soft & capacity options; diversity provides functional options.?

Elastic Capacity Module populations & functional capacity may be increased and decreased widely within the existing infrastructure.?

Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally.?

Self-Organization Module relationships are self-determined; and component interaction is self-adjusting or negotiated. ?

(Think: Plug-and-Play, Drag-and-drop)RRS Principles for System: ________________________


FEEDBACK REVIEW


BREAK



“Facilitated” Re-Usewww.wikispeed.com/wikispeed-team-blog/what-do-we-mean-by-modular

22Mar2012 posting on WikiSpeed blog:“Here's a 4 minute video of a Jeep getting torn down and reassembled: http://www.wimp.com/rebuildjeep/ Sent in by Team WIKISPEED member Bob Stuart. He titled the post "Historic Modularity."“This is awesome, and good to see the evidence of how modularity has evolved.” “As it sits - what Willys did in 1941 was amazing - they maximized the speed and efficiency to swap interchangeable parts.”

File4.0


http://www.wikispeed.com/wikispeed-team-blog/what-do-we-mean-by-modular

http://www.wimp.com/rebuildjeep


Midterm Homework Prep

Important – You are responsible for:1. Reading the Project Guide and following its instructions2. Emailing completed mid-term homework to the Instructor

by Monday 2 weeks after this class session

D1: due nlt Monday 2 weeks after first class

D2: due nlt Monday 6 weeks after last class



You Are There – Inside The System Looking OutThis is the tone an operational story should exhibit.

Readable text can be downloaded from:www.parshift.com/Files/Essays/Essay033.pdf


http://www.parshift.com/Files/Essays/Essay033.pdf


Tour-guide us through your system

Carnegie Mellon Engineering, Spring 2006

Describeyour system

during responsivere-configuration


6:20 [email protected], attributed copies permittedIllustration by Christopher Brand

Put your mindin the future.

Imagine your system in operation.

Watch it respond to unexpected circumstances.

Dream about it – then

write about it.



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/


http://www.amazon.com/gp/product/images/1400064287/sr=1-1/qid=1216404875/ref=dp_image_0?ie=UTF8&n=283155&s=books&qid=1216404875&sr=1-1



The Curse of Knowledge “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






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?


Random House, 2007





Unforgettable StoriesA friend of mine is a frequent business traveler. Let's call him Dave. A few years ago Dave was 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/



Grading (Individual Term Project – Not Teams)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 deliverableTwo-page operational story: clear evidence of an

agile system in operation demonstrated with environment CURVE, response objectives, requirements, values, response enabling principles, and operational/integrity management.

Three-element response ability model: relevance and clarity of key concepts in RS Analysis, RRS Principles, and Architectural Concept Pattern diagram.

Evidence of study: knowledgeable reference to the literature and readings.

60% on conceptual design report – Final deliverableArticulate 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.

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.

due nlt Monday 22 May

due nlt Saturday 22 Jul



Course Project (Individual Student work, no Teaming)(always refer to www.parshift.com/AgileSysAndEnt/ProjGuide/678ProjGuideCurrent.pdf for current requirements)

A newly builtcustom assemblyline for each andevery small-batchrun, every time, justin time.

Life with System X – Agility in ActionBy Rick Dove, Paradigm Shift International, e-mail: [email protected], 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

• Problem/Opportunity/CURVE• Response Objectives• Reality Factors• Response Issues/Metrics• Strategic Activity Web• Architecture AAP & Integrity• Applied RRS Principles• Closure Matrix• Conclusion• References

DetailedConceptual Design

Documentation----------------

Comprehensiveto one

Skilled in the Arts

Response Ability Model3 MS PowerPoint Slides

5 Page Operational Model - Due as deliverable #1

Operational Story~ 2 MS Word Pages

~ 20-30 PagesDue as Deliverable #2

Includes strategic objectives/themes

Operational Story

RSA - JIT Assembly Lines

RRS - JIT Assembly Lines

ACP - JIT Assembly LinesAAP


http://www.parshift.com/AgileSysAndEnt/ProjGuide/678ProjGuideCurrent.pdf


D1 Pages 1-2: Operational StoryNote: 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.

<system name><authors name>

<system description paragraph> xxxx xxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx.

<system environment CURVE>

<operational story> xxxx xxxxxxx xxxxxxx xxxxx xxxxxxxxxxx xxxxxxxx xxetc

xxxx xxxxxxx xxx xxxxx xxxxxxx xxxxxxx xxxxx xxxxxxxxxxx xxxxxxxx xxetc



Case Example: Electric Distribution Substation DesignAccurate and rapid designs with low-experience engineers, under: Capricious time to gain construction permits Uncertain availability of competent design engineers Uncertain cost and schedule of transformer delivery Risk of canceled substation need Variable engineer substation-design experience Evolving power-capacity requirements for substation(Note: above only shows reactive CURVE elements, need proactive also)

Reputation Goals:• Easy, rapid, predictable design• Accurate costing• Predictable installation completion• Low spares-inventory costs• Construction exactly as shown in city/county permit approval

Case: Public Service New Mexico (PNM)



RSA Example: Electric Distribution Substation Design

• Substation design (tp)• Bill of materials (tp)• Construction permit approval (tp)

Correction

Variation

Reconfiguration

Expansion(of Capacity)

Migration

Improvement

Modification(of Capability)

Creation(and Elimination)

Proa

ctiv

eR

eact

ive

Change Domain

• Time to permit approval (ts)• Time to construction completion (s)• Cost of spares inventory (ts)• High voltage H configurations (cp)• Transmission right-of-way fly-through configurations (cp)

• Upgraded transformer incorporation (tc)• Engineer substation-experience maturity (t)• Wrong capacity requirement (tc)• Inadequate engineer (tp)• Transformer delivery too far out (tc)• Expertise and skill levels among engineers (ps)• Time allowed to complete the project (ps)

• Power capacity range to 9x over base capacity (tp)

• Substation power capacity (tcs)• Inventory spare transformers used in new construction (t)

(D1 Page 3: Remove example bullets and use this tool form or one exactly like it)



Reconfigurable

Scal

able

Reusable

Encapsulated Modules Modules are encapsulated independent units loosely coupled through the passive infrastructure.• engineers, transformers, switchgear, transmission

termination structures, low-voltage feeder circuits, station steel

Facilitated Interfacing (Pluggable) Modules & infrastructure have features facilitating easy module insertion/removal.• Drag and Drop DASL operation• DASL flags improper module-mating

Facilitated Reuse Modules are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules.• Drop-down menus for selecting modules

Peer-Peer Interaction Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. • Designers communicate directly with permitting agency

to secure approvals• Designers communicate directly with inventory

management to ensure availabilityDeferred Commitment Module relationships are transient when possible; decisions & fixed bindings are postponed until necessary.• Quick design time enables design commitment at last

responsible moment

Evolving Infrastructure ConOps and module interface and interaction standards and rules that evolve slowly.• DASL design tool ConOps• DASL module interconnects, Construction

policies/regs

Redundancy and Diversity Duplicate modules provide fail-soft & capacity options; diversity provides functional options.• Multiple engineers capable of designing• Experience of engineers can vary

Elastic Capacity Module populations & functional capacity may be increased and decreased widely within the existing infrastructure.• Peak design-time activity can employ many easily-

qualified design-engineers

Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally.• Transformer designers work independent of substation

designers, maintaining interconnect standards

Self-Organization Module relationships are self-determined; and component interaction is self-adjusting or negotiated. • Trust relationship between designers and permitting

agency is self-organized evolution

(D1 Page 4: Remove example bullets and use this tool form or one exactly like it)RRS Principles for Electric Distribution Substation Design

Items here generally address issues on RS Analysis directly and indirectly



HH

engineers switchgeartransformers terminationstructures

low-voltagefeeders

stationsteel

Infrastructure

H Station Fly-Thru StationT Station

Resources

Rules/Standards

IntegrityManagement

Active

Passive

T T H H H

TT

SocketsSignalsSafetySecurityService

DASL module interconnectsSubstation requirementsConstruction policies/regsNo development customizationDASL design tool ConOps

H-pad standardsFly-pad standards


Resource mix evolutionResource readiness

Activity assemblyInfrastructure evolution chief engineer

design engineer

DASL program mgr min/max purchaser

project & chief engineer

AAP for Electric Distribution Substation Designwww.parshift.com/Files/PsiDocs/Pap080404Cser2008DevOpsMigration.pdf

Agile Architectural Pattern Diagram(D1 Page 5: Remove this example’s detail, or use an appropriate form like it)


http://www.parshift.com/Files/PsiDocs/Pap080404Cser2008DevOpsMigration.pdf


Case Example: Scrum Software DevelopmentWorking/delivered software under: Capricious requirements revelations, additions, and changes Uncertain feasibility of initial solution design plan Risk of unacceptable cost increases Risk of failure to meet necessary schedule Variation in development team-member capability Variation in effectiveness of customer involvement Evolution of incremental change in targeted operating environment(Note: above only shows reactive CURVE elements, need proactive also)

Reputation Goals:• Customer satisfaction with completed/delivered project• On time• On budget



• Situational awareness (t, p, s);• project management strategy (t); project team (t, c); system requirements (t, p);• system architecture (t, s); system design (t, c, p); development activity plans (t);• V&V/test plans (t); team collective understanding and learning (t, p); experiments (t, c, s).

RSA Example: Scrum Software Development

Correction

Variation

Reconfiguration

Expansion(of Capacity)

Migration

Improvement

Modification(of Capability)

Creation(and Elimination)

Proa

ctiv

eR

eact

ive

Change Domain

• activity effort estimating (p); • activity completion to schedule (t, c, p); • reducing uncertainty and risk (t, p, s);• process effectiveness (t).

• new technology/tools that will impact infrastructure (t, c, s);• project scope change (s);• lean process principles (p).

• new added team member unfamiliar/uncomfortable with management strategy (t); • new environmental dynamics (t, c, p, s).

• inadequate situational awareness (t); • wrong requirement (t);• inadequate developer (t); • failed V&V/test (t, c); non-compliant supplier (t, c).• expertise and skill levels among team members (p); • grace period on schedule (t, c); • deliverable performance range (p); • availability, interaction, and expertise of customer involvement (s).

• 2x (or half x) project scope change (t, c, p, s);• team-size changes of x-y engineers distributed across n-m locations (t, s).

• unanticipated expertise requirement (t); • development activity-sequence priority change (t);• system/sub-system design change (t).

(D1 Page 3: another example)



Reconfigurable

Scal

able

Reusable

Self-Contained Units (Modules) Modules are encapsulated independent units loosely coupled through the passive infrastructure.• Product Owners, Scrum Masters, Developers, Testers,

Backlog items, Stakeholders

Facilitated Interfacing (Pluggable) Modules & infrastructure have features facilitating easy module insertion/removal.• Common team-based culture, common process rules

for interactions

Facilitated Reuse Modules are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules.• Cross trained developers/testers, common Product

Owner and Scrum Master training, backlog displayed visually

Peer-Peer Interaction Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored.

•All-hands Scrum meetings, collaborative Sprint planning and backlog prioritization,

Deferred Commitment Module relationships are transient when possible; decisions & fixed bindings are postponed until necessary.• Backlog burned down on priority basis, requirements

firmed at last responsible moment, functional architecture emerges

Evolving Infrastructure ConOps and module interface and interaction standards and rules that evolve slowly.• Process rules and ConOps, Trustworthy

transparency, Peer-peer interaction, Daily Scrum info, Collaborative Sprint and process review

Redundancy and Diversity Duplicate modules provide fail-soft & capacity options; diversity provides functional options.• Multiple trained Scrum Masters and Product Owners,

multiple developers/testers with some special competencies

Elastic Capacity Module populations & functional capacity may be increased and decreased widely within the existing infrastructure.• Teams of 5-7, scalable number of teams, scalable

Scrum of Scrums

Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally.• Task completion individually determined locally, visual

and accessible progress and planning status updated globally

Self-Organization Module relationships are self-determined; and component interaction is self-adjusting or negotiated. • Team member working relationships, user-story and

task self-choosing, self/collaborative time estimating, collaborative Sprint-scope acceptance

(D1 Page 4: Remove example bullets and use this tool form or one exactly like it)RRS Principles for Scrum Software Development

Items here generally address issues on RS Analysis directly and indirectly



Infrastructure

Sprint n Sprint RetrospectiveScrum Meeting

Resources

Rules/Standards

IntegrityManagement

Active

Passive

Product OwnersDevelopers/

TestersScrum Masters Stakeholders

Retrospective Change

Product Backlog


Peer-Peer InteractionDaily Scrum InfoTrustworthy TransparencyCollaborative ReviewProcess Rules & ConOps


Resource mix evolution

Resource readiness


PO with Team Collaboration

Product Owner (PO)Self Organizing

Scrum Master, Developers/TestersEverybody

AAP for Scrum Software Development(D1 Page 5: another example)



"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

OperationalStory with

CURVEReality Factors

Identified

ResponseSituation Analysis

AgileArchitecture

PatternRRS

Principles Synthesis

ConOpsObjectives& Activities

ClosureMatrixDesign

QualityEvaluation

RAPTools & Process

We discussed the yellow boxes.All lectures will show what has been discussed like this.



Avoid This Mid-Term Feedback1) 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!2) 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.3) 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.4) 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. 5) Your topic appears irrelevant to systems of interest in your professional employment.

IF THIS IS CONFUSING…NOW IS THE TIME TO CLEAR IT UP



Avoid This Mid-Term Feedback6) You forgot to show the metrics (tcqs) on your proactive/reactive issues.7) 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.8) 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.9) 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. 10) 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



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.



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.

Declare your term project topic now,and send it to me in an email

(or talk to me after class if undecided).



5 Integrity Management Responsibilities(Agile Software Engineering Process Example)

The “active” part of the infrastructure

Resource mix evolution: New resource 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).

Resource readiness: Maintaining sufficient inventory of resources ready for use (development people, team leaders, engagement procedures, reusable code modules, reusable test suites, etc).

Situational awareness: Proactive diligence and alertness to finding and recognizing threats and opportunities to process and product sustainability.

System assembly: configure resources into on-demand system configurations suitable for changing response needs (successive iterations in the development process).

Infrastructure evolution: improvements to existing process ConOps and interface standards, new rules and standards.

Paper at: www.parshift.com/Files/PsiDocs/Pap080614GloGift08-LifeCycleMigration.pdf


http://www.parshift.com/Files/PsiDocs/Pap080614GloGift08-LifeCycleMigration.pdf


In-Class Tool Applications

Class Warm-ups Team Trials Team ProjectUnit 2

Unit 3

Unit 4

Unit 5

Unit 6

Unit 7

Unit 8

Unit 9

Unit 10

ConOps: Objectives

CURVE & Reality

RSA Analysis

AAP

RRS Synthesis

RSA Analysis: TWS

RRS Analysis: TWS

Integrity: TWS

Reality Factors: TSA

RSA Analysis: Tassimo

RRS Analysis: Multiple

ConOps: Activities

Closure

AAP Analysis: Football



Exercise

Make ready for presentation start of next session

Generate one new slide, refine another1)Ideas for how the 10 RRS

principles might be employedon your team project.

2)Refine previous Agile Architectural Pattern as appropriate.



Reconfigurable

Scal

able

Reusable

Encapsulated Modules Modules are encapsulated independent units loosely coupled through the passive infrastructure.?

Facilitated Interfacing (Pluggable) Modules & infrastructure have features facilitating easy module insertion/removal.?

Facilitated Reuse Modules are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules.?

Peer-Peer Interaction Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. ?

Deferred Commitment Module relationships are transient when possible; decisions & fixed bindings are postponed until necessary.?

Evolving Infrastructure ConOps and module interface and interaction standards and rules that evolve slowly.?

Redundancy and Diversity Duplicate modules provide fail-soft & capacity options; diversity provides functional options.?

Elastic Capacity Module populations & functional capacity may be increased and decreased widely within the existing infrastructure.?

Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally.?

Self-Organization Module relationships are self-determined; and component interaction is self-adjusting or negotiated. ?

(Think: Plug-and-Play, Drag-and-drop)RRS Principles for System: ________________________


school of systems and enterprises stevens institute of technology, usa

Documents

agile methods

agile coach

reconfigurable agile

engineering of agile

practical agile knowledge

practical agile terms

agile development processand

xprize car