Recensie: De startup methode

In het boek ‘De startup methode – Ondernemerschap als succesfactor in elke organisatie’ laat de auteur Eric Ries zien hoe je de Lean Startup-mentaliteit en –technieken kunt toepassen in iedere organisatie. Hoe zorg je ervoor dat je voortdurende innovatie mogelijk maakt binnen de bestaande organisatiestructuur? Hoe creëer je draagvlak en welke kansen en bedreigingen zijn daar bij het opschalen van zo’n interne startup?

Het boek bestaat uit drie delen. In het eerste deel kijken we naar het moderne bedrijf en zien we waarom traditionele managementpraktijken niet langer voldoen. Het tweede deel beschrijft een routekaart naar transformatie of te wel het ‘hoe’ van de startup-methode. Het laatste, kleinere, deel drie ‘het grote plaatje’ gaat in op de vraag wat er gebeurt als het transformatieproces ‘voltooid’ is. Door het hele boek heen krijgen we een veelheid van voorbeelden uit de praktijk van de auteur zelf bij bedrijven zoals GE, IBM, Intuit en de overheid van de Verenigde Staten.

In het eerste deel wordt het moderne bedrijf vormgegeven. Wat betekent onzekerheid, hoe gaan we om met mislukkingen, wat is de rol van de leider als de manier waarop bedrijven volwassen worden, verandert en waaraan kan je een modern bedrijf herkennen. Een volgend hoofdstuk zet ondernemerschap als ontbrekende functie centraal en zoemt in op de startup als atomaire eenheid van werk en het integreren van startups in de organisatie. Het gaat om een startup state of mind. Het draait om het team. Denk groot. Begin klein. Schaal snel. We krijgen een rondgang langs verschillende startup-werkwijzen. Een afzonderlijk hoofdstuk is gewijd aan het opfrissen van kennis van en lessen uit de lean startup en krijgen we vele types en voorbeelden van MVP’s. Dit deel wordt afgesloten met een hoofdstuk over een managementsysteem voor innovatie op schaal. Binnen de startup-methode worden algemeen en entrpreneural management met elkaar verbonden middels de volgende gedeelde waarden: toegewijd aan de waarheid, discipline, uitmuntendheid en voortdurende verbetering.

In het tweede deel staat het ‘hoe’ van de startup-methode centraal. Verschillende hoofdstukken volgen de drie fasen van de startup-methode: kritieke massa, opschalen en dieperliggende systemen en biedt daarmee een routekaart voor transformatie. Hierbij zijn de drie fasen op zowel team-, divisie- als ondernemingsniveau door te lopen. Per fase worden veel voortkomende patronen en voorbeelden besproken waarbij de kanttekening gemaakt wordt dat het geen stap-voor-stap handleiding betreft.

Fase een: kritieke massa:

1. Klein beginnen
2. Cross-functionele teams samenstellen
3. Het gouden zwaard (doorklieven bureaucratie)
4. Ontwerp een goed experiment (hypothese, vervolgactie, risicobeheersing, connectie met blinde aanname)
5. Ontwikkel nieuwe manieren om succes te meten (leidende indicatoren)
6. Werk met uitzonderingen
7. Leg deze manier van werken uit in termen die de organisatie kan begrijpen.

Fase twee: Opschalen:

1. Stel vast met welke uitdagingen de pilotteams te maken kregen
2. Implementeer een wijdverspreide uitrol
3. Vind pleitbezorgers op directieniveau en maak gepast gebruik van hun expertise
4. Train vertegenwoordigers van alle interne functies
5. Zet een inhouse coachingsprogramma op
6. Mechanismen voor het opzetten van gedoseerde financiering en groeibesturen.

Fase drie: Dieperliggende systemen:

1. Van poortwachtersfunctie (vertragend) naar faciliterende functie (versnellend). Maak handleiding in begrijpelijke taal met parameters waarbinnen innovatieteams vrij zijn hun werk te doen
2. Dubbelrollen: ondersteunen ondernemersinspanningen van product- en projectteams, en ontwikkelen ondernemersprocessen om hun eigen functies te stroomlijnen
3. Testen en valideren
4. Inbakken van de ideeën en de werkwijze in het DNA van het bedrijf.

Downloaden: Startup methode (QRC, 180103) v1.0

Dit deel wordt afgesloten met een uitgebreide toelichting op de ingewikkelde materie van innovatie-accounting. Wat is innovatie-accounting, de rol van het groeibestuur en de drie niveaus (dashboard, businesscase en netto contante waarde) om daarmee de vage taal van het ‘leren’ naar de harde taal van dollars of euro’s te vertalen.

Groeibestuur verantwoordelijkheden:

• Optreden als centrale verantwoordingsinstantie van de startup.
• Optreden als centraal punt voor informatievoorziening over de startup.
• Gedoseerde financiering bieden aan startup-teams.

In het laatste deel ziet de auteur als belangrijkste toepassing van de startup methode het opbouwen van een open en innovatieve samenleving. Hoe komen we tot een overheidsbeleid dat ondernemersvriendelijk is en de startup methode als een nieuwe maatschappelijke beweging om daarmee een antwoord te hebben op de volgende punten:

• Een epidemie van kortetermijndenken.
• Een gebrek aan kansen op het gebied van ondernemerschap.
• Een gebrek aan leiderschap.
• Geringe groei en instabiliteit.

Conclusie. Als je de Lean Startup gelezen hebt dan is dit boek een mooie aanvulling en biedt je praktische handvatten, vele voorbeelden en verdieping om de continue transformatie naar meer agility vorm te geven door de startup als bouwsteen in te zetten en ondernemerschap te promoten. Maar onderschat het niet, om als bedrijf zo’n transformatie door te maken is een zeer zwaar traject zoals dit ook helder naar voren komt in dit niet altijd even vlot te lezen boek.

Bestellen: De startup methode

Book review: The Product Samurai

Chris Lukassen wrote the book The Product Samurai. A Product Manager’s guide to continuous innovation.

An easy to read book to get a good idea of the Product Manager’s role within an agile environment, with lots of examples, techniques to be used, figures, and tables and on many places analogies with martial art experiences and great black and white martial art pictures of the author himself with quotes. Every chapters end with a kata, an individual training exercise. After reading you want, if you aren’t, to be a product manager.

To explain the title, the author made the comparison with the seven principles a Samurai warrior used. In product management the same apply and by following these you can become a Product Samurai. The seven principles are: Integrity, Respect, Courage, Honor, Empathy, Sincerity, and loyalty.

The book is divided in three parts following the three key aspects of product management: vision, winning and crafting.

Vision (Discovering, Defining): The discovery process and ways to identify and develop innovation potential. You get many examples and techniques that will help you to discover a product vision. To mention a few techniques:

• The innovation granularity pyramid with four levels (feature, product, portfolio/segment, industry) of innovation and provides a framework for defining a product in relationship to the overall business strategy.
• The Flux Capacitor technique. A brainstorming based approach that involves concept diagram mapping combined with traveling to and from the future.
• The 3 x 3 framework (status quo, observations, story, insight, opportunity, analogy, solution, advantages, ethos): To pitch your product and it will help to define your product vision.
• The value model canvas: compare the business model canvas and the lean canvas. Here we focus on customer needs (wants / rational, fears / hidden, needs / emotional) and product benefits (benefits /why?, experience / what?, features / how?)
• Rolling wave planning and product roadmaps to create transparency. To rank the goals, the following formula is explained: (Market Evidence x Problem Impact x (Usability + Vision + Buying + Competitive Advantage)) / Estimated effort.
• The customer journey map to frame your opportunity and translate this into a business case.
• Last but not least: genshi genbutsu: to truly understand, you must go to the real place. Vision comes from the real world out there, through real people with real needs.

Winning (Growth, Steer, Observe): The tools (growth models and tools that create feedback loops) that help create winning products once the vision is in place.

Here you get many product strategy techniques:

• The product adoption cycle: innovators, early adopters, early majority and the late majority/laggards
• The AARRR (Acquisition, Activation, Retention, Revenue, Referral) framework. This framework provides you a series of metrics you can use to measure performance and determine improvements.
• Eric Ries’ three engines of growth: paid engine of growth, viral engine of growth, sticky engine of growth.
• Cohort analysis. To expose groups of users to alternative versions of the product to figure out which performs best (e.g. A/B testing).
• Pruning the product tree. A tree analogy to achieve the shape you envision by plotting (post-its) existing products, latest product’s feature additions and optimizations, etc.
• Gap, SWOT and the Ishikawa diagrams
• A persona is a narrative, or story description about the user that resonates with the team and the stakeholders on an emotional level.
• Customer experience testing. It starts by testing two things: usability (can they use the product) and discovery (context of the product: who, why, when, where, what, what for and how)
• Alternate realities: or product variants to test with real customers (multi-variant testing)
• Blue oceans and red oceans. It is easier to capture market value when you create a new market (blue ocean) than to fight the competition in a saturated market (red ocean)
• ERRC quadrant: how does your solution enable your growth (Eliminate, Raise, Reduce, Create)
• The expanded buyer utility map: it shows the six utility levers (productivity, simplicity, convenience, risk, brand image, environmental friendliness), combined with the ten stages of the buyer experience cycle (awareness, evaluation, selection, purchase, delivery, use, supplement, maintain, discard and recommend).

Crafting (Practical, Meta): The art of product creation. Here we closely follow the path of the product manager.

To gain knowledge you have to go through three phases: Shu (just copy what you see), Ha (understand why you are doing it), Ri (learn from your own practice). In this part we got an explanation of Eric Ries’ Lean Start-up and especially the usage of a Minimum Variable Product (MVP). Also here several techniques are explained:

• Design thinking: using a five-day challenge to go through the six stages of design thinking: understand, define, diverge, decide, prototype and validate.
• Judo Solution: follow the central guiding principle of judo: “maximum efficiency with minimum effort”. Compare with the MVP.
• Double loop learning: replace “knowing” (your product features and value) with “assuming” (unvalidated insights about user’s requirements). So as a Product Manager you plan, do check and adjust, think again and make new assumptions. Here we get a new user story format: As a <persona> I have a <problem> which causes me <impact> as can be seen with <metrics>.
• Three horizons of growth: now, next and beyond.

To become a great Product Manager, a Product Samurai you have to comply with the seven principles. To succeed you must show passion, empathy and compassion, focus and tenacity and decisiveness. You have to practice and train to develop the following skills: observation, questioning, association, networking, experimenting, planning, analysing, detail orientation and self-discipline.

Conclusion

A great book to read if you are a Product Owner or Product Manager and want to achieve continuous innovation. It will help you to understand the role you were asked to start playing or you are already playing and what you can do, what techniques you can use to become a great Product Manager.

To buy: The Product Samurai

PRINCE2 Agile webinar recordings

Friday February 12th, I gave, on request of Fortes Solutions, the PRINCE2 Agile lecture twice (NL, EN). In total approximately 600 persons registered for these webinars. Due to the webinar system limitations we had to disappoint 150 people. I am sorry for that. The good news is that both sessions are recorded. In these 45 minute lectures I gave a brief overview of the new PRINCE2 Agile framework. The attached picture shows in a glance the overview of this new framework and showing the topics I discussed: PRINCE2 2009 version, Scrum, Lean startup and kanban, the behavior aspects, the usage of the Agilometer and the Cynefin framework as well as fixing and flexing of the six project control parameters.

The first recording is my lecture in English and the second one is in Dutch.

If you want to know more about PRINCE2 Agile feel free to enroll for one of our PRINCE2 Agile training classes. The next one will start in April in Hilversum, Netherlands. See: Hedeman Consulting.

The Lean Startup in six lectures by Eric Ries offered by Udemy

In my post regarding PRINCE Agile, a first overview and PRINCE2 Agile in one picture, I explained that PRINCE2 Agile makes use of the Lean Startup philosophy.

To get a better understanding of this philosophy I reviewed Eric Ries’ book The Lean Startup (see the one-pager on my blog).

I already received several questions regarding the MPV (Minimum Viable Product). It looks like that people are confused and think that at least all ‘Must Haves’ must be part of the product. See attached screenshot from a online lecture from Eric Ries about this MVP. This screenshot comes from a training offered by Udemy.

Udemy (www.udemy.com) is an online learning marketplace, where 8 million+ students are taking courses. They offer 32,000+ courses taught by an expert instructor, and every course is available on-demand. You can buy course by course.

As stated they offer an online course regarding the Lean Startup. In this module you can find:

• Over 6 lectures and 2.5 hours of content!
• The basic principles of Lean Startup methodology
• How to create a system of “innovation accounting” within your company so that everyone is building products that meets customers needs
• The easiest and fastest ways to build minimum viable products so you can get your product launched as quickly as possible
• Tactics for experimenting with landing pages, A/B tests, MVPs on real customers
• What “The 3 A’s” are and how to make sure all of the metrics you look at are actionable, accessible and auditable
• And much more…

I liked the setup of these Lean Startup lectures and it definitely helps you to understand MVP, pivots, testing hypotheses, etcetera. The six videos offer introductions by Eric Ries and interviews with several people to talk about specific topics. E.g. Farb Nivi on Innovation Accounting, Hiten Shah on Creating experiments to test hypotheses, Janice Fraser on Lean user experience and David Binetti on the art of the pivot.

For those who want to hear/see more have a look at YouTube. Eric also gave a lecture at Google. See below.

Book review: The lean startup, how constant innovation creates radically successful businesses

Just finished ‘The lean startup, how constant innovation creates radically successful businesses’ by Eric Ries. This is one of the books that was used in creating the PRINCE2 Agile framework. In my previous post I gave an overview of this new PRINCE2 Agile framework. See PRINCE2 Agile, a first overview.

PRINCE2 Agile briefly explains the lean startup and the usage of the Minimum Viable Product (MVP). Lean startup follows the Build-Measure-Learn cycle and is a good example of agility. The book focuses on entrepreneurs and helps you to set up a new business. The philosophy can easily be applied in your projects to find out if you understand your customer correctly by creating a hypothesis and model, build a MVP and test. The sooner you fail with your test the earlier you can learn from what you have done and adapt.

I created a one-page overview (to download: Lean startup (QRC, 150717) v1.0). The MPV can have many forms. Be aware that the MPV is not necessarily the smallest product imaginable (minimum usable product). It can be a simple video, a concierge model, a smoke or split test, or an early prototype and many more. Make sure the MVP helps you to learn and keep it as simple as possible. The faster you can start testing, the better. After analysing the results you have to decide to pivot (the test fails so you have to change the MVP or change your vision and leaps of faith) or to persevere.

The book is divided in three parts. Part one: Vision, part two: Steer and part three: Accelerate. The final chapter in the book is titled Join the movement. It contains many references to interesting websites/blogs and required and future reading.

PRINCE2 Agile, a first overview

During the last Gartner PPM Summit, 8 and 9 June 2015, in London, it was confirmed again. “One size does not fit all” is true in the world of projects too. Are reliability and cost the most important or are we going for brand awareness, sales and customer experience? Do we have to deal with long-term or short-term contracts? Is the focus on IT only or enterprise-wide? Are we talking about frequent or a limited number of deliveries within short or long lead times? Many debates we see in the media, PRINCE2 versus Agile, Scrum only but what about governance or the business case? The answer from Axelos is PRINCE2 Agile that combines the best from both worlds to carry out a project properly.

Introduction

PRINCE2 Agile includes both the existing PRINCE2 as the agile way of thinking. The agile way of thinking must be seen as agile behaviour, concepts, frameworks, focus areas and techniques. The existing PRINCE2 principles, processes and themes remain, but should be tailored using the agile way of working and the project itself. PRINCE2 Agile searches for the best of both worlds where the emphasis lies in the use of PRINCE2 within project direction and project management and the agile approach in the product delivery. Depending on the project situation you can apply more or less of the PRINCE2 or agile way of thinking. See Figure 1.

Figure 1. Mixing of PRINCE2 and Agile

six project control parameters: PRINCE2 uses six project control parameters: time, cost, scope, quality, risks and benefits. All six have their own tolerances. PRINCE2 Agile recognizes the same six project control parameters except that within an agile approach time and cost are fixed (no tolerance), quality and scope can be partially flexible (no tolerances for the essential criteria and products) and the risks and benefits can be fixed or flexible (tolerances in consultation between the project manager and the project board).

The reasons for flexing are explained by the five targets:

1. Be on time and hit deadlines
2. Ensure the required quality
3. Embrace change
4. Keep the team stable
5. Accept that the user doesn’t need everything

In the following paragraphs I explain how the principles, themes and processes can be customized to incorporate the agile way of thinking.

Principles

The seven PRINCE2 principles remain. However PRINCE2 Agile adds five behavioural components to it:

• Transparency – regarding the progress of the project.
• Collaboration – between the project team members and stakeholders.
• Rich Communication – consultation over email, visualization over text.
• Self-organization – empower and facilitate the project team.
• Exploration – curiosity over obeying the rules.

The processes

Starting up and initiating the project: Make during starting up a project, an initial estimate how far you can go with embedding the agile way of working in the project. To perform this agile risk assessment, PRINCE2 Agile developed the Agilometer. This evaluation must be repeated during the initiation stage and the various stage transitions.

Agilometer: The Agilometer consists of six key areas to be used in the assessment of the application of agile within the project. The six key areas are:

• Acceptance of agile;
• Advantageous environmental conditions;
• Ability to work iteratively and deliver incrementally;
• Ease of communication;
• Level of collaboration;
• Flexibility on what is delivered.

The project manager performs this analysis and looks for each key area for possible or necessary improvements and gives insight how agile the project can be established. So, it’s not a matter of yes or no. It also makes no sense to calculate an average of the six sliders. This Agliometer is comparable with the agile project questionnaire from DSDM.

During Start up and Initiating the project it’s key to find the right balance between the risks associated with the project and the level of detail the issues should be sorted out beforehand. The aim should be to maximize the freedom to steer the project during the implementation of the project. Sometimes within agile they call Starting up and Initiating the Project stages, sprint zero or the discovery phase. The Project Product Description is then referred to as the project backlog.

Cynefin model: PRINCE2 Agile uses the Cynefin model from Snowden to determine the level of uncertainty and thereby what the most logical approach and management of the project. The Cynefin model identifies five domains:

• Obvious: clear cause-effect relationship
• Complicated: cause-effect relationship is not clear
• Complex: cause-effect relationship can only be explained in retrospect
• Chaotic: cause-effect relationship can’t be indicated
• Disorder; unclear to which domain the change belongs.

With clear cause-effect relationships there is usually a simple project or ‘business as usual’. Projects we find especially in the complicated and complex domains. The more complex in its environment the more an agile way of working is desirable. If the cause-effect relationship can’t be indicated, then a process approach is the most appropriate approach.

Directing the project: With ‘business as usual’ the product owner directs the agile process. In a project environment, we see the PRINCE2 roles of executive (sponsor), senior user and senior supplier. For simple projects, some of these roles can be merged, e.g. the executive and senior user role.

In all cases it is important that collaboration is based on trust, and that therefore there is no blame culture. Management by exception is than characterized by empowerment and rich communication.

Controlling a stage / Managing product delivery: Within PRINCE2 Agile it is possible that there are no stages but only time boxes, whether inside releases or increments. Releases or increments can also be defined as stages, if at the end of which an explicit go / no-go decision is planned. It is important to plan around the functions (sub-products) and use flexible work packages that emphasize that teams are as much as possible self-organizing, communicating rich and make management by exceptions possible. Focus is on the result to be delivered, so the scope and quality criteria and the control of the agile related risks. The Controlling a Stage is characterized by transparency, collaboration and rich communication, self-organization and flexibility.

To have frequent releases makes it possible to harvest benefits as early as possible, obtain fast user feedback and reduce risk. It provides confidence that the project will deliver and it will help to obtain and retain the stakeholders’ interests. Small releases are often easier to take into production. Of course, the releases needs to be planned so that it is clear when which of the functions (sub-products) are delivered.

Manage a stage boundary: During managing a stage boundary (increments or releases), it is important to assess how much is produced, which what quality and what benefits have been or may be harvest. In addition, an assessment of the agile way of working, and determine if the method used must be adjusted. This corresponds to the retrospective in Scrum. Of course, this step should take place with as little as possible ceremony.

Closing the project: Within agile there is not much described on the formal closure of a project. Usually there are already several interim products delivered. PRINCE2 Agile emphasizes on the following activities that may or may not be conducted in workshop form. Rate the final outcome with respect to the original plan. Agree on the formal user acceptance. Evaluate the process as well as the usage of agile in the project. Finalize the required documentation. Transfer the result formally to the customer.

Themes

All themes within PRINCE2 can be found in PRINCE2 Agile. Some topics are within the agile way of working more important than others.

Business justification: The business case for the entire project is drawn up during Starting up / Initiating the project and updated at the end of each stage. It must also clearly define the minimum usable product, based on the prioritized list of requirements (must-haves). The added value of the individual functions will be prioritized in the different timeboxes. A requested function or feature that adds no value to the organization will not be realized.

Organization: The known roles of executive (sponsor), senior user and senior supplier still exist in an agile project but from a user perspective often expanded with the role of Business Ambassador (DSDM) or Product Owner (Scrum). The Project Manager has a more facilitating role than a managerial role (servant leader). Depending on the self-organizing ability of the development team and the Agile method used, the role of Team Manager can be filled formally, or by a Scrum Master (Scrum), or be fulfilled by the team as a whole. For the Project Manager, it is important that he has at least a point of contact in the team and that in the team someone from the user side is involved (business ambassador or product owner).

If the project consists of only one agile team, then a simple agile approach with one product owner and scrum master suffice. Consists the project of more teams than the different product owners and scrum masters must tune their work and progress (scrum of scrums).

Plan: A project is finite. For each project there must be a planned end date. Therefore you need an overall project plan. This also distinguishes the agile project approach to agile maintenance approach as part of business as usual. The project plan to support the agile approach, however, should be limited to the main topics/functions. It has to be just sufficient to be able to determine the total duration and the total budget, assuming sufficient (flexible) tolerances within the to be requested functionalities. Per increment or timebox the project plan will be more detailed. Within an agile approach the time and cost tolerances are set to zero and the flexibility will be found in the tolerance of the functionalities.

PRINCE2 Agile prescribes no mandatory planning technique and no planning approach. From the agile way of working it is appropriate to establish the project plan empirically in consultation with the project team and set the various timebox plans by the delivery team themselves. These delivery teams can make use of a simple scoring system such as planning poker, or T-shirt planning.

Progress monitoring: As with the PRINCE2, PRINCE2 Agile focuses on the product to be delivered. However, PRINCE2 Agile is less about whether it will succeed to deliver the product as defined within the given time horizon, but how much functionality can be completed within the given time horizon. For progress reporting at project level you can make use of stand-up meetings, information radiators, team boards and visual burn-down or burn-up charts that are used at the team level. In addition agile teams frequently make use of the concept of velocity. This is a measure of the production of the development team in a certain period of time (timebox), with which one can also determine the extent to which a team learns, and hence can realize more in the course of time.

Risk Management: Risk management gets less attention Within PRINCE2 Agile because many project risks are already minimized by the agile approach. But due to a possible discrepancy between the agile approach and more conditioned environment new project risks can be introduced too. In order to identify these risks, the Agilometer is introduced. As a result the project approach can be tailored to accommodate the given situation as showed in the Agilometer. PRINCE2 Agile uses the five behavioural components to control possible project risks too.

Quality: Within PRINCE2 Agile is important to develop a less formal quality management strategy, but you still need to capture it: what and how is tested within the development teams and what, how, and by whom will be tested at the end of the time boxes. Within the Project Product Description we find the description of the needed necessary changes in the organization based on the result to be delivered. Further, the acceptance criteria and the “Definition of Done” are central to the quality theme. Quality criteria of the requested products can be found in the product descriptions on the project level and in the user stories at the team level.

Change management: PRINCE2 Agile embraces change. The more changes, the better the product is likely to be connected to the company strategy and the greater the user involvement, and thus the probability of acceptance of the product. It is important to make a distinction between the changes in the officially fixed configuration (project product description), which should be monitored formally at project level and the further elaboration of that configuration within the development team and user representatives (informal). Adding new parts means that those new parts needs to be exchanged for other less important parts (trading), because there are no time and cost tolerances within agile projects.

Lean start-up: Within the philosophy of embracing change, PRINCE2 Agile also introduces the principle of lean start-up. Lean start-up focuses on learning and act accordingly. Try as fast as possible (fail fast). But take as soon as possible (parts of) products in use, and learn from them. The product that processed most of the learning experiences, usually delivers the most value.

Agile and supplier contracts

Agile in combination with strict supplier contracts remains a challenge for many. Within PRINCE2 Agile this problem is worked out in a clear manner and therefore also provided various guidelines. Useful recommendations are:

• Focus is on the end result (outcome) and not on the final product (output);
• Define the level of user participation during the project;
• Describe, in terms of time, important delivery milestones (sprints and / or releases);
• Include a clause that the project board may decide to stop prematurely;
• Take a bonus / penalty clause on the basis of the quantity of delivered end result;
• Define global requirements and prioritize them. Detailed requirements will ask for too many adjustments during the project;
• Keep the contract as simple as possible (depends on mutual trust).

Agile Frameworks

PRINCE2 Agile discusses the use of the Scrum and Kanban frameworks and related techniques such as user stories, MoSCoW prioritizing, frequent releases, planning poker and T-shirt estimation extensively.

A Dutch version of this article will be published in due course (IPMA Projectie).

PRINCE2 Agile in one picture

In one of my previous posts I already gave some preliminary facts regarding the new PRINCE2 Agile framework. See: preliminary facts 

In this post you get a simple overview regarding PRINCE2 Agile. This framework is based on blending PRINCE2 and agile together. PRINCE2 is strong in the areas of project directing and project management and agile is strong in the area of product delivery. It’s not a matter to chose between PRINCE2 or agile but to decide how far you can go using specific agile ways of working by tailoring the PRINCE2 approach. The new framework offers the Agilometer to understand how far you can go using agile. Together with the usage of the Cynefin framework created by David Snowden you must have a good view how to blend PRINCE2 and agile.

For the PRINCE2 part this new framework is based on the existing PRINCE2 2009 version. For the agile part they use The definitive guide to scrum by Ken Swaber and Jeff Sutherland (integral copy included in the manual) and material based on The lean startup by Eric Ries and Kanban – Successful evolutionary change for your technology business by David Anderson (see book review).

Besides these frameworks you can also find explanation of behaviour in the areas of collaboration, self-organisation, transparency, rich communication and exploration.

In a next post I will give a summary of PRINCE2 Agile based on the official PRINCE2 Agile manual.