Mini webinar PRINCE2 Agile Agilometer

On request of several of my followers I created a mini webinar of the PRINCE2 Agile Agilometer. According to the official PRINCE2 Agile manual, the Agilometer is a tool that assesses the level of risk associated with using agile in combination with PRINCE2. This allows PRINCE2 to be tailored in such a way that best mitigated the level of risk. The Agilometer should evolve to suit the needs of each organization.

In this approximately 10 minutes mini webinar I discuss the composition of PRINCE2 Agile before I go into the Agilometer slider details and the relationship with the management layers of PRINCE2.

Boek launch: Scaling agile in organisaties – Wegwijzer voor projectmanagers en agile leads

Tijdens het 20ste BPUG seminar vond ook de launch van mijn nieuwe boek plaats. Altijd leuk zo’n mijlpaal en ondertussen al vele enthousiaste reacties ontvangen. Ook hebben wij, Bert Hedeman, Hajati Wieferink en ik van de gelegenheid gebruik gemaakt om de nieuwe naam van onze organisatie wereldkundig te maken. Het is geen Hedeman Consulting meer maar HWP Consulting om daarmee de complementaire kennis en ervaringen van ons drieën te benadrukken.

Boek preview

Scaling agile in organisaties gaat over organisaties die stappen willen zetten om teams meer autonomie te geven door besluitvorming decentraal neer te leggen en managementlagen en managers weg te halen om de teams zelforganiserend te laten optreden.

Business agility (oftewel de vraag: hoe wendbaar is je organisatie) is meer en meer onlosmakelijk verbonden met het bestaansrecht van organisaties. Het snel en accuraat kunnen inspelen op consument- of klantbehoeftes is van levensbelang. Iteratief en incrementeel ontwikkelen biedt betere oplossingen en waarborgen om producten fit-for-purpose te laten aansluiten bij de eisen van klanten; beter dan een watervalaanpak waarbij alle eisen al aan de start gedefinieerd worden en gedurende het ontwikkelproces in principe bevroren blijven.

Vele organisaties hebben stappen gezet om teams meer autonomie te geven door besluitvorming te decentraliseren. Ze hebben managementlagen en managers weggehaald om de teams zelforganiserend te laten optreden. In dit eerste deel komen enkele agile aanpakken van het eerste uur aan bod. Dit betreft agile aanpakken op teamniveau. Daarnaast beschrijf ik wat het betekent als er meerdere teams met elkaar moeten samenwerken.

Kijkend naar zo’n agile team, werkend met Scrum (met voorgeschreven rollen) of Kanban (zonder voorgeschreven rollen), komen de vragen op of er in zo’n constructie met een ontwikkelteam en Product Owner (typische Scrum-rol) nog wel sprake is van een project en of er dus nog wel plaats is voor een projectmanager. Een project is een tijdelijke multifunctionele organisatie, werkend met een start- en einddatum, opgezet om een uniek product of unieke dienst of release van een product of dienst op te leveren, rekening houdend met onzekerheid en onderbouwd door een businesscase, waarbij de juiste mensen voor het projectteam worden gezocht. Er zijn ondertussen verschillende cases bekend van organisaties die alle project- en programmamanagers hebben laten afvloeien en hiervoor in de plaats zijn gaan werken met Product Owners en Scrum Masters.

Zelf ben ik van mening dat het compleet afbouwen van alle project- en programmamanagers een brug te ver is. Wel geloof ik dat het aantal project- en programmamanagers bij veel organisaties sterk kan afnemen, maar er zullen situaties zijn waar toch een beroep op project- en/of programmamanagers gedaan moet worden. Wellicht worden ze dan anders genoemd, maar de rolinvulling zal veel gelijkenis vertonen met die van de project- of programmamanager. Ondertussen word ik gesterkt in dit idee door het feit dat ik organisaties in Nederland toch weer project- en/of programmamanagers zie aantrekken. Hierbij moet ik wel de kanttekening maken dat de opnieuw aangetrokken of overgebleven project- en programmamanagers veel vaker op de relatie zitten (stakeholdermanagement) en dat ze om zaken voor elkaar te krijgen invloed moeten uitoefenen zonder macht te kunnen hanteren.

Dit boek kan dus ook gebruikt worden door meer traditionele projectmanagers die zich een beeld willen vormen wat business agility gaat betekenen voor hun eigen rol. Blijven er traditionele of hybride projecten bestaan (projecten waarbij gebruikgemaakt wordt van zowel tijdelijke als permanente ontwikkelteams en waarbinnen gebruikgemaakt wordt van zowel agile als meer traditionele aanpakken) waarbinnen zij een projectmanagerrol kunnen blijven vervullen? Of is het zinvol dat zij zich binnen de lijnorganisatie meer gaan ontwikkelen in de richting van portfoliomanager, Agile Leader, Integration Manager, Roadmap Manager of Roadmanager, Release Train Engineer, Scrum Master, Agile Coach of Product Owner?

Ik ga in op verschillende agile frameworks die het op organisatiebrede schaal agile gaan werken ondersteunen. Ik schets eerst een handvat om de verschillende agile aanpakken mee te positioneren en vervolgens ga ik in detail in op een aantal van de meest gebruikte frameworks en geef ik een korte introductie van enkele minder gebruikte en minder bekende frameworks.

Ten slotte vergelijk ik verschillende frameworks en sluit ik af met een aantal, soms aan een specifiek framework gerelateerde, aanpakken om een agile framework te implementeren. Verder krijgt u mogelijke valkuilen waar u bij het implementeren van een agile aanpak rekening mee moet houden en antipatronen waar u tegenaan kunt lopen bij het gebruik van een agile framework.

Bestellen (Managementboek): Scaling agile in organisaties

Bestellen (bol.com): Scaling Agile in organisaties

Agility by delivering changes as ‘business as usual’ (extensive version)

Organizational agility developments

Many frameworks use the model ‘run the business’ (permanent teams doing the work) versus ‘change the business’ (work will be done by temporary groups of people). Projects and programs are managed via ‘change the business’. We see project and programme managers bringing people together for a definite period of time to make this happen. But in many cases we are confronted with budget overruns, delays and unhappy customers because what is delivered is not what they really need. As a reaction on these unsuccessful projects a group of people created the agile manifesto, and based on that several agile delivery frameworks were designed to help to deliver more successful projects.

This agile manifesto is embraced by many organizations and these organizations started to keep the people together who delivered e.g. a new system. These teams are able to deliver changes much faster by using Scrum, Kanban etc. These small focussed agile teams are self-organizing and are continuously learning to deliver more with the same people and within the same time-boxes. Collaboration is the norm. What these teams are delivering is managed by a product owner. It is the product owner who prioritizes the work to be done by maintaining a backlog with potential features and user stories. For these teams we don’t need a project manager to bring people together and structure and control the work. The members are already together, are self-organizing and can be seen as part of the ‘run the business’ side of the organization.

So for those changes that can be managed by a single agile team there is no need for a project manager. But in many occasions you need more than one agile team to implement the requested change. We need to scale up from a single agile team to many agile teams. The Scrum guide (developed by Ken Schwaber and Jeff Sutherland) gives some directions to use the scrum of scrums to align the teams and to make integration into one solution possible. In practice this works well for just a few teams, but what do you need if you have to make use of several component and feature teams to deliver one integrated solution? Scrum of scrums is not enough, you need a project manager to manage all stakeholders, all dependencies, the complexity and to deliver one integrated solution. Several organizations are on this level. They still run projects and project managers will make use of these permanent agile delivery teams.

Probable you could ask yourself, why do I want to make use of a temporary project manager? Is it not possible to have a permanent, maybe virtual, structure to take care of stakeholder management, dependency management and integration and have as a result a more or less continuous flow or at least short delivery cycles of changes bringing into production without ramping up and down project governance structures and teams.

You now see that several frameworks to support this level are being developed and used by many different organizations. To mention a few: Nexus developed by Ken Schwaber, Scrum at Scale developed by Jeff Sutherland, SAFe developed by Dean Leffingwell, the Spotify model copied by several organizations, Less developed by Craig Larman and Bas Vodde and there are many more. If you have implemented one of these frameworks the need for a project or programme manager will decline but on the other hand they can take new roles like roadmap manager, integration manager, release train engineer, value stream engineer.

Does this mean we don’t need any more project or programme managers? I think for the coming years we definitely need project and programme managers. In those cases, where we need more than the already existing permanent teams we have to build these non-existing teams. And these teams can of course make use of agile ways of working or just choose the for them most appropriate delivery method. If there is a need for a piece of specialist work we must select the right people and bring them together to deliver. This is typically a task for a project or programme manager. If you want to transform your organization, open new product/market combinations, integrate departments, or merge different organizations I expect that most of the organizations will not have permanent teams in place to handle this.

To support this way of working we see frameworks on project level (PRINCE2 Agile, DSDM AgilePM and PMI APM) and at programme level (MSP and DSDM AgilePgM). The competences of these project and programme managers have to change. where in the traditional way of working the focus was on project results using a formal mandate we now see a shift to business results realized by using influence without power. Stakeholder management becomes even more important with a focus on empathy, negotiations and persuasiveness. Servant leadership becomes key.

Here too, I see developments to reduce this type of project management work. Where we first saw integration of development and operations people into DevOps teams we now see the first BusDevOps multi-skilled teams where product management, marketing, development and ops people are in the same team and as a consequence again less projects and project managers.

Scrum or Kanban?

During the first part of a product life cycle the uncertainty is high and the focus is on goal driven iterations for the first product launch and market fit product. During this part of the life cycle Scrum is a great fit to cope with uncertainty and product iterations developed by the whole team. During the rest of the product life cycle the amount of uncertainty and change gradually declines. Here Kanban is a good fit. User Stories will be realized in a continuous flow by one or more of the individual team members.

When a major product upgrade has to be delivered by the whole team Scrum could be a better choice for that goal oriented iteration, otherwise Kanban stays a good fit.

To avoid the error prone handover and to shorten the time to market the Development and Operations teams can be integrated. Kanban is a good fit for the DevOps team. When to start with DevOps varies.

Agile portfolio management

Does this have consequences for portfolio management too? At this moment I have not seen any mature agile portfolio frameworks. The first framework that includes the portfolio level is the SAFe framework and DSDM included an agile portfolio management paragraph in their little book The Agile PMO.

In one of my previous posts I already proposed a change in the MoP framework to include the ‘run the business’ permanent agile teams in the portfolio view. If we want to reach more business agility, I strongly believe that we have to decentralize decision making. If we don’t and still want to make decisions at a higher more central level Standish ‘Cheetah’s Law’ is applicable and the speed of decision making could obstruct delivery success.

So for me the following aspects need to be taken into account to design an agile portfolio management framework:

Agile Portfolio Management Framework:

• Strategy assessment
  • Internal and external environment assessment (SWAT)
  • Portfolio management must facilitate sustainable business change (People, Planet, Prosperity, Processes, and Products)
  • Strategic Objectives setting
  • Develop Strategic themes
• Direction setting
  • Portfolio vision, goals and objectives
  • Portfolio management facilitates innovation as part of the roadmap
  • Portfolio management must move away from the iron triangle and focus on delivering value, capacity and time-to-market
  • Close cooperation between enterprise architecture and portfolio management (addressing enabler epics (NFRs, technology drivers, innovations) to be part of the roadmap) to invest in (digital) technology to win, serve and retain customers
  • Portfolio management will have large impact on strategic decisions (achievability, technology trends)
• Selection
  • Funding at value streams or permanent agile teams level and not at project or programme level
  • Funding must be aligned with the strategy or strategic themes. Enlarge or lower the number of agile teams must take place to align with the strategic themes
  • A short simple business case justification must be used to put epics on a portfolio backlog
  • The portfolio backlog epics must be prioritized based on attractiveness, risk or opportunity costs, time criticality and the duration. The weighted shortest jobs first (WSJF) from SAFe is a good example. Standish ‘Law of the eatable elephant’ is in line with this.
  • Epics can be business related as well as non-functional
  • Epics must be head and heart-driven, not just head-driven
  • Keep epics as small as possible but it must contain more than one feature
  • Number of epics in the roadmap must be WIP limited
• Planning
  • Portfolio plans will be replaced by a portfolio backlog with epics and a rolling-wave portfolio roadmap (Roadmaps include six key elements: time frame, prioritized and identifiable outcomes, strategic themes, context-specific content, dependencies, investment outlay)
  • Starting point for a portfolio roadmap must be a portfolio vision
  • Rolling-wave portfolio roadmap must be a living document. Only the first part must be committed to make sure changes can be embraced
  • Portfolio roadmaps must have a cadence or heartbeat to increase throughput and integration moments/milestones to create learning loops
  • Portfolio roadmaps must show retrospective events
  • Portfolio roadmap achievability must be based on (group of) team(s) velocity and not on optimized resource utilization. 100% resource utilization will lead to a lot of busy persons but no delivery!
  • Portfolio roadmap must be approved by senior management and communicated to the organization
  • Must be a continuous integrated portfolio planning process with regular strategic reviews (included fact-based feedback loops) and pivot when needed
  • Portfolio roadmap development includes strategic option analysis / scenario planning
•  Delivery
  • Portfolio dashboards must show the funding of value streams (and permanent agile teams) and the alignment with and budget allocation across the strategic themes
  • Portfolio dashboards must show progress on epic level. Details of epic break downs in features and user stories are not for the portfolio level (respect the decentralized decision making)
  • Focus must be on delivering value / benefits and not on OTOBOS (On Time, On Budget, On Scope)
  • Possible portfolio dashboards Key performance indicators and metrics (not limitative): productivity (feature lead time), agility (predictability, number of releases), quality (satisfaction, #defects), metrics for self-improvement, time to market, NPS
  • Use timely, accurate, and relevant information based on real time (automated) performance data, avoid manual aggregation
  • Portfolio dashboards must show data-driven recommendations for decisions
  • Portfolio dashboard reporting at anytime
  • Dependency management on epic level (inter and intra dependencies)
  • Doing the right things (metrics on effectiveness), Doing it right (metrics on process efficiency). Compare over more than one period
  • Customer feedback to evaluate the effectiveness of the roadmap
  • Portfolio dashboard reporting creates transparency and will motivate stakeholders
  • Integrated tooling (EA and PPM) must give real time insights (rich information) about the health of initiatives, capacity and what-if scenario analysis corresponding with the requester’s role

Behaviour

• Senior management commitment (much more leadership, less management)
• Decentralized decision making
• End-to-end transparency
• Inspect regularly and adapt where needed
• Feedback is crucial
• Empowered employees
• Culture of collaboration (remove silo’s)

Looking forward to your comments and adjustments so we can co-create a new agile portfolio management framework.

• Updates:
  • 30-09: added Scrum or KanBan paragraph
  • 30-09: Agile Portfolio Management Framework additions
  • 02-10 Picture Agile PfM Framework

 

How to understand the forest of Agile methods, and frameworks? How can we see the wood for the trees?

At this moment I am aware of several different methods and frameworks with a link to Agile.

In the attached pictures you already see several of them, like Agile PM, Agile PgM, DevOps, Disciplined Agile 2.0, DevOps, Feature Driven Development (FDD), Kanban, PRINCE2 Agile, Large Scale Scrum (LeSS), SAFe 3.0 / 4.0, The Scrum Guide, The Nexus guide, Test Driven Development (TDD), eXtreme Programming (XP 2.0). In the picture I didn’t include Kanban, Lean Start-up, but you can find overviews on my blog.

I will give brief summaries of several methods / frameworks (in alphabetic order)

AgilePM

AgilePM is developed by DSDM. AgilePM consists of the following elements:

• Philosophy: best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people
• Principles: Focus on the business need, Deliver on time, Collaborate, Never compromise quality, Build incrementally from firm foundations, Communicate continuously and clearly, Demonstrate control
• Processes: Pre-project, Feasibility, Foundation, Evolutionary development, Deployment, post-project
• Roles & responsibilities: includes the steering roles Business Sponsor, Business Visionary, Technical Coordinator and Project Manager. The Solution Development Team is formed by the Team Manager, the Business Ambassador, the Business Analyst, Solution Developer and Tester.

See my blog: AgilePM (in Dutch) 

AgilePgM

AgilePgM is developed by DSDM. AgilePgM consists of four elements: philosophy, five principles, six processes and six themes.

• Philosophy: An agile programme delivers what is required when it is required – no more no less.
• Principles are related to business strategy alignment, incrementally realised benefits and as early as possible, decision-making at the lowest possible level, governance focuses on creating a coherent capability and agile programmes are iterative and contain both agile as non-agile projects.
• The six processes are Pre-Programme, Programme Feasibility, Programme Foundations, Capability Evolution, Tranche Review and Programme Close. The themes or knowledge areas are related to Roles, Governance, Stakeholder engagement, communication and management, Planning, Management and control and Quality Management.
• See my blog for more info: AgilePgM 

Disciplined Agile 2.0

Is an enterprise wide scalable process framework (people first, learning oriented hybrid agile approach to IT solution delivery).

• Enables agile delivery teams to succeed (work together with people outside the team).
• Provide a coherent strategy for agile IT (different BoKs at different points on the agile/lean learning curve).
• Supports the lean enterprise (IT is able to work in an agile/lean manner and the context counts (tailor).

Feature Driven Development (FDD)

FDD is a model-driven short-iteration process that consists of five basic activities: Develop overall model, Build feature list, Plan by feature, Design by feature, Build by feature.

core set of software engineering best practices:

• Domain Object Modeling
• Developing by Feature
• Individual Class (Code) Ownership
• Feature Teams
• Inspections
• Configuration Management
• Regular Builds
• Visibility of progress and results

Kanban

Kanban is a scheduling system for lean and just-in-time production. When there is no explicit limit to the work in progress (WIP, or the maximum number of cards at a specific process step) and there is no mechanism to show that we have to pull new work into the system, it is not a Kanban system.

Key properties of a Kanban system are:

• Visualize workflow using a Kanban board
• Limit work in progress;
• Measure and manage flow;
• Make progress policies explicit;
• Use models to recognize improvement opportunities.

See my blog: Kanban 

Large-Scale Scrum (LeSS)

Large-Scale Scrum is Scrum. There is only One Product Backlog, one Product Owner, one potentially shippable product increment, and one Sprint.

LeSS was developed (starting in 2005) to apply Scrum to very large and multisite product developments. Today, the two LeSS frameworks (basic LeSS and LeSS Huge) have been adopted in big product groups worldwide.

• Principles: empirical process control, transparency, more with less, whole-product focus, customer-centric, continuous improvement towards perfection, systems thinking, lean thinking, and queuing theory.

Lean Start-up

Is a method for developing businesses and products. Within the philosophy of embracing change, PRINCE2 Agile also introduces the principle of lean start-up. Lean start-up focuses on validated 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.

MVP: (not necessarily the smallest product imaginable): Concierge, Smoke test, Video, Split test, Early prototype.

See my blog: Lean Start-up 

PRINCE2 Agile

Includes both the existing PRINCE2 as the agile way of thinking. The agile

way of thinking must be seen as:

• agile behaviour: Collaboration, exploration, self-organization, transparency
• concepts: Prioritisation, working iteratively and incrementally, not delivering everything, time focussed, inspect and adapt, kaizen limiting WIP
• frameworks: scrum, Kanban, lean start-up
• focus areas: rich communication, requirements, contracts, agilometer
• techniques: Burn charts, user stories, retrospectives, timeboxing, measuring flow
• 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.

See my blog: PRINCE2 Agile webinar 

Scaled Agile Framework (SAFe 4.0)

SAFe 4.0 is a framework for using agile and lean practices at organization wide scale (Software delivery focus).

Four levels of scale:

• Portfolio: portfolio backlog, business and enabler epic-level decisions. To align value streams with the business strategy.
• Value stream: optional, intended for complex environments where multiple agile release trains exist.
• Programme: to deliver programme increments, coordination of a number of agile teams with there release trains based on a programme backlog.
• Team: foundational layer of SAFe, and powers the agile release train. Can make use of Scrum, XP, Kanban, etc.

Test Driven Development (TDD)

Test Driven Development is a development methodology and is created by Kent Beck. It follows the following steps:

1. Add a test
2. Run all tests and see if the new test fails
3. Write some code
4. Run tests
5. Refactor code
6. Repeat

The Nexus Guide

Nexus is developed by Ken Schwaber and is his answer on developments with more than one scrum team. It starts with one Product Owner managing the Product Backlog. The Product Owner sets up the Nexus Integration Team. In this team we see Integration Team members as well as a Scrum Master.

• The Nexus Integration Team together with representatives of the Scrum teams develop the Nexus Sprint Backlog (Nexus Sprint Planning.). Each Scrum Team will have its own expertise area and have its own Development Team members and a Scrum Master.
• Every day the Nexus Integration Team and representatives from the Scrum Teams will have their Nexus Daily Scrum to discuss integration issues, dependencies and sharing information across the teams. Joined to this Nexus Daily Scrum the individual Scrum Teams will have their own Daily Scrums. The Scrum Teams will develop their parts and integrate and test their work with that of the other teams.
• At the end of the sprint we have the Nexus Sprint Review demonstrating, showing the Integrated Increment. This is a joined review with all team and replaces the individual Scrum Team Reviews.
• An overall Nexus Sprint Retrospective focusses on inspection and adaption and consists of three parts: The first part is identification of issues impacting more than one Scrum Team. Part two are the individual Scrum Team Retrospectives and the last part focusses on actions to be taken.

See my blog: Nexus 

The Scrum Guide

Scrum is developed by Jeff Sutherland and Ken Schwaber.

Scrum is a process framework to develop and sustain complex (software) products. In itself it’s a light weighted and simple framework but difficult to master. The Scrum framework consists of:

• A team and their associated roles of Product Owner, Scrum Master and Development team members;
• Events: Sprint planning, Daily Scrum, Sprint Review and Sprint Retrospective;
• Artifacts: Product Backlog, Sprint Backlog, Increment.

See my blog : Scrum, the art of doing twice the work in half the time 

eXtreme Programming (XP 2.0)

XP is a software development methodology and is created by Kent Beck focussing on delivering quality.

• It contains several planning and feedback loops: code, pair programming, unit test, pair negotiation, stand up meeting, acceptance test, iteration test, release plan.
• Activities: coding, testing, listening, and designing
• Values: communication, simplicity, feedback, and courage, respect (2.0)
• Practices: Fine-scale feedback, Continuous process, Shared understanding, Programmer welfare, Coding, Testing.

Some related websites:

Naam	website
AgilePM	www.apmg-international.com
AgilePgM	www.apmg-international.com
Disciplined Agile 2.0 (DAD)	www.disciplinedagiledelivery.com
DSDM	www.dsdm.org
EXIN Agile Scrum	www.exin.com
PMI Agile Certified Practitioner	www.pmi.org
PRINCE2 Agile	www.axelos.com
Large Scale Scrum (LeSS)	www.less.works
Scaled Agile Framework (SAFe)	www.scaledagileframework.com
Scrum Alliance	www.scrumalliance.org
SCRUMstudy	www.scrumstudy.com
The Nexus Guide	www.scrum.org
The Scrum Guide	www.scrum.org

Please let me know if you are aware of other interesting agile methods/frameworks.

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.

BPUG session 6/1/2016: PRINCE2 Agile: Agilometer workshop results

Wednesday Jan 6th, I gave a presentation regarding PRINCE2 Agile for the BPUG. You can find the presentation on the BPUG site. I would say a lively session with lots of positive and enthusiastic reactions.

I started with a short visual movie created by Kirsten Casper from Hedeman Consulting.

In the second part of this session we focussed on the Agilometer. In the attached figure you see the three management levels and the Agilometer. The Agilometer will help to understand how far the agile thinking can rise up or how far the PRINCE2 thinking can cascade down. When a suitability slider, e.g. “Flexibility on what is delivered” is moved to the right (becomes completely yellow) we have a project where agile thinking is maximized. At the opposite side (slider to the left (completely blue) the PRINCE2 thinking is completely cascaded down.

The official manual only describes the full agile situation. In this situation the sliders are all moved to the right.

In 12 groups we discussed the definition and example behaviour of the missing situations. Due to time constraints we focussed on the left side, the traditional approach and the middle where parts from the traditional PRINCE2 as well as the agile world are equally combined.

‪I added all your comments in the 6 slides and with great help from Richard Metcalf (one of the attendees) these were translated in understandable sentences.

‪To download all six slides (sliders): PRINCE2 Agile (BPUG 160106 agilometer results) v1.3

Feel free to comment on the results till so far.

‪As a next step I will generate a final version using your feedback and other material such as the questionnaires from KWD Resultaatmanagement (Agile Geschikt/Ongeschikt) and the Project Approach Questionnaire from AgilePM.

Managen van agile projecten, 2de geheel herziene druk

De nieuwe geheel herziene druk van ons boek is beschikbaar!

De kern

Het boek Managen van agile projecten 2de geheel herziene druk is gebaseerd op Agile Projectmanagement Handbook Version 2 van DSDM en vervangt daarmee de 1ste druk die gebaseerd was op DSDM/Atern versie 2 en het Agile Project Management Handbook Version 1.2 van APMG.

Dit boek is geschreven voor de Projectmanager die leidinggeeft of gaat geven aan agile projecten. Het is echter geen rechtstreekse vertaling van het DSDM handboek. Op onderdelen geeft het boek een eigen visie op het managen van agile projecten. Verder is getracht de methode meer toegankelijk te maken voor de lezer.

Het boek is onderverdeeld in een viertal delen.

• In deel I. Methodiek worden de uitgangspunten, het raamwerk, de filosofie, de principes en de succesfactoren van AgilePM beschreven. Verder worden in dit deel de AgilePM-rollen, -processen en -producten beschreven.
• In deel II. Projectmanagement wordt nader ingegaan op de consequenties van de AgilePM-aanpak voor de verschillende aspecten van projectmanagement.
• In deel III. Technieken worden de afzonderlijke technieken beschreven die in agile projecten worden toegepast om ervoor te zorgen dat de filosofie en uitgangspunten van AgilePM in projecten ook daadwerkelijk worden ingevuld.
• In deel IV. Afstemming wordt ingegaan op de vraag hoe de verschillende methoden zich tot elkaar verhouden. AgilePM en PRINCE2 worden met elkaar vergeleken. Scrum, Lean Six Sigma, continue oplevering, DevOps-teams, Kanban en PRINCE2 Agile worden nader toegelicht. Verder wordt aangegeven hoe de verschillende methoden zijn te combineren en hoe een compleet portfolio van projecten met verschillende methoden het best kan worden gemanaged.

Dit boek is een geschikte basis om zich voor te bereiden op het examen AgilePM Foundation en Practitioner.

Samenvatting

De AgilePM-methode voor het managen van agile projecten bestaat uit een raamwerk, omvattende een filosofie, daarvan afgeleide principes en een viertal bouwstenen.

De AgilePM-filosofie is dat ieder project moet worden afgestemd op duidelijk gedefinieerde bedrijfsdoelen en moet focussen op een vroege oplevering van producten die echt toegevoegde waarde leveren aan de bedrijfsorganisatie.

AgilePM kent een achttal principes. Agile in meer algemene zin kent meer principes die hier bovendien iets van afwijken. De agile principes zijn met name gericht op het zelf-organiserende team. De AgilePM-principes zijn meer gericht op het project als geheel.

De vier AgilePM-bouwstenen zijn:

• Mensen > de rollen en verantwoordelijkheden
• Processen > de afzonderlijke stappen in de projectlevenscyclus
• Producten > de noodzakelijk op te leveren producten
• Toepassingen > de te gebruiken tools en technieken

Belangrijke technieken zijn met name timeboxen, planning poker, gefaciliteerde workshop en prioritering van functies op basis van het MoSCoW-principe.

Het AgilePM-procesmodel onderscheidt zes processen ofwel zes fasen (zie figuur 1):

In de Pre-projectfase wordt besloten het project uit te voeren. In de Haalbaarheidsfase wordt nagegaan of het project vanuit zowel zakelijk als technisch oogpunt realiseerbaar en wenselijk is. In de Fundatiefase wordt, zoals de naam zegt, de fundering gelegd voor de uitvoering van het project.

Na de Fundatie start de uitvoering van het project. Dat gebeurt in vooraf gedefinieerde increments. Per increment wordt een werkend deel van het eindresultaat opgeleverd. Ieder increment bevat in principe de fasen Ontwikkeling en Ingebruikname.

Na de Implementatie wordt een nieuw increment opgestart of het project afgesloten mocht aan de eisen zijn voldaan. In de Post-projectfase wordt nagegaan of de geprognotiseerde baten ook daadwerkelijk zijn of worden gerealiseerd.

AgilePM maakt onderscheidt tussen de projectbesturing, het Ontwikkelteam en overige rollen (zie figuur 2). De projectbesturing wordt gevormd door de Bedrijfssponsor zijnde de opdrachtgever, de Bedrijfsvisionair zijnde de vertegenwoordiger van de gebruiker op managementniveau, de Technisch Coördinator zijnde de vertegenwoordiger van degene die het resultaat moeten opleveren en de Projectmanager, verantwoordelijk voor de coördinatie en communicatie.

Het Ontwikkelteam wordt gevormd door de Teammanager, de Bedrijfsambassadeur, de Bedrijfsanalist, de Ontwikkelaar en de Tester. Essentieel binnen AgilePM is dat er sprake is van een zelf organiserend team. De Teammanager moet ervoor zorgen dat het Ontwikkelteam ook echt als team functioneert. De Teammanager is in deze echter meer faciliterend en begeleidend dan manager. De Bedrijfsanalist vertaalt de bedrijfseisen naar technische oplossingen De Bedrijfsambassadeur is verantwoordelijk voor het detailleren en prioriteren van de gebruikerseisen en voor het (laten) testen van de gerealiseerde producten vanuit gebruikersperspectief.

De overige rollen binnen de AgilePM-structuur zijn de Bedrijfsadviseur, de Technisch Adviseur, de Workshop Moderator en de agile coach. De Bedrijfsadviseur is vaak een collega van de Bedrijfsambassadeur en levert specialistische input. Datzelfde geldt voor de Technisch Adviseur maar dan alleen vanuit het leveranciersperspectief.

Figuur 2: AgilePM-organisatiemodel

AgilePM maakt gebruik van bedrijfs-, management- en specialistenproducten. Afhankelijk van het project en de omgeving kunnen producten worden samengevoegd. Net als bij PRINCE2 moet het project op maat worden gemaakt en kunnen producten worden samengevoegd

Doelgroep

Dit is een interessant boek voor iedereen die benieuwd is naar het managen van agile projecten en meer wilt weten dan alleen scrum. Het is enerzijds geschreven voor personen die zich willen voorbereiden op het AgilePM Foundation en Practitioner examen en anderzijds voor mensen die naast AgilePM zelf ook de relatie van AgilePM met andere agile methoden en raamwerken willen begrijpen.

Bestellen: Managen van agile projecten.

 

PRINCE2 Agile

Tijdens de laatste Gartner PPM Summit, 8 en 9 juni 2015 in Londen werd het nog eens bevestigd. ‘One size doesn’t fit all’, geldt ook in de wereld van projecten. Zijn betrouwbaarheid en kosten het belangrijk- ste of gaan we voor merkbekendheid, omzet en klantenbeleving? Hebben we te maken met langdurige of kortlopende contracten? Is de focus IT of juist organisatiebreed? Hebben we het over veelvuldige of een beperkt aantal opleveringen binnen korte of langere doorlooptijden? Vele debatten zien we in de media, Agile versus PRINCE2, alles Scrum, maar hoe zit het met de governance? Het antwoord van Axelos is PRINCE2 Agile waarin het beste vanuit beide werelden wordt ingezet om een project goed uit te kunnen voeren. Download: PRINCE2 Agile artikel Pro_2015-04

Zie ook mijn (Engelstalige) posts over PRINCE2 Agile waarin facetten uit PRINCE2 Agile worden beschreven zoals Lean Startup, Kanban etc.

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.

PRINCE2 awareness email course

I received a request from Nader Rad (Management Plaza) to have a look at his micro-courses regarding PRINCE2, and PRINCE2 Agile.

It’s a great concept if you want to get a flavour of these best practices.

PRINCE2 Awareness email course:

After subscribing you get during 6 weeks, every day an email. In this personalized email a single topic will be discussed. Every mail ends with a sort of ‘cliff-hanger’ or question regarding the next mail to come. In every email you will find a progress indicator too. It will cost you a few minutes to read so if you are not familiar with PRINCE2 you don’t have an excuse anymore. Subscribe, spend a few minutes per day and after 6 weeks you have a basis understanding of PRINCE2.

As I stated, it’s just to get a flavour, it’s not a full eLearning course. You will follow step by step the introduction, the seven principles, the seven themes and the seven processes.

Some suggestions:

• Give subscribers the possibility to immediately request for the next episode. If they do not ask, they will receive the next episode the next day
• Replace the video regarding processes with mails in line with the rest
• Add figures, tables etc.

If you are interested see: http://mplaza.pm/free-prince2-course/ where you can subscribe (for free).