Re: Strange agile articles

OK Massimo, I did it. I read the http://prince2agile.wiki/An_
Overview_of_PRINCE2_Agile

I'd rather do SAFe, and that isn't a complement.

Strange Agile indeed.

First off they redefine Agile. Apparently the manifesto wasn't good enough.

PRINCE2 Agile's Definition of "Agile"

PRINCE2 Agile prefers to ignore the simple definition of Agile as the use
of adaptive lifecycles, and uses a popular description instead:

*The term ‘agile’ is very broad and is viewed in many different ways
throughout the agile community. There is a set of well-known frameworks
referred to as ‘agile methods’ and there are also well-known behaviours,
concepts and techniques that are recognized as characterizing the agile way
of working. But there is no single definition of agile that accurately
encapsulates them all, although the Agile Manifesto (see Figure 2.1) comes
the closest to achieving this.* -- Official manual, Page 9

*The term ‘agile’ when used on its own in this manual refers to a general
family of behaviours, concepts, frameworks and techniques that is widely
accepted throughout the agile community as being part of the agile way of
working. The terms ‘behaviours, concepts, frameworks, and techniques’ also
encapsulate other similar terms such as methods, principles, values,
mind-sets and approaches.* -- Official manual, page 21

This description, which can be reduced to "it's Agile when it's commonly
referred to as Agile", is very risky for companies willing to become Agile
by leading them to the wrong path, and creating poor results.
External Links

   - Agile Practices Vs. Agile Methods
   <http://mplaza.pm/agile-practices-vs-agile-methods/>
   - Agile cannot be used in every project
   <http://mplaza.pm/agile-cannot-be-used-in-every-project/>




They have an Agilometer
http://prince2agile.wiki/The_Agilometer

They recommend fixed price fixed scope contracts and think adaptation
(scope change) is bad

...Then Work Packages <http://prince2agile.wiki/Work_Package> would be the
basis for creating the release plans and iteration plans (Team Plans),
while their high-level aspects have been defined in the Project Plan and
Stage Plans from the beginning.

Delivery team members are empowered to decide on minor changes, as long as
they do not affect the Category:Management Products
<http://prince2agile.wiki/Category:Management_Products> directly.
Otherwise, the usual change control process would be run, with escalations
based ontolerances <http://prince2agile.wiki/Targets>. Therefore, a limited
level of adaptation exists in the delivery layer, and higher-level
adaptation would happen in the higher layers, and specially in the Managing
a Stage Boundary <http://prince2agile.wiki/Managing_a_Stage_Boundary>
 Process.

The suggested approach in PRINCE2 Agile is to have fixed time and cost for
the project, similar to DSDM Atern. Consequently, the contract
<http://prince2agile.wiki/Contracts> would be fixed-price. When the
customer asks for a new feature, they have to swap it for one (or more) of
the initial features mentioned in the contract, with the same size.

PRINCE2 Agile defines Agile <http://prince2agile.wiki/Agile> as a set of
behaviors and practices rather than the use of an adaptive lifecycle, and
consequently, the manual is focused on providing generic guidelines on
common behaviors in Agile environments rather than providing a complete
integration between the PRINCE2 process model and Agile lifecycle.


OK, really bad taste in my mouth. I need to go gargle with Lagavulin.

Thanks for that Massimo!

Robin.