puma - entreprise-agile.com · puma is a global framework of the agile enterprise ... the 2tup...

Agile Project Motor

PUMA

Architect of a generation

of high-performance enterprises

Jean-Pierre Vickoff

Teamlog

The Agile Project Motor

___________________________________________________________________________

___________________________________________________________________

Jean-Pierre Vickoff, Teamlog www.Entreprise-Agile.com 2

Table of Contents

PUMA is a global framework of the Agile enterprise ....................................................4

Agile risk management .........................................................................................5

Common practices among Agile methods ...............................................................7

Differentiating practices of Agile methods ..............................................................8

The PUMA project motor ........................................................................................ 10

The fundamentals ............................................................................................ 12

Project management ........................................................................................ 14

Project management extensions ...................................................................... 17

Specific project extensions .............................................................................. 20

Specializations (BPM – SOA) .......................................................................... 23

The 12 “quality” practices of XP ....................................................................... 26

Using Agile techniques .................................................................................... 29


___________________________________________________________________________

___________________________________________________________________


History of PUMA

In September 2001, Jean-Pierre Vickoff, one of the pioneers of

the Agile way of thinking in the I.S. field and its French-speaking

initiator, writes the first communication regarding PUMA. Its

translation is then expedited to the American and English

universities

In December 2001, “Développeur Référence” (IDG) uses the PUMA graphic design

(Proposition for Unifying Agile Methods) on the cover of an issue that devoted its main

feature to the rough outlines of this novel Agile vision. The communication is then taken up

in 2002 by numerous publications, including: ADELI, “Forum Logiciel”, LMI, etc.

At the time, PUMA already expressed its vision of Agility as follows “After having

determined the major portion of the common practices and the differences in practices of

each approach, the unified Agile method is composed of an optimal selection of common

practices to which it is convenient to judiciously add specific practices in function of the

context.”

It seems that the initial idea of PUMA was quite good, because Ivar Jacobson announced in

2006 in EssUp (Essential Unified Process) “a basic method which will be enriched with

additional practices in function of the project needs.”

Since then, Jean-Pierre Vickoff has enlarged the scope of PUMA (now the Proposition for

Unifying Agile Methods) by adding two outer layers to cover the entirety of the

organizational adaptation aspects as well as the anticipation and optimization of processes.

Because, without taking these points into account, there are no enterprises or

organizations that are truly Agile.

Representing a significant advance and an enlargement of the scope of organizational

agility, the principles of PUMA are the subject of several publications in French and in

English on the site Agile Alliance.


___________________________________________________________________________

___________________________________________________________________


PUMA is a global framework of the Agile enterprise

This communication follows up that which presented PUMA (Proposal for the Unification of

Agile Methods) globally.

PUMA is a dynamic framework for the evolution of business processes, information

systems, and collaborative modes.

By basing itself on the fundamentals of the Agile movement and the technical standards

that it integrates and brings together, PUMA represents the first formalization of an Agile

and global Enterprise method, coupled with a project motor, by the intermediary of a

solutions model. This model was conceived with regards to the new order of current

requirements classes and the imperatives of the incremental, iterative principle.

The Agile Project Motor is one of 3 components of PUMA. More precisely, it is the

component of operational implementation.

By modeling the high-level generic structures applicable to all organizations, PUMA’s

ambition is to reduce the complexity of their management. If a professional who faces the

PUMA solution immediately thinks “it’s naturally obvious, I already had it in mind, but I

never had the time to formalize it,” the challenge of Agility will be taken.

Figure 1. — PUMA Proposition for the Unification of Agile Methods


___________________________________________________________________________

___________________________________________________________________


Today, approximately ten methods meet the requirements allowing them to call

themselves Agile. As a common point, they put into place, from the beginning of a project,

a reduced team, composed of a homogenous group of “creators-developers” in a solution

space permanently validated by real users.

Figure 2. — Adaptability or predictability of the methods

Agile risk management

Comparing a classical project management method with an Agile method from the point of

view of project risk management (delays, quality, etc.), could be interesting for a logical

thinker.

� The classical approach tries to reduce the risks using specific and deterministic steps for

which the preventative costs (analysis, detection, follow-up and corrections) are non-

negligible.

� The completely practical Agile methods are based on the competence of the

development teams that they engage in permanent practices oriented to performance

and validation in order to naturally avoid the occurrence of risks.

All the methods find themselves concretely at different degrees on a scale that positions

them from the most predictive to the most adaptive. If one wishes to have a vision of the

application scope of the various current methods, it is necessary to sort them according to

these criteria (figure 2). The differences emphasized this way therefore justify a detailed

analysis of the project environment and of the type of application in order to determine

which aspects of the method will allow for the limitation of the risks that were revealed,

and which methodological service level and application quality will be put into place.

The paradigm of classical methods is predictability. The paradigm of Agile methods is

adaptability.


___________________________________________________________________________

___________________________________________________________________


Let’s be clear: no approach is reduced to just one of these visions. All try to deal with the

contradiction of flexible rigidity, with greater or lesser finesse and with more or less success

in function of the context:

� Predictive methods try to reduce uncertainty from the beginning of the project using

very detailed and precise planning. This elimination of risk implies that the

requirements of the application be fixed.

� Agile methods prefer, starting with an initial planning that is reevaluated regularly, to

adapt themselves to the evolution of the context. The reevaluation will serve as a basis

for making GO or NO GO decision (figure 3) at each major change applied to the initial

project.

Figure 3. — Procedure allowing for evaluation / decision

One of the significant points of the Agile concept requires the involvement of rationally-

motivated resources focused on the service to provide and no longer on the product to

create.

Agility therefore creates a real team dynamic that appeals to both the client and the

developers: the client finds himself in a central role in the development, and the developers

participate in all aspects of the development and work as part of a real team.

In terms of Agility and the Iterative-incremental cycle, the idea of planning is the most

frequently misunderstood. All Agile methods are in fact semi-iterative and begin by an

exploration of the problem and the planning of its solution. Whether this step is called

Release Planning at the project level, Planning Game at the release level, or Standing

Meeting at the daily or Zero-Default milestone level, this doesn’t change the principle that

adaptability must remain under control.

An Agile approach is by its very essence adaptive, it accepts change but measures the

consequences. According to the context, the change and its acceptance present

themselves with greater or lesser acuity and the negotiations are more or less important or

formal. In all cases, questioning the initial plan (the Project contract) requires a new


___________________________________________________________________________

___________________________________________________________________


planning creating a win-win exchange. The tasks concerning the functionalities to introduce

or modify are therefore planned according to their priority, pushing back (to the bottom of

the pile or into a new project contract) the less important functions. This consensual

negotiation implies a capacity of objective evaluation of the tasks to introduce or remove as

well as an Agile toolkit for configuration management.

Although similar based on their common principles and practices, Agile methods offer more

or less complete coverage with regards to the generic concerns of a project manager:

� Respect for the environment (positioning of the project in the information system)

� Management (resource management, planning, follow-up, quality, reporting, visibility)

� Application engineering (Requirements management, creation and development,

validation)

� Change management (organizational impacts and deployment)

All of the difficulty in choosing the right method in function of the general context of the

application or the project context can be found here. By selecting the Agile best practices

as part of a variable methodological level in function of the project, PUMA offers a

homogenous and progressive response to this concern that is as powerful as it is elegant.

Common practices among Agile methods

The heart of the practices common to Agile methods is the following

1 – Common practices linked to human resources

� Participation of the end user in work groups.

� Work groups with decision-making power.

� Autonomy and centralized organization of the team (motivation).

� Specification et permanent validation of the Requirements.

2 – Common practices linked to project management

� Variable methodology level in function of the project goals.

� Management by the goals and the risks.

� Strategic global planning based on rapid iterations.

� Creation in phases by active iterative and incremental.

� Continuous search for the amelioration of practices.

3 - Common practices linked to production quality

� Search for technical creation excellence.

� Graphical view of a necessary and sufficient model.

� View of the necessary and sufficient documentation.

� Reasonable norms and techniques of code quality (metric).

� Architecture based on components.

� Automated change management.


___________________________________________________________________________

___________________________________________________________________


Differentiating practices of Agile methods

Only a few techniques, complementary amongst themselves, or better adapted to specific

typologies and project sizes, differentiate them. Lets now look at the most significant

differences in practices among them.

The particularity of the DSDM method is the specialization of the project participants into

“roles.” This way, executive sponsors, ambassadors, visionary users, and advising users can

all be found in DSDM meetings, without forgetting the animator – facilitator and the

minutes recorders.

� The SCRUM method affirms its difference in the practice of short daily meetings. These

common working sessions have as their objective to improve the motivation of the

participants, to synchronize tasks, to unblock difficult situations, and to increase

knowledge sharing.

� For FDD, the particularity named Mission focused resides in a strong orientation

towards an immediate, measurable goal. It is, in fact, the global ambition of an

iteration that finds itself thereby reinforced. This aspect is also found in RAD in the

form of Focus objectives or in Scrum in the notion of Sprint.

� FDD requires Features Driven Development. This technique characterizes itself by the

notion of the Feature and the Features set (functionalities and groups of

functionalities). The priority is given to functionalities that add value. RAD proposes

similar techniques: delivery with reduced functionality or delivery by theme.

� XP is very focused on the area of application construction. One of its originalities

resides in the approach to planning which expresses itself in the form of a game called

the planning game and that simultaneously involves users and developers. One will also

note particular techniques linked to code production such as programming in teams of

two, collective appropriation of code, re-factoring, and continuous integration. The

RAD method requires, in this way, personal code reviews, then collective reviews, and

integration before each Focus. On the other hand, RAD limits programming in teams of

two to the most strategic sections.

� 2TUP requires a “Y” lifecycle that dissociates and parallels the resolution of functional

and technical questions. The 2TUP lifecycle resembles a domino effect but introduces

an internal iterative form to certain tasks. It is not certain that the cycle really belongs

to an Agile approach. On the other hand, 2TUP requires interesting forms of seeking

quality and performance such as reusable services and generic creation (Framework

and Design pattern) close to the RUP architectural methods.

� RUP is characterized by a global approach named “View 4+1.” The 5 components of

this view are: the Use Case view, the Logical view, the Implementation view, the

Process view, and the Deployment view. RUP also offers, like RAD, a formal and

adaptable Process guide as a guide to activities. In the case of RUP, it is unfortunately

proprietary and tool-oriented.


___________________________________________________________________________

___________________________________________________________________


RAD and RAD2 Processus

� The most important thing that RAD brings to project communication and to the

formalization of requirements is the Group Animation and Reporting (GAR).

� Like the other methods, RAD requires the formation of a specific development team,

SWAT. This team is autonomous, specially trained, deeply motivated, and well-

equipped. It is composed essentially of a unique profile of designers-developers trained

in complementary technical specialties.

� The SWAT works with users in a particular room that is specially equipped to form a

communications base (RAD room).

� RAD also recommends varying the size and the experience level of the work groups in

function of the phases of the project in order to optimize the engagement of resources

and to preserve their interest in work that is adapted to their concerns.

� The high-performance organization of meetings is based on an operating mode of

interviews (sessions in 3 steps) and on techniques of permanent validation.

All methods of project steering should include an operating mode for emergency stops.

However, the study of old predictive methods seems to lead to an optimistic idea: the

authors have never experienced failure and their disciples must follow this path. On this

point, the force of RAD is found in the presence of the animator-facilitator. This resource,

preferably external, must be neutral with regard to the other participants. He or she

responds to a higher authority than all of the project participants. This way, when the

strategic, economic, or technical context of a project evolves, or if the working conditions

degrade, the animator reports the problem to the director who ordered it. The director can

then make the necessary decisions in the best possible time frame and with objective

information.


___________________________________________________________________________

___________________________________________________________________


The PUMA project motor

Once the common practices are isolated from differentiation practices, it is simple to

imagine what should be the optimal method in function of the particular project type :

� The optimal Agile method is composed of the entirety or a selection of common

practices to which it is convenient to add specific practice(s) judiciously in function of

context.

� The entirety of these aspects is obligatorily part of a variable, methodological service

level. Here rests the base of the PUMA project motor.

To optimize its use, the understanding of the project and its environment and constraints is

indispensable.

The PUMA project motor is composed of 3 levels of Agile practices. The second and third

levels respond to more and more important or specialized project requirements.

� The first level is composed of fundamental Agile principles described as usable practices

and a low-level base responding to basic project needs. This base can simply be

composed of the 12 practices of eXtreme Programming or be enriched with several

complementary practices specific PUMA, such as, for example, the use of Facilitated

communication techniques or the Agile solutions for requirements expression.

� The second level introduces two groups of light Project management practices. It

generally corresponds to more important projects that demand increased control or

visibility.

� The third level allows for “à la carte” choices among 15 complementary practices,

which are sometimes complex in their classic versions but are specially “Agilized” for

PUMA.


___________________________________________________________________________

___________________________________________________________________


Figure 4. — Autre vision des itérations (Microsoft)


___________________________________________________________________________

___________________________________________________________________


The fundamentals

Pr inc ip l es

These are operational explanations of the four fundamental Agile

values and the four fundamental Agile principles: collaboration,

interaction and negotiation with users, frequent deliveries,

permanent validation, etc. As simple as they may appear, the

operational implementation of these collaborative modes requires

experience and tenacity on a daily basis.

Methods

All Agile methods are in fact semi-iterative and start by an

exploration of the problem and the planning of the solution. After

this, the adequate choice of the Agile methodology level can be

made. This flexibility permits PUMA to offer an adaptive solution,

regardless of the type or importance of the project.


___________________________________________________________________________

___________________________________________________________________


St ructu re

All Agile methods, including PUMA, are based on a cycle made up of

3 principle phases that are accentuated to a greater or lesser extent:

Exploration of the problem and the possible solution, with regards to

the constraints, Global conception of the solution, Obtaining of the

solution. Keys to global planning are specific to each approach

(Agile, RUP, …).

Mi les tones

The mastery of the temporal dimension of the iterations is capital. It

is on this control point that the pertinence of Agile methods with

regards to project management is played out. Many models

proposing anchors linked to different types of project constraints are

available and calibrated.

Del i verab l es

The various deliverables are dependent on the type of project and

the organizational culture. The important thing is to respect the

Agile fundamentals: that which is useful and sufficient.

XP Extens ion

Bringing programming to the rank of a collective discipline, eXtreme

Programming proposes a coherent ensemble of the 12 techniques

that bring solutions to a great majority of performance and quality

problems in the area of application development. Separated into 3

groups (collaboration, project management, development quality),

these practices are treated in an annex.


___________________________________________________________________________

___________________________________________________________________


Project management

Communicat i on

Teams

All of the resources included in the communication plan intervene

simultaneously from the real beginning of the project. The goal is to

obtain a simultaneous understanding of the problem by all actors

and to end up with the creation of a homogeneous knowledge space.

This approach also allows for the avoidance of wasting energy linked

to repetitions as well as risk of errors, redundancy, or divergence

linked to multiple formulations. The understanding of the

participants is global and unique.

Engagement

In order to optimize the engagement of resources, the

communication plan applies to the work groups a principle of

variability according to the phase or the depth of the iteration. This

way, the presence of high-level executives, indispensable during goal

definition or process reconfiguration, will no longer by solicited

during the detailed specification phases.


___________________________________________________________________________

___________________________________________________________________


Meetings

A collective mode of working characterizes interviews, which require

intensive participation from users. The operating mode of

communications is structured into 3 steps: pre-session, session, post-

session. These practices have as their goal to obtain a real-time

formalization and an immediate validation of requirements

expressed. They require, in addition to the imperative presence of

the “for action” participants from the communication plan (real

empowerment), the availability of an isolated and well-equipped

work area.

Requi rements

Structures

The structure of the requirements expression takes into account 4

classes of applicable requirements at 4 levels of concern: strategy

and creation constraints, functional, technological, and

organizational. According to the advancement of the project, the

requirements are expressed more and more precisely. This iterative,

incremental approach is performed in a unique document at four

depth levels.

Formalization

A minimal formalization is always necessary. It could be simply a

sheet of paper (CRC card or user story) as required by XP, a more

detailed document, a formal model, or a mix of these techniques.

The important thing is to respect the fundamentals of Agility: that

which is useful and sufficient.

Prioritization

The operations of ranking requirements or prioritizing functionalities

are the responsibility of the functional team but are the object of a

planning game with the technical team, who has the knowledge to

allow technical dependencies to be displayed. This practice appears

in the development choice (by usable themes or temporal stability of

components).


___________________________________________________________________________

___________________________________________________________________


Solut ion

Research

It is no longer reasonable to rush into a completely specific

development. The practice of Spike Solution covers an exploration

step (often on the Internet) for available or emerging technologies

(Professional software, Components, Open source, etc.).

Modeling

Agility obliges the project leader to keep in mind that the objective is

an application and not multiple models. A simplified way of thinking,

Agile Modeling, considers modeling in excess and not adaptive for

projects under heavy time or monetary constraints. It proposes an

optimization in the use of models in function of the context.

Architecture

Advice for the identification of optimal granularity and normative

development base. For example, SOA (an approach to design and

construction of services in the form of independent applicative

bricks). The advantage is to produce simple, modular, and weakly-

coupled components that can therefore allow for quick re-

composition of the application framework of the functionalities they

assure.

Creat ion

Construction

Secured construction architecture and preparation of a Construction

Show. An important point: defining, for each phase, the number of

iterations and their precise content. The construction architecture

orchestrates the entirety of the “best practices” of PUMA and/or of

XP. The open and adaptive principle, however, formally assures the

control of the iterations as well as the respect of practices for

technical and functional quality.


___________________________________________________________________________

___________________________________________________________________


Configuration

The GCL manages the state of the components, masters the

traceability of changes, and guarantees restoration benchmarks. The

GCL manages tasks and multiple workspaces, allows for coherent

coordination of development activities, to share files, and to isolate

elements specific to certain tasks. Even for small teams, the use of a

GCL tool has become indispensable.

Delivery

Frequent deliveries that allow for feedback and permanent

validation are one of the most important practices of Agile. The

client expects, at a fixed time, an executable version with reduced

functionality but containing a certain number of planned increments.

The non-respect of the planning game is immediately made visible.

Frequent deliveries allow for an accelerated ROI in certain cases.

Project management extensions


___________________________________________________________________________

___________________________________________________________________


Pro jec t prepara t i on

Estimation

Working from a unique shared knowledge base obtained during

common working sessions of comprehension and validation, the

decisions to continue actions (GO & NoGo) are made collectively in a

win-win model that protects the interests of the project as well as

those of the solution.

Planning

From the requirements, the estimate of the workload, the

development method chosen and the timeframe, a planning is

conceived. The details must reach a level of finesse sufficient to

determine individual tasks. It is then possible to organize these tasks

by group level in order to facilitate the creation of tasks in parallel or

by lot, whether it is temporal or contractual. These logical and

temporal constraints and the dependencies among activities are

therefore introduced.

Development strategy

The planning of an Agile project is fundamentally different from that

of a classic project. A simulation and optimization practice allows, in

the strategic choice of planning, for the evolution of scenarios in

function of diverse project constraints (time frame, cost, perimeter,

quality, visibility, risk). The principle interest in this practice resides in

the immediate display of incidences of each negative option that is

foreseen.


___________________________________________________________________________

___________________________________________________________________


Pro jec t cont ro l

Follow-up

A fixed period, which could be daily, of control operations allows you

to fill in the engagement of resources based on the real

advancement of the work. The objective is to obtain a vision of the

project allowing for verification of the real advancement and

production sufficiency with the quantitative planned objectives. This

activity is an element of the CRM practice Follow-up and supervision

of a project.

Monitoring

For the follow-up of important or specific projects, indicators that

show the evolution of risks can be added. Sometimes, elements of a

quality metric can be added. They can concern the technical quality

of the product (for example, the evolution of the number of

corrected and uncorrected errors) or its functional quality (number

of fixes coming from the client).

Reporting

A dashboard can be part of a larger group of indicators of the

activities of an Information Services Department, produced to

present the information that allows the project managers and

steering committees to make appropriate decisions whether to

continue, reframe, or stop.


___________________________________________________________________________

___________________________________________________________________


Specific project extensions

Facilitation

Agile methods are based on communication practices that bring

together IT professionals and users. There are techniques that allow

for animation of meetings and to facilitate decision-making. In case

of a difficult context, experts can be brought in to accompany

difficult actions. PUMA also proposes a model of Neuro Agile

Facilitation of Collaborative modes.

Functional team assistance

An Agile project team is composed of the ensemble of the parties

involved: representatives of the functional and technical teams as

well as Experts and real users (themselves considered experts in

their activities). This engagement as well as its forms and conditions

are formalized in a document entitled “Project Communication

Plan.”


___________________________________________________________________________

___________________________________________________________________


Prototyping

In prototyping the Construction of the solution, the interviews can

be founded on a weakly structured communication when: users are

available on a regular basis, that they accept the planning game and

the mode of specification-coding-test, iterations are rapid (up to 2 /

day). The principle practice to respect consists of always letting the

user manipulate the application in order to validate it.

Documentation

At each iteration or step (generally phases or benchmarks) and for

each concern, a document with a unique structure (based on 4

classes of Requirements) is used for the formalization of information.

In this unified formalism, the only distinctions can be seen by the

taken by one or the other of the classes of concern or their level of

depth.

Risks

Project management consists of listing and analyzing the risks that

could affect the outcome of the project and the events that could

cause them to occur. The action plan then consists in putting into

place preventive actions, to survey the evolution and the

materialization of risk, and to engage, if necessary, corrective

actions. The level of risk management is dependent on the type of

project.

Processes

The notion of formalized processes is at the base of all standardized

approaches for project risk management (like CMM). Without

introducing a heavy process into the Agile mode, a Check-list of

actions or usual practices from which to determine those that seem

pertinent in the context is generally a useful aide for the different

participants in a project.

QAP

Classical quality imposes an obligation and a formalization of means

but does not specify the result expected. Agile quality proposes an

obligation for the result but requires autonomy of means. The

notion of quality norms is also a principle that agility is often

confronted with. PUMA proposes a Quality Assurance Plan

compatible in its structure with the recommendations of CMM and

ISO.


___________________________________________________________________________

___________________________________________________________________


Business Plan

When the project group must justify its budget by a formalized

return on investment, this very light investment plan model will

guide the actors involved in its justification. Here are treated the

minimum economic, budgetary, and accounting practices that a

project manager must have.

BPM Model

The BPM is based on business models to optimize and adapt the

ensemble of activities. By remodeling the organization around

processes that make up the heart of the organization, the BPM

imposes itself as the principle driver of operational performance.

BPM projects are one option for PUMA project management.

Quality Surveys

Allows for the measurement of non-quantifiable information

automatically such as, for example, the general level of user

satisfaction with regard to communication, the impact of previous

corrective measures (interface ergonomics, conformity to

requirements, functional completeness, level of documentation,

etc.).

Cutting-edge Solution

In a project, 7 layers may be externalized, making up the ensemble

of the solution. The team opens itself up to all concurrent

possibilities and sees them as means to complete the mission. The

objective of this choice is to obtain the best quality at the best price,

in the best time frame in function of the constraints imposed.

Newsletter

A regular and transparent project communication characterizes the

Agile management mode. This practice proposes means of

communication adapted to the size of the projects.


___________________________________________________________________________

___________________________________________________________________


Technical standards

Standards are a key element of SOA and BPM projects. This practice

includes the diverse protocols SOAP, WSDL, UDDI, WS-x, BPMN,

BPEL, etc. and all those that are necessary to model and orchestrate

processes or develop Web services.

Virtual workspace

In the daily practice of project,, and more particularly when the

teams are spread out, the participants need a formal means of

communication to permit them to work as a group. The collaborative

virtual work workspace is therefore seen as a privileged means of

communication.

CMMi TSP-PSP

Agility and normalization are ideas with identical objectives but

philosophically opposites in the way they obtain them. This practice

performs a mapping between Agile practices and the practices of

CMM, TSP, and PSP.

Specializations (BPM – SOA)

Standard but “Agilized” practices


___________________________________________________________________________

___________________________________________________________________


Process (BPM)

Configuration process

The fundamental concept is the complete reorganization of working

processes and the division of tasks in order to reduce the time and

the effort. It consists in analyzing the logic of procedures in function

of the reconsidered finality of the missions of the organization.

Means: rationalization of the activities, reduction of delays,

improvement of reactivity, reduction of costs, improvement of

quality. The action takes into account the ensemble of the drivers of

change management.

Process optimization

Tool for the resolution of “complexity of details.” The detection and

resolution of problems is applied to minor malfunctions that generally

escape the attention of higher levels because of their low visibility. The

Agile enterprise continuously masters the complexity of an evolving

environment by treating, as soon as they are detected, emerging changes.

Collaborative model

Current organizational systems are complex. To master and simplify

them, it is necessary to use the power of collective intelligence. The

collaborative model draws its force from the practical knowledge of

employees whose participation in a systematic search for

improvement is rationally provoked.

BPM toolkit

Recommendation in the area of modeling tool usage and organization of

processes. The level of criticality of the processes directly influences the

management mode and the choice of tools. This also covers the monitoring

aspect (BAM).


___________________________________________________________________________

___________________________________________________________________


Arch i tec tu re (SOA)

Agile modeling

Agility requires that the pilot project keep in mind that the objective

is an application and not multiple models. A simplified way of

thinking, Agile Modeling, considers modeling in excess and not

adaptive for projects under heavy time or monetary constraints. It

proposes an optimization in the use of models in function of the

context.

Granularity - Validation

Advice for the identification of optimal granularity and normative

development base. For example, SOA (an approach to design and

construction of services in the form of independent applicative

bricks). The advantage is to produce simple, modular, and weakly-

coupled components that can therefore allow for quick re-

composition of the application framework of the functionalities they

assure.

Unified vision

The unification of an information system defines a development plan

that is coherent and in phase with the strategy, the business

departments, the processes, the technology, and the current system.

The standard model is made up of four layers: processes,

organization, application, and infrastructure. Unification is one of the

elements of Enterprise Architecture.

Implementation Norms

Standards are also key elements of SOA and of BPM. These practices

bring together the different protocols of SOAP, WSDL, UDDI, WS-x,

BPMN, BPEL, etc. and everything that you need to model and

orchestrate processes or develop Web services.

Bor rowed f rom Scrum

PUMA has a native iterative-incremental-adaptive mode based on rational

management of iterations. PUMU also provides its own meeting techniques

and a principle of roles for development actors. When it comes to particular

aspects of project meetings, it is possible to integrate a vision of Scrum.


___________________________________________________________________________

___________________________________________________________________


The 12 “quality” practices of XP

Figure 5. — A summary of XP principles (Design Up)

XP uses programming as a collective discipline. Here is a synthesis of the 12 fundamental

principles of XP presented in order of their implementation:

� 1 - Planning is a consensus between the client and the developer. As with Risk

Driven Development, it proceeds by priorities (sometimes technical when linked to

dependencies, but most frequently functional). The developer focuses uniquely on the

principle goals and delegates the treatment of the secondary objectives. The principle of

“courage” is applied to negotiations with the client in case of possible divergences.

� 2 – XP teams use metaphors. The metaphor is a high-level abstraction. The

metaphor must not be an overly simple version of the initial concept, but must allow for

the simplification of complexities such as, for example, clarification of functionalities.

The merit of a metaphor is to by synthetic and explanatory. For example: using a

metaphor as a “recipe” to explain a sophisticated process. In XP, the majority of the

metaphors concern the functionality of the application or the architecture.

Technique: Planning Game. The client produces use case scenarios and

prioritizes them. These scenarios are then implemented by the

development team. The project is considered finished when the client

cannot find a new scenario.

Technique: elementary metaphors and analogies are used to describe the

system and its functionality before delivery of real functions, in order to

make it understandable by non-IT workers and users involved in the

development .


___________________________________________________________________________

___________________________________________________________________


� 3 – The application is quickly available in a limited version. The construction phase

it made up of iterations structured into steps (short specifications, development, tests,

feedback from the client). The functional aspects are described in brief, scenarios that

can be implemented and validated immediately by the client. The risk of

misunderstanding is therefore reduced to a minimum. Modifications can be frequent

but concentrated into a very short cycle. The objective is to quickly have an operational

pilot application. The application sections delivered could even be used, with reduced

functionality, if the dependencies with other non-delivered sections are not too strong.

� 4 - The design is simple and focused on current requirements. Without speculating

on possible further evolutions (not expressed), the developer codes the essential, based

on immediate requirements in their order of priority.

� 5 – Development in two-person teams. Two development resources work

simultaneously on the implementation of the same code. Taking turns, they program

and validate the quality in order to product clean, robust, and trustworthy code. In

certain projects, the developers create teams of two only during re-factoring sessions

(as with the RAD method), or when the problem is particularly difficult. This practice is

associated with the rotation of these teams. The ensemble is considered the Agile form

that is the most powerful for collective learning and integration of beginners.

� 6 – Collective appropriation of the code. The team is collectively responsible for

the application, and is assumed to have knowledge of the entirety of the code.

According to this theory, the quality of the ensemble of the code is the responsibility of

the ensemble of the programmers. This practices increases the effective quality of the

code, reuse, understanding, and removes the principle problems linked to turnover.

Technique: Frequent releases. They allow for immediate feedback, while

at the same time offering validated functionalities that can be used.

Delivery frequency is weekly.

Technique: Initial planning based on added value of the expected

functionalities. Simple design and simple coding, in order to facilitate

future evolutions, making the product easy to understand and modify.

Minimal documentation adapted to real needs.

Technique: XP programmers work in teams of two on the same machine.

The first developer (called driver or pilot), has the control of the keyboard

and works on the section of to be written. The second developer (called

partner or copilot) assists by suggesting options or detecting possible

problems.

Technique: The developers frequently reorganize the two-person teams,

which allows for the improvement of the collective knowledge of the

application and the communication at the heart of the team.


___________________________________________________________________________

___________________________________________________________________


� 7 – Sustainable rhythm Weeks have only 40 hours and tired resources commit

errors that are always more costly to solve after the fact.

� 8 – The client collaborates permanently and directly. In order to assure an

improved reactivity and rapid feedback, a representative from the client must be

present for the entire duration of the project. This resource, dedicated to the project, is

responsible for determining the requirements, assigning the priorities, and validating the

tests.

� 9 - Standards of coding. To facilitate the collective appropriation of the application,

the reuse, and the communication, the programmers code in identical styles and with

identical rules (naming norms for variables, methods, objects, classes, files, etc.).

� 10 - An XP program is tested and validated continuously. XP requires, for the

technical part, programming driven by tests (TDD): for each class of application,

developers write a class that tests and verifies the results of these tests.

Functionalities are for their part validated by tests (with and by the user).

Technique: Individual planning does not include overtime for two weeks

in a row.

Technique: A permanent representative from the client is present at the

site. This representative must master the practical knowledge of a final

user, while at the same time possessing a global vision of the final result

to obtain. This is, in general, an operational executive.

Technique: Standards of coding, frameworks, design patterns, naming

conventions, etc.

Technique: Zero-default benchmarks by Test-Driven Development based

on tests coming from a low level translation of integration tests.

Technique: Zero-Default Benchmarks by finalization of permanent

validations obtained from the user during prototyping.


___________________________________________________________________________

___________________________________________________________________


� 11 – Continuous Integration: The modules developed are assembled on a daily

basis or at the end of coding of each benchmark. The starting version of a new code

implementation is thereby performed on a stabilized application.

� 12 – Re-factoring of code. During development, the code is reworked continuously

and progressively. The software is clean and simple. Otherwise, corrections are much

more costly, the design is corrupted, the code becomes fragile, and the application loses

structure.

Using Agile techniques

On the other hand, all Agile techniques are not necessarily implemented in an identical way

in reality within organizations.

Figure 6. — Real use of practices

Agile practices concerning code quality (particularly Pair programming) generate a cost of

realization approximately 20% higher than that of classic development. In return, they

notably reduce the number of residual errors in an application when it is put into

production, according to the study Strengthening the Case for Pair-Programming (Tableau

below).

Technique: Zero-Default Benchmarks by permanent integration of

tested configurations. Construction planned in small modules that are

integrated and tested progressively. Several daily integrations can be

performed daily if necessary.

Technique: Re-factoring by continuous improvement of the code quality

without changing its behavior (comments, respect for naming rules,

simplification, etc.). The result of this “cleaning” is produced regularly and

is validated during collective working sessions with the participation of

the entire team.


___________________________________________________________________________

___________________________________________________________________


Techniques o f Ag i le P l ann ing

Figure 7. — Strategies for Agile planning

Four contradictory constraints and the serious problem of combining them

Figure 8. — Agility recommends: iterative-incremental-adaptive

A simple principle: the perimeter is variable but the techniques and formal choices of

design in view of modifications (prioritization, modularity, encapsulation, weak coupling, …)


___________________________________________________________________________

___________________________________________________________________


Per formance watchers

In numerous domains of IT management, the search for perfection and the complete

reduction of risk are dangerous chimeras. Obtaining relative quality in a given context in

function of precise constraints is in fact the only goal that can be reached. Abandoning the

idea of perfection is the most difficult principle to accept intellectually for the logical spirit

of a rational-minded person, such as an IT professional. It is, however, the search for

absolute quality that leads projects to lose “body and soul.”

Refusing a user request is not an easy thing, it’s true. To avoid the trauma of refusing, it is

preferable to obtain a renunciation from the client. To make this situation possible, it is

necessary to put a price on each functionality. The budgeted amount is, in this case,

transferred to the user. The user is then conscious of the link between budget and

requirements and imposes the priorities.

The management of the budget in regard to the functionalities should be the problem of

the functional team and not of the IT workers. Project management by operational

departments, based on the budget and the time frame, keeping in mind the goals and risks,

is the only form of project management that can stand up to the complexity of modern

development.

It is frequently heard that “the urgency of problems makes having a vision impossible, but it

is in fact the total absence of perspective that makes you a slave of urgency.”

Along the same lines, IT workers often complain about the methodology and its heavy

requirements, and try sometimes to indiscriminately work around them. Complaining

about the method is the same thing as complaining about the driving code. Driving without

knowing it and without respecting it can naturally lead to an accident. And, when it comes

to project management, the victims of the accidents are not only budgets and timeframes

but accidents can even kill enterprises through operations, logistics, sales, and capability for

expansion.

However the “all or nothing” principle does not apply to the method if it is understood well.

An intelligent approach adapts the “level of service method” to the type of requirement.

This economical sizing of effort allows for preservation of basic, indispensable rigor of

management of projects that are “moving” or under constraints.

It is just as indispensable for the project manager to chose with discernment the method

whose cycle will be best adapted to the requirements of the future application. This real

development management must systematically evaluate the diverse forms of obtaining

things (professional software, solutions, components, externalization) from the angle of

constraints (budget, quality, time frames, or resources).

The same way, when it comes to design, the choice of a level and form of model takes up

the challenge of a modeling that is adapted to the specifics of each problem. The

competent designer-developer creates “in view of modifications” and searches for design

techniques that can integrate change, because efficient modeling must evolve in synergy

with the reality it describes.

The Agile movement found its initial inspiration in the resolution of problems with which

teams assigned to IT system development found themselves confronted. Agility therefore

emerged from project groups, where individualism was extreme, in the form of collective

discipline, but at a human scale, of performance and quality.


___________________________________________________________________________

___________________________________________________________________


The Agile enterprise lives at the rhythm of its projects and the energy of this dynamism

assures its existence “Just do it”, such is its empirical and pragmatic slogan. Carrying this

philosophy, the Agile movement consecrates itself to the essential and offers the possibility

to attain simplified power. So lets try to be simple, and with the limits of or actions, adopt,

as a slogan “be Agile.”

For the sake of the quality of which it is a more and more vital component, Agility is not

decreed from the highest structures. Agility emerges from the base of the organizational

pyramid and patiently conquers all the levels, because Agility is fractal. An operational

response to constraints as important as those imposed by the globalization of exchanges,

the principle of collective intelligence on which Agile rests will progressively end up

spreading forms of flat hierarchies.

Agility, at this stage, is the dynamic revolution of organizational systems.

The dilemma of the IT worker is often found in relation to dysfunctions of the organization

that he must code, the organizational aspects that are worrying are most often masked

until the end of the project in the hopes that the application will reveal them after the fact.

Very often, the realization is too late, and a maladaptive application is uselessly developed

that makes the basic problem permanent. Sometimes, the movement for refusing changes

imposed becomes a social problem, and the participants regret the lack of communication

after the fact.

There is a long road to go down before arriving at an optimal system in the majority of

organizations. By dissecting the details of techniques put into place by the Agile

movement, some will be disappointed not to discover anything totally new or miraculous.

In fact, good sense leads to the most theoretical concepts of Agility being seen as simple

improvements in managerial practices.

But, beyond a progression in the state of the art, what is essential in these changes is the

rhythm that they bring to our thought processes. A rhythm of engagement of human

resources. A rhythm in the phasing and in the temporal dimension of projects.

In an environment of accelerated evolution, the dynamics issued from facilitated

communication from a rethought organization, and from more fluid information systems

enter in synergy and impose themselves in the energy of the rhythm. A rhythm of change,

a winning, rhythm, an Agile rhythm.


___________________________________________________________________________

___________________________________________________________________


Table o f i l l us t ra t ions

Figure 1. — PUMA Proposition for the Unification of Agile Methods .................................4

Figure 2. — Adaptability or predictability of the methods ................................................5

Figure 3. — Procedure allowing for evaluation / decision .................................................6

Figure 4. — Autre vision des itérations (Microsoft) .................................................. 11

Figure 5. — A summary of XP principles (Design Up) ..................................................... 26

Figure 6. — Real use of practices ................................................................................. 29

Figure 7. — Strategies for Agile planning ................................................................ 30

Figure 8. — Agility recommends: iterative-incremental-adaptive ............................. 30

___________________________________________________________________

Concerning the use of the PUMA method, its author Jean-Pierre Vickoff as well as

TEAMLOG, the company with which he collaborates in creating TMF (Teamlog Methodology

Framework), wish to render the theoretical principles accessible to the entirety of the

profession by regularly publishing, via the media and the Web, on its structure and its

practices by the intermediary of professional organizational principles www.Entreprise-

Agile.com

© Jean-Pierre Vickoff. The text and graphics in this document have been registered and copyrighted by the author Jean-Pierre Vickoff, as well as by the medias who initially distributed them. You may copy and distribute, without alterations, all or part of this document in any format, commercially or non-commercially, on the condition that this licence and copyright notice are reproduced on each copy, and that you do not add any additional restrictions. You may also, while respecting the author's ownership, quote brief passages.

puma - entreprise-agile.com · puma is a global framework of the agile enterprise ... the 2tup...

Documents