2014/01/27 8:45 Phyllis Marbach, “The Role of SE in Agile Software Implementation Teams”, Agile Systems and Systems Engineering Working Group

Phyllis Marbach (Boeing), coauthors Gundars Osvalds (Praxis Engineering), Larri Rosser (Raytheon), and David Lempiach (Rockwell Collins), with the Agile Systems and SE WG commentary to improve the quality of working paper to be submitted to the July issue of INCOSE Insight

This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

INCOSE International Workshop 2014, Torrance, California


Review articles are at:

[Phyllis Marbach]

More a how-to paper than a concept paper

Agile has gone from software development to DoD projects

Proposing a work cadence, the Agile SE Framework, for the EMD phases of a DoD program with many teams working in parallel

  • Engineering and Manufacturing Development

What capabilities do you?

  • Proposal
  • Win
  • Implement

There’s a pre-planning phase

  • Might have several implementation teams working in parallel
  • May also have multiple architectural team working in parallel as well

Figure has a variety of roles

  • System engineers
  • Product owners
  • Chief engineer
  • Systems engineer
  • Some also working on the implementation team
  • If have an architecture came, need to implement at an appropriate time, so that it doesn’t impact schedule
  • e.g. could be building operating system software and application software at the same time

Comment: architecture team could be a bottleneck

Architects are also members of the implementation team

  • Working together to maintain architectural integrity

Modular architecture is key to making this work

  • If don’t have modular, then agile may not be the way to go

It’s really an IPT issue

Comment:  How big is the team? Scale?

Agile practices say team is 7 +- 2

  • Some teams can be larger, working as part of project

Comment:  What’s the largest thing you’ve built?

Had a team of 50, now working as 30

Dean Leffingwell says 80 to 100

Project was integrating new product with legacy code, so hard to say what the measures:  army contract over 2 year period

Comment:  Tools, e.g. CATIA on Boeing 777?

Several enablers

  • Integration and test tools
  • Development tools
  • Project management tools
  • Protection that only
  • Design tools, e.g. Rhapsody
  • In sprints, maintain design with implementation
  • Agile says value code over documentation, but customers need documentation, so need to do simultaneously

In EMD phase, at milestone 2, should have requirements done, at a high level

  • Preplanning, define scope and deliverables, list of priorities
    • Execution:
    • implementation teams,
    • architecture team,
    • integration and test team, in large projects, need to integration at next sprint
    • planning team

SE role?

  • Should work well in testing and development
  • Maintaining system integrity
  • Larger systems view
  • Articulation and satisfaction of needs
  • Verification of capabilities and performance
  • Goal is to mature the requirements and architecture as the project proceeds, taking advantage of early iterations

Observation: Description doesn’t match?

  • Vertical integration with same person on architecture team and implementation team.  If can’t do this, then do documentation.
  • Horizontional integration to managing things bubbling up

Comment:  More likely to accept agile if includes systems engineering?  Invites participation in implementation team.

Wanted them to come, but they were working from paradigm of documenting

  • Agile could have a more steady flow, so don’t have it not coming together at integration and testing

Question: Incremental integration, different from agile?  Systems with architecture up front.

A matter of understanding the work cadence, so that that people know when iterations come up

  • Pull integration and test earlier

Question: How long are sprints?

  • Software community says 2 to 6 weeks
  • When have multiple teams, and hardware team, they need as much as 3 months, but the software team should be working shorter
  • Depends on product and development
  • Need to all have the same end date, should be working in a similar cadence, even if in different sprints

Comment:  Complementary aspects to scale up agile development

  • Agile was traditionally small
  • Have capability within model

Comment: Found RACI diagrams interesting, nothing for SE to be responsible for?

Have to look at that

  • Put that in to show how division of responsibilities could be place, not how they should be done
  • Need to have a bellybutton responsible for architecture, can’t just have one person responsible