EPF F2F Meeting - Boulder, CO
December 6-7 2007
Kurt Sand (Telelogic, day 1)
Chris Sibbald (Telelogic)
Per Kroll (IBM/Rational)
Ricardo Balduino (IBM/Rational)
Ana Paula Valente Pereira (Whatever Consulting)
Nate Oster (Number Six)
Ken Clyne (Number Six)
Bjorn Gustafsson (GoodSoftware)
Ryan Martens (Rally Software, day 1)
Dean Leffingwell (Leffingwell LLC, day 2)
2 Agenda as planned
1) Thursday December 6, 2007
OpenUP planning (what will be in next release) (Nate) 8:30 – 9:30
Scrum planning (what will be in next release) (Lyndon TBD) 9:30 – 10:30
Discuss practice library (Per, Bruce Macisaac-remotely) 10:30 – 12:00
ProjectKoach Presentation (Bjorn) 13:00 – 14:00
Update on translation efforts (Ricardo) 14:30 – 15:00
Discuss how to grow the community (Steve) 15:00 – 17:00
Team dinner 6:30 pm
2) Friday December 7, 2007
EPF Wiki Training (Onno) 8:30 – 10:00
Discuss Enablement (Steve) 10:00 – 12:00
Release Planning (Per) 1:00 – 3:00
3 Update on Translation Effort (Ricardo) 9:15 – 9:45
Ricardo presented the attached slides.
There are 6 – 10 people (depending on availability) working on the Portuguese
translation. This effort is about 90% complete (based on OpenUP/Basic V0.9).
There are ~three people working on the Russian translation (at Luxsoft via Steve
Adolph). Per noted that if they have not done much, perhaps we should get them to start
working on the V1.0 release (vs. V0.9). Steve to look into this.
EPF Composer does some translation when publishing in a particular language (structural
information such as element types).
Per noted that IBM should have language specific glossaries that may help with
translation efforts. Ricardo will look into the possibility of making these glossaries
It would be nice if there was a diff tool for EPF Composer that would, for example, tell
us all the differences between OpenUP/Basic V0.9 and OpenUP V1.0. This would also
be useful for users when new versions of OpenUP are released.
How do we ensure translation is complete and of acceptable quality. There are two
possible approaches identified by Ricardo (see slide 5). Per noted that only approach b)
will comply with Eclipse rules. In the case of the Portuguese translation there is an
individual that has been active and reliable that would be a good candidate to make a
committer (Paulo Moreira) Ricardo to look into this.
Steve noted that for the French translation effort, Universities in Quebec may be
interested and able to get a grant to perform this work. Steve will look into this.
The other issue to address is the promotion of translated content and due diligence to
meet Eclipse Legal requirements. Per noted that translated content should be moved to
CVS incrementally, rather than one big bang migration when complete. The standard
process is to track contributor, Bugzilla and committer for each contribution. Do we need
multiple Bugzilla’s or many smaller bugzilla’s? We need to ask Onno what reports we
can get from EPFWiki that lists all changes. This report could then be attached to a
single Bugzilla to provide more detailed auditing. Ricardo will check with Onno to see if
the EPFWiki reports have all the required information (who contributed what).
3) Scrum Planning (Ken Clyne) 9:45 – 10:45
Ana, Lyndon, Ricardo and Ken are the “Scrum Team”. Ken did recruit four people from
Number Six to help out as well.
Content is still a bit immature with some translation, accuracy, completeness and depth
We need to get more participation from the Scrum community.
Rough assessment is 50% complete.
Mike Cohn has given consent to re-using some of his material. Ken will provide a list of
items that he would like to get permission from Mike to re-use. Per will contact Mike to
see it is ok to use this information and to see if he is interested in becoming more
involved in EPF in general.
Ryan Martens joined the meeting. He outlined Rally’s interest/plans regarding EPF.
Rally did not build a workflow engine into the Rally Dev product. Rally uses a
programmable state-machine in the tool to manage the lifecycle of work items.
The product is more of a decision support system for overall project health than a
process management tool. It is highly focused on the “project” level versus the
Portfolio or development level.
They are very interested in Best-practices at Rally but not interested in EPF
creating or driving an automated process. Ryan says they provide guidelines and
best practice mentoring, but are only asked for end-end process by their largest
customers. Their customers are typical program managers that have to coordinate
multiple Scrum/XP teams.
Per outlined the method/process pattern/delivery process hierarchy in EPF.
We discussed that best-practice is easier to “sell” than end-end process. Many people
agree on best-practice, but the larger the building block (ex. a full end-end process) the
more violent the process wars.
As the discussion has turned to best-practice vs. full lifecycle process, this seemed like a
reasonable point to transition to the practice library discussion.
4) Practice Library (Per, Bruce, Ricardo) 11:00 – 12:00, 12:45 –
Per set the context for the discussion with the presentation “EPF Practice Library
Proposal” (see attached slides)
How to adopt a process? How to avoid the process wars and build a community and
library of best practice?
Current practices in OpenUP:
1. Management Practices
a. Iterative Development
b. UP Lifecycle
c. Self organization
2. Technical Practices
a. Use-Case driven
b. Shared Vision
c. Basic Architecture
d. Basic Software Design
e. Test-driven development
f. Agile Testing
g. Continuous integration
Bruce Macisaac then presented a prototype library structure. (See attached presentation
“OpenUP Practice Library Structure”)
Currently we can accommodate the proposed structure, however due to tool limitations it
is rather complex. In order to simplify library management and process definition there
are some additional features that could be added to EPF Composer. Bruce outlined a
proposed set of EPF Composer features to support a practice library. See attached
presentation “EPF Features”.
Ricardo presented a demo of the prototype library. Ricardo will provide a copy of the
The plan is to create a separate best practice library. The current plug-ins for OpenUP,
Scrum, DSDM, XP content that currently exists will continue to exist in their current
5) ProjectKoach (Bjorn) 13:30 – 14:10
Bjorn delivered a presentation on ProjectCoach. (Slides Attached).
Bjorn introduced himself as “a programmer”. He was a member of the RUP team from
Bjorn is here to introduce ProjectKoach (an agile project management tool) and to get
involved in EPF.
Demo showed ability of ProjectKoach to:
1. Create project plan and integrate with Mylyn (work items) in standalone model
2. Import an EPF process configuration and create a project plan (instantiate
process). Add resources, and make work items from process tasks. The process
tasks maintain links back to the process website.
6) Growing the Community (Per) 14:20 – 15:15
Per outlined the sweet-spot for EPF Composer (i.e. larger groups with traditional
processes). OpenUP (content) has been targeting small agile groups.
Some perceived motivation for adoption by various groups:
1. SEPG – EPF Composer is the best tool available
2. Bus Manager/Dev. Executive – Best solution for incremental improvement in
3. Agile Practioner – OK if it can help me convince management that agile is
4. Dev/Project Manager – Good if I get the practices I need for better
Kurt noted that we have been very focused on promoting OpenUP, and have not been
very active at promoting EPF Composer in its own right. Chris noted that there is also
opportunity to expand the community outside of the software development domain.
Per noted that a shift to practices vs. processes should also expand the audience since we
will appeal to a broader audience and avoid the process wars.
More university involvement will lend credibility and re-useable content (Ana noted an
example of a University in Portugal that is using EPF Composer to document their co-op
Ryan said a contest to find the “nicest” EPF Composer generated web site could create
More Standards body involvement would also lend credibility. It would be a great coup
if Carnage Mellon adopted EPF Composer.
7) OpenUP planning 15:30 – 16:30
Current plan is to have a minor release of the current OpenUP plugin that addresses
defects only. We will also begin work on the EPF Practice Library in parallel.
8) Enablement (Steve) 16:30 – 17:00
Chris quickly walked through the Introduction to EPF course (~4 hrs including hands-on
exercises) that Telelogic will donate to the EPF project. Chris gave Ricardo a copy of the
preso to add to CVS.
9) Enablement (Steve) 9:00 – 14:00
Steve asked if we should have a certification program. There is no huge demand for
certification at this point. It may be a barrier more than an enabler.
1. EPF Composer: Effectively manage your enterprise practices
2. OpenUP: Start small and grow
3. Practice Library: the tool box for incremental adoption.
Nate got involved in EPF because he would get to work with thought leaders to get a
minimal package that can be used as a starting point in consulting engagements and to
leverage the brand to generate demand.
Steve got involved because he felt the practices and light-weight nature of OpenUP
matched the needs of his target market and it would help his business. Also his
participation in the project would enhance his personal credibility.
Ana is in a market where Scrum and RUP are not that well known. But her target market
is looking for more agility, so she sees that EPF/OpenUP will help her deliver agility to
Bjorn consults with organizations that are adopting/using RUP but having problems. He
saw EPF as a means to simplify tailoring/right-sizing process.
Telelogic got involved because they saw the project as a means to ease tool adoption and
to provide a more efficient service delivery.
Dean said there are two ways to drive demand and adoptions: 1) Top-down via thought
leadership, 2) Bottom-up by solving grass-roots problem (demand from the desktop).
“Agility that Scales” is a tag line that has been used since about May (for RUP and
OpenUP) and has resonated in the market place. There has been some resurgence in
interest in RUP of late.
The names “StartUP”, “StepUP” or “ScaleUP” had some traction with the group since it
captured the minimal, complete, extensible message and avoids the “this is THE
process”. The “StepUP” (or “ScaleUP”) may be different for every organization,
drawing on the practice library as required. The following draft list of practices would be
part of StartUP (immutable, must do):
1. Iterative (plan, assess)
2. Continuous Integration
3. Concurrent Testing (Developer test, system test)
4. Two levels of planning
5. Agile Team (Define, Build, Test; Self-organize)
It was proposed that we call this base configuration “The Agile Kernel”. The additional
practices added to get OpenUP could be called ScaleUP. So, OpenUP is:
1. Agile Kernel
2. StepUP which includes the following practices:
a. Evolutionary Architecture
b. Evolutionary Design
c. Use-Case Driven
d. Shared Vision
e. Practice Authoring Guidelines
Other ScaleUP practices could include:
1. Portfolio Management
2. Program Management
3. Integration/synchronization of multiple teams
Messaging on OpenUP would have to change: OpenUP is a software development
process that consists of a minimal, extensible kernel of agile practices and a set of
additional practices (StepUP) that are added to provide some scaling.
The book on OpenUP would consist of two parts: Part I – The Agile Kernel; Part II –
Scaling UP. The second part would also contain a section on adoption which discusses