a plan-driven process —how and why to fake it philippe kruchten @ usc, on march 18 th, 2004
TRANSCRIPT
![Page 1: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/1.jpg)
A Plan-Driven Process—How and Why to Fake it
Philippe Kruchten
@ USC, on March 18th, 2004
![Page 2: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/2.jpg)
2
Presenter
Philippe Kruchten, Ph. D., P. Eng.
Dept. of Elec. & Comp. Eng.
University of British Columbia2356 Main MallVancouver BC V6T1Z4
[email protected]@ieee.org
![Page 3: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/3.jpg)
3
Fitting in a Plan-Driven Environment System engineering “waterfall” approach Necessity to comply to
IEEE Standards
ISO 12207
some company or industry standard Intent to certify or remain certified at some CMM level
![Page 4: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/4.jpg)
4
Fake it. Do the “right thing”, e.g., use appropriate agile practices
Present enough of an external façade to the outside world to meet the requirements
Present management artifacts ‘as if’ you were doing things in a plan driven fashion.
Tailor the external demands to the maximum extremity feasible. in particular, tailor:
Document templates
Level of “precision”
Frequency of updates (no early “freezing”)
Adjust the jargon Produce
High level plan
Plans by iteration (or cycle, or sprint, …) Inform and set the expectations right for the external world
![Page 5: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/5.jpg)
5
Example: IEEE Standards
Tailored software development plan 1058:1998
Section 6.1: introduce your agile process
Section 7.4: Test-first
Section 7.5: pair programming
Section 7.6: introduce the scrum
Section 7.8: introduce retrospective
etc…
The standards do not tell you HOW you have to do the work. The plans can be as flexible as you want or need.
But set up the right expectations.
![Page 6: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/6.jpg)
6
Scaling UP the Agile processes?
How large can I expand the team and still be agile? How long… ? How many attributes of agility can I drop and still be agile? Which practices can I scale up? Which practices I cannot use on large projects?
Or should we :Understand the ideal conditions of agility
Scale down projects in a way that establishes these ideal conditions of agility
If the mountain will not go to Mahomet,let Mahomet go to the mountain. (Proverb)
![Page 7: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/7.jpg)
7
Agile Process “Sweet Spot”
High bandwidth communicationSmall team (10-15), Collocated, Face to face (as opposed to document
based) Customer on site
a customer representative, domain literate and empowered to make decisions
Short lifecycle (weeks or months, not years) Powerful development environment:
Rapid development cycle, though automation
Continuous integration (builds)
Automated test Iterative
Accommodating change, refactoring Business applications (rather than technical, embedded, real-time) New development (rather than maintenance)
Availability of test regression suite ?
![Page 8: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/8.jpg)
8
The “Bitter Spot” (?)
Large team Distributed team No empowered customer on site Long development cycle Inefficient development environment (low level of automation) Different cultures
Low communication bandwidth, reliance on documents Waterfall Aversion to change
Try to follow a fixed plan
![Page 9: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/9.jpg)
9
Large Project
Large projects are not going away
Tend to :• Heavy early planning (and desperately try to follow)
• Relying solely on written artifacts (workproducts),
− including in dialog with customer
− And in following a defined process
Waterfall approach still dominant paradigmEasy on management
“comforting”, false sense of rationality, of determinism
Similar to other engineering disciplines
![Page 10: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/10.jpg)
10
An Exemplar Large Project
Avoid the marginal conditions (go from 12 to 18) Do not compare a bad large project with a good small and agile
project
200 people or more Distributed Different organizations/companies 2 ½ years before first delivery Iterative lifecycle Good, skilled people Access to customer Access to efficient programming environment New system, architecture not set
![Page 11: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/11.jpg)
11
The Ideal Large Project—Agile?
High bandwidth communicationHow to achieve beyond 15?
CustomerHow to make it available to 150 people
Focus on resultsHow to focus on something getting out in 2 years?
Some level of planning and explicit documentation will be necessary
Break-down the 200 people in:10 teams of 15
Establish the conditions of optimal agility
Use the 50 others to fill the space in between, act as the glue
• Communication
• Customer role
![Page 12: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/12.jpg)
12
Setting up the Large Project—Inception+Elaboration
Initial team Initial team
Architecture team
Architecture team
Prototyping team
Prototyping team
Management teamManagement team
Elaboration Inception
LCA Milestone
Agile teams
Superstructure teams
time
![Page 13: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/13.jpg)
13
Setting up the Large Project—Construction+Transition
Architecture team
Architecture team
integration team integration team
Architecture team Architecture team
Feature team 2 Feature team 2
Feature team 1 Feature team 1
Feature team 3 Feature team 3 Infrastructure team A
Infrastructure team A
Infrastructure team B
Infrastructure team B
Prototyping team
Prototyping team
Management team Management team Management team Management team
Construction & Transition Elaboration Create 2 types of teamFeature teams
• User oriented
Infrastructure teams
• Provider of common services to feature teams
![Page 14: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/14.jpg)
14
Increased level of ceremony
Initial team Initial team
Architecture team
Architecture team
integration team integration team
Architecture team Architecture team
Feature team 2 Feature team 2
Feature team 1 Feature team 1
Feature team 3 Feature team 3 Infrastructure team A
Infrastructure team A
Infrastructure team B
Infrastructure team B
Prototyping team
Prototyping team
Management team Management team Management team Management team
Construction & Transition Elaboration Inception
Feature teams Infrastructure
teams “glue”
More planning More
documentation Less agility
![Page 15: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/15.jpg)
15
Where are we?
Feature teams and infrastructure teams:Organized as “agile projects”
Added a project superstructure to reproduce ideal conditionsArchitecture team
Integration team
Project management team
Increase in level of ceremony
More planning involved than with a single agile projectKeep feedback loop from iterations, react to change
Not a plan first and then execute to plan
![Page 16: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/16.jpg)
16
Issues with a Federation of Teams
Dependencies between teamsTeams are customer for each other
May need “brokering” by architecture team to avoid too much one-to-one communication
StovepipesTeams as small fiefdoms, building and empire and reinventing the wheel
Architecture team participate in design reviews, planning sessions Imbalance: staff and skills
Identified by architects, or raised up by team lead Communication breakage Too much staff too early Long cycle: lack of feedback loop?
Rotation of staff, and circulation of architect “moral” equivalent of pair programming
Spreading the culture
![Page 17: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/17.jpg)
17
Dual Rhythm
Long cycleLack of feed back
Team lose track of ultimate goal
Need intermediate, tangible goals
Dual ‘beat’
System increment beat: 6 months
Weekly/biweekly scrum
Team increment: 1 month
Daily scrum
Example
![Page 18: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/18.jpg)
18
Organizing Project Documentation
Progressively introducing more explicit documentationMore efficient use of staff (e.g., architecture team)
Greater visibility
Software (/System) Architecture Project level backlog, Risks and issues
Requirements: “vision” and key use cases Key interfaces Recommended practices, project standards (the actual concrete
process) Reusable elements Overall project plan
![Page 19: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/19.jpg)
19
Initial StateInitial State Actual Path and precision of artifacts
Iterations and Demonstrable ProgressUncertainty in Stakeholder
Satisfaction Space
Uncertainty in Stakeholder
Satisfaction Space
Initial PlanInitial Plan
Emergence of Requirements, Architecture, Design, Plans, and Product
![Page 20: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/20.jpg)
20
Examples
Ship System 2000 (FS2000)Central software architecture team
Iterative development
Architecture => blueprint for organization
Canadian Air Traffic Control system (CAATS)Went further than SS200
Customer on-site: large team of actual users of ATC
Start prototyping with a small team + arch. team
Architecture team “split” at end LCA milestone
• Played role of facilitator, communication vertex Integration team
Progressive introduction of explicit documentation
![Page 21: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/21.jpg)
21
Examples (cont.)
Rational Software’s Product GroupTeam of teams (700 total)
Distributed – 7 sites around the globe
Varied culture (acquisition)
Centralized:
• Architecture
• Product definition, with “local rep”
• Integration (installer, licensing, etc.)Dual rhythm
• Major beat: 6 months
• Internal beat: monthly
![Page 22: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/22.jpg)
22
A different kind of project management support Single prioritization scheme “Virtual” SCRUM
BringRequirements (user stories, use cases, etc.)
Problems (bugs reports, etc.)
Issues (tactical things)
Tasks (and other time consumers)
Risks
Business constraints
Resources
Process
under one single tool to support project managers and practitioners
Visibility of results, progress, metrics to all
![Page 23: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/23.jpg)
23
Different project management support Scheduling and WBS Earned value
Replaced by:
Tactical backlog support Virtual Scrum
Some new players in this space: Osellus, Toronto: IRIS Ensemble Systems, Richmond BC: TaskWorkbench F4 Tech, Boulder, CO: ??? Big, Seattle area company….
![Page 24: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/24.jpg)
24
Summary Large projects set up as as a federation of agile teams Two levels of:
Communication
Organization
Project ‘beat’ Software architecture serves as the blueprint for the team structure
“Emerges” during elaboration with a small team (or two) Then Architecture + Integration teams add communication “glue”
Serve as customers
Facilitate communication
Balance skills, load
Foster reuse
Assemble final product Gradual introduction of explicit documents
Where they support effective communication, reduce ambiguity, spread common culture
![Page 25: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/25.jpg)
25
References and further reading1. P. B. Kruchten, The Rational Unified Process: An Introduction, 2 ed.
Boston: Addison-Wesley, 2000.2. B. W. Boehm, D. Port, M. Abi-Antoun, and A. Egyed, "Guidelines for the
Life Cycle Objectives (LCO) and the Life Cycle Architecture (LCA) deliverables for Model-Based Architecting and Software Engineering (MBASE)," USC, Los Angeles, USC Technical Report USC-CSE-98-519, 1999.
3. K. Schwaber and M. Beedle, Agile Software Development with SCRUM. Upper Saddle River, NJ: Prentice-Hall, 2002.
4. L. Brownsword and P. Clements, "A Case Study in Successful Product Line Development," Software Engineering Institute, CMU/SEI-96-TR-035, 1996.
5. T. Paine, P. Kruchten, and K. Toth, "Modernizing Air Traffic Control through Modern Software Methods," in 38th Annual Air Traffic Control Association Conference. Nashville, Tenn.: ATCA, 1993.
6. P. Kruchten, "Iterative Software Development for Large Ada Programs," in Proc. Ada-Europe conference, Montreux, Switzerland, vol. LNCS 1088, A. Strohmeier, ed.: Springer-Verlag, 1996, pp. 101-110.
7. P. Kruchten and C. J. Thompson, "An Object-Oriented, Distributed Architecture for Large Scale Systems," in Proc. of Tri-Ada'94, Baltimore, November 1994: ACM.
8. P. Kruchten, "The Software Architect, and the Software Architecture Team," in Software Architecture, P. Donohue, ed. Boston: Kluwer Academic Publishers, 1999, pp. 565-583.
![Page 26: A Plan-Driven Process —How and Why to Fake it Philippe Kruchten @ USC, on March 18 th, 2004](https://reader031.vdocuments.us/reader031/viewer/2022032200/56649f4d5503460f94c6de07/html5/thumbnails/26.jpg)
26
Thank you