2012/04/08 IEEE Software Technology Conference

by Gene Kim on

#ieee

IEEE 25th Annual Software Technology Conference
Salt Lake City
http://sstc-online.org/schedule/schedule.cfm?pg=sc

Plenary Session

Mr. Paul Croll, VP Technical and Conference Activities

  • At 25th year, this is a long running conference. Air Force lost funding for the program last summer, IEEE took over stewardship

Plenary Session:

Mr. Lloyd Moseann, former Asst Secretary of the Air Force for Acquisition (Communications, Computers and Support Systems, and STC founder)

  • Moseann: "I'm a bit of an antique; at the 1st conference, it was all government; now it's all industry"
  • Moseann: 12 yrs ago: 1988: different world: "gallon of gas 98 cents; sw engineering non-existant; not many cell phones"
  • Moseann: "Dept of Defense has extremely high reliance on software; now $1.5 trillion portfolio value annually
  • Moseann: "1985: birth of Software Tech Conf: 7/10 weapon systems in trouble b/c of software: projects late b/c sw as art
  • Moseann: "NATO coined term: 'Software Crisis': projects over budget/schedule/inefficient/low quality/or never delivered"
  • Moseann: "2nd STC: 4/19/1989: Pentagon told world: C-17 program over budget/schedule b/c software; plane is ready, but no sw
  • Moseann: "Fear was C-17 would be on runway, but still waiting for software to load on it; major factor was cultural/sociological
  • Moseann: "You can't see, touch or feel software; made it difficult to convince generals of importance" (no diff than now w/CEOs!)
  • Moseann: "1980s was a lost decade for software dev; wondered back then whether 1990s wd be better: thot 're-use' was ray of hope
  • Moseann: "Pentagon wasn't concerned abt sw cost: instead, it was on predictability: could orgs ever deliver on their promises?"
  • Moseann: "2002: stated world of software was still governed by faith based mgmt, bumper sticker mgmt
  • Moseann: "'best practices' does not exist with defense contractors; trying to convince that contractors are well trained"
  • Moseann: "1991: Paul Strassman: '#1 priority is to turn software from cottage industry into modern industrial method of production
  • Moseann: "2012: Joint Strike Fighter: 24MM lines of code; sw has delayed testing/training & added costs; capabilities being delayed
  • Moseann: "Apparently, Air Force things software problem is fixed, since Bold Stroke program has been canceled
  • Moseann: "We must acquire product as well as process; we need transform doctrine and policy into reality in the acquisition & development of complex systems dependent on software"
  • Moseann: "Must happen first at Military Dept Level, and again at Acquisition Program Manager Level: and must include Architecture"
  • Moseann: "Architecture Driven programs: embedded in acquisition and RFP process: Army Integrated Battle Command Systems; AF Joint Mission Planning Systems; Navy Common Link Integration Processing; Navy DDG-1000; Army Warfighter Information Network Tactical
  • Moseann: "Most hopeful: Army's Strategic Software Improvement Program (ASSIP): in 2010, mandated software architect in every program
  • Moseann: "Let's hope that there's enough software architects out there"
  • Moseann: "from SEI: 1/3 of reporting orgs failed to have CMM Level 3; 58% USA software orgs > 3 or above; 78% non-USA > 3 (!!)
  • Moseann: "5x are many CMMI Level 3 or above are outside of the US"
  • Moseann: "It saddened me to hear friend say, 'CMMI no longer has traction in OSD, you shouldn't even talk about it"
  • Moseann: "Orgs, govt & mgrs must recognize difference betw Performance they value & Discipline needed to achieve results
  • Moseann: "Recommended book: 'Balancing Agility and Discipline': by Boehm http://www.amazon.com/Balancing-Agility-Discipline-Guide-Perplexed/dp/0321186125"
  • Moseann: "3 choices; 1) rise up in shocked indignation & accuse me of irresponsible reporting;

Dr. Paul Nielsen, Director and CEO, Carnegie Mellon University's Software Engineering Institite

  • former major general
  • trained as a physicst, 1965 learned to program in Fortran, even before learning physics
  • timecards was hard: over night batch jobs, no feedback, long lead times
  • Nielse: "at NRO for national satellite reconnaissance; back then, no memory on satellites, so processing done on ground"
  • Nielsen: "now satellites are all software
  • Nielsen: "Rutherford fan: best experimentalist: Einstein called him '2nd Newton,' won Nobel Prize in chemistry; father of nuc physics
  • Nielsen: "Discovered that atom is mostly empty; Rutherford diffraction experiment; first alchemist; build Geiger counter w/student Geiger
  • Nielsen: "1) nature of radioactivity; 2) first person to split atom"
  • Nielsen: "1) surviving tough times; 2) importance of software; 3) roles & responsibilities as scientists for engineers"
  • Nielsen: "we must form the nucleus of
  • Nielsen: "only thing people are willing to reduce are congressional salaries or foreign aid; how about growing economy (software) and cutting expenses
  • Nielsen: "Is this really the toughest time ever? Really? Maybe we're not facing up to challenge: Civil War, Grt Depresion, WWII
  • Nielsen: "Or 1960s: civil rights struggle, anti-war protests, cities burning, US Army firing on our own citizens; 2008 world economic disaster
  • Nielsen: "Come on, we must face up to our responsibilities: every generation
  • Nielsen: "Rutherford: 'Now we are out of money; now we must think'"
  • Nielsen: "All of scientists and engineers must speak up about what we think is important"
  • Nielsen: "Tough times are the incubators of great organizations; they're the crucible of innovation/creativity
  • Nielsen: "In Rutherford time: many thought all tough physics were solved: except black body problem, matter/wave duality, atomic stability, etc... People thought we could live with those" (haha)
  • Nielsen: "SW engineering: Discipline works; Agile works; Boehm is a great book; they support each other; we've been thru out software adolesence
  • Nielsen: "Our inconsistencies: sw is too important to not know how to build it right"
  • Nielsen: "Software is important: it allows commodity chips to do infinite # of things for us; brings it to life
  • Nielsen: "We all know abt Moore's Law: Scientific knowledge doubled every 10 yrs, in every field since 1600s"
  • Nielsen: "Knowledge doubling happens b/c we build on accumulated data; in software, too often, we write things from scratch"
  • Nielsen: "Most cars have 180M+ lines of code; why does JSF not work w/only 24M lines of code? Humility." (fixed typo)
  • Nielsen: "When we threw out all the software regulations, we threw away 40-50 years of knowledge on procurement"
  • Nielsen: "Coupling adds to complexity; we need to find architectural techniques; we need loose coupling"
  • Nielsen: "We need systems view: we no longer need to use silicon and carbon talents; architecture is the key"
  • Nielsen: "quality attributes are so important; in AF, we called them non-functional requirements (systems vs. software speak)
  • Nielsen: "What software calls 'non-functional requirements', systems thinking calls 'quality attributes': security, operability
  • Nielsen: "My opinion on most important non-functional req: 'evolvabiliity': the ability for systems to chg over time"
  • Nielsen: "Best example of evolvability: B-52, nearing 70 yrs old; every system designed to replace it failed"
  • Nielsen: "Software engineering is most vibrant place to be. Everything depends on it; nothing is more critical"
  • Nielsen, SEI CEO, addressing Dept of Defense crowd on software; most attendees couldn't attend, b/c budget sequestration. ARGH!!
  • Nielsen: "Time from Sputnik to landing men on moon: 12 years; Transister only 60 yrs old;
  • Nielsen: "Pace of advancement is breathtaking; now more engineers & scientists working than ever; more probs will be solved in our lifetime
  • Nielsen: "2008 Great Recession: consequence of interconnectedness of all things"
  • Nielsen: "Infosys CEO: company started with $250, now $45B market cap; credits SEI CMM and CMM-I that made it all possible
  • Nielsen: "The irony: we all like seeing so much of India coming out of poverty; but why can't we see more of that happening in US?
  • Nielsen: "Snow: wrote extensively on science and government: scientists & tech bring foresight to policy & govt
  • Nielsen: "Asimov 1st law: When an elderly distinguished scientists says something is possible, she's right; if she says something is impossible, she's most certainly wrong"
  • Nielsen
  • Nielsen: "Asimov: when scientist says something is possible, she's prob right; if she says something is impossible, she's wrong"
  • Nielsen: "Scientist Bartender Law: As scientist, if you can't explain your theory to a bartender, your theory is wrong."
  • Nielsen: "talking about values of giving to students; if you're just a member of IEEE, you're missing out on so much; and be active on schools"
  • Nielsen: "Newton: if i've seen further than others, it's because I'm standing on the shoulders of giants"
  • Nielsen: "Agile got it right: people do great things, not processes; exceptional people do exceptional things"
  • Nielsen: "Many govt workers/contractors have gone 4 yrs w/o pay raises, now having pay cut; we're out of money, time to think!"

Day 2

Dr. Barry Boehm: "Skating To Where The Puck Is Going: Future Trends In Software Intensive Systems

  • TRW Professor of Software Engineering and Director (USC Center for Software Engineering)
  • former DISA director, http://csse.usc.edu
  • On "Future Proofing Opportunities and Challenges"
  • Gretzky: "What helped me most in becoming a good hockey player was learning to skate to where the puck was going, rarther than where it was or where it had been"
  • Boehm: "Reflection in action" or asking how could we have done our last project better" is actually merely optimizing bureaucracy
  • Boehm: "8 surprise free trends: increasing integration of syse and swe; user value focus; software criticality and dependability; rapid, accelerating change; distribution, mobility, globabliztation; complex systems of systems; COTS and open source and reuse; computational plenty"
  • Boehm: "Wild cards: autonomy software; combinations and biology and computation"
  • Boehm: "Biggest 2013 trends missed in 2006: nanotech sesnors; search and mining of ultralarge data aggregations; multicore cips; cloud computing; social networking"
  • Boehm: "top 2013 surprise-free trends: rapid, accelerating chgs; software criticality, complexity; COTS & open source; datamining
  • Boehm: "More than ever, we need agility & continuous learning: balance agility & plan driven dependability
  • Boehm: "must eradicate THWADI (that's how we've always done it): administrative THWADI kills technical agility"
  • Boehm: "Emergence of Architected Agile Approach: using scrum of scrums: 10 teams of 10 people: going to three lvls seem infeasible
  • Boehm: "sprint 0: 2-12 weeks; then 1 month sprint intervals
  • Boehm: "US PITAC report: 'the IT industry spends bulk of its resources..on rapidly bringing products to market [vs fixing defects]
  • Boehm: "Prediction: by 2025, there will be a 9/11-scale software failure that will elevate priority of sw engineering
  • Boehm: showing awesome chart of conflict of rapid change vs. high assurance (V&V exercises):
    https://pbs.twimg.com/media/BHaoLc1CAAAtoj8.jpg
  • Boehm: "pattern of high assurance may be specialized team that critiques"
  • Boehm: "lack of integration among stovepiped systems causes: unacceptable delays in svc, uncoordinated & conflicting plans...
  • Boehm: "...ineffective or dangerous decisions, inability to cope with fast-moving events
  • Boehm: "What are the benefits of agility? You see first; understand first; act first" (which typically result in winning)
  • Boehm: "On COTS, open source, services, legacy integration
  • Boehm: "It's not all about programming anymore: in 1990s: it was 72% of effort; now less than 20%; remainder: COTS & cloud
  • Boehm: hahaha! how depressing legacy systems are for sci-fi fans: look at "1939 city of future" vs today
    https://pbs.twimg.com/media/BHaqFz4CAAAs86p.jpg
  • Boehm: "Today's skyline doesn't match 1930 sci-fi mag covers: we have potholes, bldgs look like 1930s, same materials
  • Boehm: "Trend: megasensor-empowered smart systems: smart power grids: EU digital agenda 'internet of things'
  • Boehm: "Imagine thousands of sensors, each generating 1Gb/sec of data
  • Boehm: "Google generates billions of search hits, all in 0.3 to 0.5 seconds"
  • Boehm: "Computerworld panel: more focus on user/ownership costs & benefits; less focus on features & license costs
  • Boehm: "User orientation has many challenges: Emergent needs and priorities: IKIWISI (I'll know it when I see it)
  • Boehm: "Golden Rule: do unto others as you would have others do unto you"
  • Boehm: "(as opposed to Programmer's Interpretation: optimize for programmers)
  • Boehm: "Platinum rule: do unto others as they would be done unto"
  • Boehm: "Value based testing: empirical data and ROI: LiGuo Huang: 20% of cases test 80% biz value
    https://pbs.twimg.com/media/BHasNkzCAAAwPhs.jpg
  • Boehm: "Startling conclusion: After you run 35% of test cases, every test you run loses the business money" (!!!!)
  • Boehm: "Computational plenty: you can use cpus to do: assertion checking, intrusion detection, trend analysis, Monte Carlo simulation
  • Boehm: "You can't do good software engineering (SwE) by neglecting systems engineering (SysE)
  • Boehm: "You can't do good SysE by neglecting critical success factors
  • Boehm: "Wildcards: autonomy and bio computing: Potential for good: robot labor, redesigning world for higher quality of life
  • Boehm: "Downsides: loss of human primacy (computers propose, humans decide); overempowerment of humans (accidents, terrorism)
  • Boehm: "Downsides: new failure modes (adaptive control instability, self modifying software, commonsense reasoning)" (oh no. haha)
  • Boehm: "Conclusions & future proofing: incremental vs start-over tools & methods (eg, formal methods)
  • Boehm: picture of his research agenda
    https://pbs.twimg.com/media/BHat395CUAAdpqv.jpg
  • Boehm: his slide on future -proofing processes
    https://pbs.twimg.com/media/BHauQRiCcAIVG0Q.jpg
    • Boehm: "No longer any clear boundary between dev and ops
  • Boehm: "We can no longer pre-specify what we want. Doesn't match current DoD acq process w/master schedule & master plan
  • Boehm: "Worse, sched/cost overruns typically result in project cancellation; erasing all data on emergent processes/outcomes
  • Boehm: "Current university students will be practicing SysE into 2050s; so, we must teach them timeless principles
  • Boehm: "When deciding Agile vs. Plan Driven, ask 'where are the change hotspots?; think UI vs. dealing w/device drivers"
  • Q: "as engineer, I don't see contract until it's signed. how do I influence contract manager?" A: "DoD should do more competitive prototyping, to see what creative companies can do, instead of seeing what integrators propose; they're doing more draft RFPs, but not as much as they should"

Dr. Vic Basili: "Aligning An Org's Goals & Strategies Thru Measurement: GQM*Strategies"

Professor Emeritus of Computer Science, University of Maryland

  • Basili: "need to develop & connect goals to all levels of the org"
    https://pbs.twimg.com/media/BHazKL9CAAAWfbx.jpg
  • Basili: "GQM has been around for 30 yrs, addressing measurement, alignment, and tying it all together
  • Basili: "Measurement is the best abstraction of what is going on around me"
  • Basili: "Why measure? 1) understand business & create visibility; 2) manage & control based on quantitative evidence (learning)
  • Basili: "...enabling tribal learning; 3) guide improvement and optimize activities towards goals"
  • Basili: "Measurements answer: what should happen, is it happening? are certain problems commonplace? what will minimize probs?
  • Basili: "Measurement is a means to an end, not an end unto itself" (spend 3x more time analyzing data vs. collecting data)
  • Basili: "Measurement is not just the collection of data; it cannot just be aggregated... it requires interpretation"
  • Basili: "GQM stands for Goal Question Metric": slide is here:
    https://pbs.twimg.com/media/BHa1VCeCMAAmO51.jpg
  • Basili: "Collecting data is expensive; so what is minimum data I can gather to inform the most number of goals"
  • Basili: "Measurement needs to be deeply integrated into organizational processes"
  • Basili: "Higher level goals require more understanding, but have bigg payback"
  • Basili: "There is no universal measurement program solving all problems related to measurement"
  • Basili: "Tom DeMarco: 'you cannot control what you cannot measure'" (I loved his book "The Deadline")
  • Basili: "Horrible symptoms: IT & software seen as pure cost driver that is substitutable; core biz competencies are outsourced
  • Basili: "align business at all levels of org; link org goals & strategies to project level; control success & failure thru measures
  • Basili: "Goals: improve customer satisfaction by 10%; reduce customer reported defects by 20%

Steve Baynes: "Transforming Your App Dev Org": Northrup Grumman

  • Baynes: Topic: broader understanding of scrum, testing, etc...
  • Baynes: "We used to do annual software releases, but features weren't getting done; slow feedback loops; integrations at end
  • Baynes: "Dev was writing code that wasn't being tested for 5 months
  • Baynes: "All this made long term, detailed planning almost impossible; planning by activities instead of features
  • Baynes: "In Microsoft Project, we put in all our activities, instead of the feature outcomes; focused on activities instead of features
  • Baynes: "And we weren't focusing on features in priority order
  • Baynes: "64% of the features that we develop are rarely or never used"
  • Baynes: "Our challenge: be Agile across our organization: lots of concurrent release, and supporting multiple versions
  • Baynes: "XP is more about engineering management practices; Scrum as more a management framework
  • Baynes: "We started with XP, and then as releases grew, focused on Scrum
  • Baynes: "In simple terms: compress each element of Waterfall into each 2-4 week sprint, repeated over and over
  • Baynes: "Define Vision Statement and Product Roadmap: Release 0; Release Planning"
  • Baynes: "In this planning process, we're constituting the team, identifying any training, tooling needs, etc. Transition planning allows team to hit ground running on Day 1
  • Baynes: "I have 4 scrum teams working concurrently: 3 ceremonies: sprint planning, daily scrum, sprint review, sprint retrospective
  • Baynes: "daily scrums: what did you do since last mtg; what are obstacles; what will you do before next mtg?
  • Baynes: "managing backlog: individuals sign up for work; estimated work remaining updated daily
  • Baynes: "Our automated build process and continuous integration; every commit goes into CI, static code analysis, unit test databases for all sorts of Oracle versions and schemas, all unit tests run, code coverage analysis on unit testing; generate online help and API docs from comments in code; create CD image; then deploy to test clusters, update dashboards,
  • Baynes: "Sprint review and retro: I explain to my management, see working software; retrospective (went well, improve, develop actions & priorities)
  • Baynes: "Readiness: our Release or Hardening Sprint: finalize remaining tests (perf/load testing, regression; platform test is extensive); docs are finalized, prepare deployment CD and artwork; release retrospective is planned; QA manager leads our "total product readiness" process
  • Baynes: "Testing techniques: for section 508: take away mouse and see whether you can use software
  • Baynes: "Agile testing: test early, test often, automate
  • Baynes: "You'll spend 50% of dev cycles understanding reqs in order write testable software
  • Baynes: "It's better to get 80% of the features 100% done, than 100% of the features 80% done"
  • Baynes: "Transition strategy: Understand: it's important to first understand what it is that you're trying to change
  • Baynes: "Educate: educate them so they can break comfort for doing things status quot; Execute
  • Baynes: "Even US govt cited need for chg: 2012 GAO Report: cited $76B spent on IT that did not advance mission, recommends Agile
  • Baynes: "Even DoD CIO very concerned, asking all contractors & integrators to change; President Obama enacted
  • Baynes: "http://gao.gov/products
  • Baynes: "Trends: Version One review
  • Baynes: "Top reasons for Agile failure: at odds with company culture; external pressure for waterfall releases" (Version One 2012)
  • Baynes: "We have 193 virtualized servers to support builds; we can spin all of them up on demand"

Dr. Peter Hantos: "Agile Software Development In Defense Acquisition: A Mission Assurance Perspective" (Aerospace Corp)

  • Hantos: "Agile is a wet-dream for programmer, and a nightmare for a [govt] program manager" (haha. holy cow)
  • Hantos: "My customer are the US govt, Air Force and intelligence agency that use satellites: acquisition programs for satellites
  • Hantos: "On management buzzwords:
  • Hantos: "On 'bandwagon' effect for TQM, Lean, Six Sigma;
  • Hantos: "Many claiming excellence [tqm, lean, 6 sigma] turned out to be medicore or outright failures [pararone 2009]
  • Hantos: "Agility connotation in Defense: war-fighter agility vs. need for agile acquisition of weapon systems
  • Hantos: (oh dear. showing agile software dev is minuscule part of the grand Acquisition process in govt procurement process)
  • Hantos: (omg. watching his critical analysis of govt acquisition, agile methods, nature of large projects blowing my mind)
  • Hantos: "No one uses waterfall methods for satellite projects;
  • Hantos: "Increment planning is equal difficult for 'waterfall' or Agile; opt for cost-based or time-based contracts respectively
  • Hantos: "Agile is difficult for macro-estimation estimation, which is reqd for many contracts/customers"
  • Hantos: "Space vehicles: 512K delivered source instrs (KDSI); ground systems: space shuttle: 2K KDSI; satellite ctl: 4700K KDSI
  • Hantos: "To deliver a 4700K KDSI ground system to support satellites is a 47 month project
  • Hantos: "Mission assurance risks composed of (mission risk: satellite blows up; program risk is cost and schedule)
  • Hantos: (Asserts Iron Triangle negates posited benefits of Lean and Agile; pretty sure he's wrong, despite FEARSOME intelligence)
  • Hantos: (Asserts that mission assurance is not valued by Dev; and that there's no fluff to cut. Wrong.)
  • this guy is fearsome debater, I think he's wrong)
  • Hantos: (citing all the non-functional requirements; "the Lean question: which ones do you cut? which ones don't add value?)
  • Hantos: "Sign on my dentist's wall: Brush only those teeth you wish to keep" (Haha)
  • Hantos: "Typical 3-4 year development process and min 5-10 yr long ops/sustainment for space vehicle req strong tools support"
  • Hantos: (fascinating watching practitioners and academics jump on Hantos' assertions)
  • Hantos: "Turnover in IT sector almost 2x higher than federal employees
  • Hantos: "When facing situation where employees are let go due to funding, extreme need for documention
  • Hantos: asserts that Agile values doesn't scale up for large projects. True? False?
  • Hantos: "JROC, DoD, Congress are all high-inertia orgs w/complex, bureaucratic processes for interaction"
  • Hantos: "It's unfortunate fact of life that when things don't go well, collaborative resolution becomes less and less feasible
  • Hantos: "Yogi Berra: if you don't know where you are going, you will wind up somewhere else
  • Hantos: "Recoverable vs non-recoverable software failures:
  • Hantos: "It's really bad when Congress legislates a software development process: guaranteed to backfire
  • Hantos: "In 1988, spiral development introduced, one of most powerful adaptive methods; 2003, declared as preferred methodology
  • Hantos: "Every govt contract submission insisted they did spiral dev; 5 yrs later, they took it out, b/c they learned what it was
  • Hantos: "Agile is an extreme adaptive process model: being pushed blindly
  • Hantos: "Govt is pushing for Fixed Price Contracts; pursuing agile development and fixed price contracts at same time is not feasible
  • Hantos: "The temptation to cut corners, even in the name of being efficient or expedient, is ever present, especially in a global business that is economically forgiving
  • Hantos: "Dr Wanda Austin, President CEO Aerospace Corp: "That is why 'getting it right' must be a 24/7 commitment"

Phyllis Marbach, Boeing: Case Study Of DoD Program Using Agile Software Dev Process

  • Marbach: "Introduction to agile, major defense acquisition program description, JTRS enterprise network management (JENM), contract specifics, systems engineering role, agile and earned value management, program reviews and contract requirements, metrics and productivity, continuous integration
  • Marbach: "plan review: srs, irs, sad, all plans; release reviews: hand over test scripts, etc.;
  • Marbach: "at Boeing project, we went from 2 to 3 week sprints to enable time for program reviews & contract documentation
  • Marbach: "organized sprints so that teams could complete enough functionality to enable testing
  • Marbach: "Major Defense Acquisition Program defined as: those that cost more than $365MM/year in 2000 dollars
  • Marbach: "JTRS JENM was a major project to enable unified network management for warfighter: IDIQ awarded 4/2010
  • Marbach: "Proposal written w/Agile mentioned: Had to support lots of legacy radios, field testing (in mud), lots of priority chgs
  • Marbach: "In contract: priority of work items may change, but not the requirements
  • Marbach: "807 requirements -> 1607 features
  • Marbach: "Systems Engineering Role: Test; SysE and SwTestE didn't work in iterations; received software at end of each sprint"
  • Marbach: "SysE Role: Deliveries: SwE maintains reqs, design & test scripts within iterations
  • Marbach: "Must get infrastructure set up in Sprint 0/Planning: infrastructure, dev & continuous integration test env" (Yes!)
  • Marbach: "At Boeing, we added a 4th member to Agile team: technical owner, in addition to product owner"
  • Marbach: Q: "this obviously has hardware, where does it fit?" A: "we tested at end of each sprint in lab"
  • Marbach: Q: "how did you prevent testers from being left behind?" A: "we'd enforce testability of UI to database and back; at first, we had 3 weeks to qualification tests, and finished a day early, b/c we were finding/fixing as we go
  • Marbach: "Agile and Earned Value Management: each software release was a milestone deliverable; progress reported weekly on % complete story points for each release's planned total story points
  • Marbach: "Story points are estiated effort to copmlete a backlog or user story; business value is in the completion of a feature
  • Marbach: "A release might have a partial feature delivered that will be finished in the next release
  • Marbach: "hybrid Agile: after PER, your design and how you satisfy infosec requirements; forced many team members to decouple from team to satisfy security testing requirements via detailed design; then went back to Agile
  • Marbach: "This was an example where three letter agency tested design, traceability requirements
  • Marbach: "when you have heavy information assurance requirements, maybe you can't do iterative building;
  • Marbach: "You need to have architecture and modules, which enables iterations; between PDR and CDR; then customer changed everything; but with prioritized backlog, we could absorb it
  • Marbach: "Used Version ONe;
  • Marbach: "We hit the schedule, and we had assurance based on velocity reporting that we were going to hit the date
  • Marbach: "Customer attended demos every 3 weeks; the more we showed, the more showed up
  • Marbach: "Challenges: learning the process (recommended training b/c it created champions), planning work, maintaining the design, too many conflicting stakeholders, customer waterfall schedule, defining the backlog to trace the requirements, Agile and EVM
  • Marbach: "What did they like? liked deliverable product every 3 wks, do builds quicker, agile testing rather than whole thing at once, keeps everyone accountable, build relationships w/our suppliers, stakeholders impressed with demonstrations
  • Marbach: "What would you change: reduce the amt of change, maintain the design betterc
  • Marbach: "Biggest surprise: how rigorous it was, it's working,
  • Marbach: "Our customer kept changing requirements, using Agile as the rationale of why we could absorb them" (haha)
  • Marbach: "

Suzanne M. Miller & Mary Ann Lapham, SEI: "Ready & Fit: Understanding Agile Adoption Risks in DoD & Other Regulated Settings

  • "DoD is not the only regulated setting that constrains approaches; compliance du jour is everywhere"
  • "Other regulated envs: Dept of Energy, FDA, Financial Services (pharama & medical devices), healthcare records, international trade
  • "Probs: inherently conflicting regs:
  • "Regulatory ghosts in the system (still cutting off ends of roasts: becuase mom did it, not knowing it was because roast was bigger than the pan
  • "Regs often have unwritten laws: written law protects you & persecute those who violate unwritten law (eg, don't trust contractors)
  • "Problems of the past become the regulations we have to live with today"
  • "Are we fit? Meaning, do we have the culture and processes to get things done?"
  • "Why do I care about Agile? B/c methods are based on explicit set of principles: incr learning, trust & roles working side by side
  • "DoD conflicts: documenting everything beforehand prevents incremental learning
  • "DoD conflict: Minimize risks to acquisition agency: not much opportunity for trust
  • "DoD conflict: keep contractors at arm's length, maintain govt independence: not much opp for working shoulder to shoulder
  • (Wow. Someone here worked on Apollo program!! I'm buying drinks for him!!! He says, back then, govt & contractor indistinguishable
  • (He says, back then, so much trust between gov & contractors; now, culture of fear and distrust; Golly.
  • "Our mission: create translation layer between Agile and DoD policies: confirming what practices aren't explicitly disallowed
  • "Created the Agile Collaboration Report
  • http://sstc-online.org/schedule/schedule.cfm?pg=sc
  • "Created SEI Readiness & Fit Analysis tool:
  • "Categories: business & acquisition; organizational climate; system attributes; project & customer environment; technology environment; practices (citing Adler work extensively)

Rick Barbour, SEI: "Improving Operational Resilience Processes"

  • operational risk and resilience, convergence, cert-rmm, cmmi-svc, itil v3
  • "SEI definitions: possibility of suffering harm or loss; risks consists of an event, a consequence, and uncertainty
  • "Defn: categories of operational risk: actions of people, systems/tech failures, failed internal process, external events
  • "Resilience: emergent property of organization when it continues to carry out mission after disruption within operational limits
  • "40% of companies in World Trade Center after 9/11 went out of business; exceeded operational limits or the org due to loss
  • "Operational Resilience Management <- Security & Controls, Continuity & Recovery, IT Operations
  • "CERT-RMM: resilience management model; doesn't look like Capability Maturity Model
  • "Case studies done at Dept of Energy, Lockheed Martin, and many more
  • "Levels: operational risk mgmt -> 3 domains -> operational resilience -> organizational mission
  • "4 types of assets: people -> facilities, technology and information
  • "CERT-RMM elements: services, business processes, assets

Misc

  • @RickVargas: Review of Gene Kim’s new novel, “The Phoenix Project” http://t.co/iiaYYXMSTH via @sharethis #books #IT #DevOps
  • @MsKachita: @bimparas Know anyone for this job? DevOps Engineer in San Francisco, CA http://t.co/qxRDd6PvJm #job #DevOps #Linux
  • @GJ7300: The 5 Goals Of #Agile And #DevOps — Agile Web Development & Operations http://t.co/mM85oh0NOI
  • password will be: stc2013
  • @patrickdebois: current state - making up #devops stories - http://t.co/qklY2GAQLO
  • @SerenaSoftware: The real meaning of 'mission critical' - #devops in space and #avionics http://t.co/XqZLCLyX3U @ComputerWeekly
  • @igorescobar: Team work #devops http://t.co/nhTOdXIfaB
  • @RealGeneKim: My notes from '2012/04/08 #IEEE Software Tech Conference', written w/@tweetscriber! http://t.co/