Agile NXT Future Friday retrospect

Schermafdruk 2019-04-08 15.16.29Friday May 10, 2019, I was one of the 40 participants of the first Agile NXT Future Day conference organized by Xebia.

It was perfectly organized, really interesting and next level topics, great food, and enough time to network. The conference offered seven thought leaders to sharpen our mind and to help to improve your own organization’s performance. The group was split in two to facilitate discussion and active participation. Four sessions of 1,5 hour that made it possible to get some theoretical background and workshop set-ups to learn by doing.

The first session – Why the Agile “Fixed-Team” Dogma is Wrong (Laïla Nouijeh & Laurens Bonnema) was somewhat controversial. Fixed teams are the ideal world and now they say this is wrong. Luckily, it’s not that black and white but the reality is that people are entering and leaving the teams on unexpected moments, sometimes due to management decisions, sometimes as a result of a team mismatch, sometimes on a person’s own initiative and in most cases it will have a negative impact on the team’s performance. If you take this for granted and accept that reteaming is inevitable, make sure you get good at it. To become good in reteaming you can look e.g. at techniques like pair programming or MOB programming to speed up the process of integrating new members or create a checklist to facilitate on-boarding and make sure the questions are definitely a lot of fun to answer. To build, reshuffle or reteam teams you can also make use of self-selection. This will speed up the process of teaming too and ultimately you will have more engaged teams. In the last part we had a workshop to discover how to implement dynamic reteaming experiments in your organization.72

An interesting book to read is Dynamic Reteaming: The Art and Wisdom of Changing Teams by Heidi Helfand.

The second session – Stop Copy-Paste Agility, Start Agile Problem Solving (Daniel Burm) focused on the question: Is your agile “copy-paste” or “problem-solving-specific? If you only imitate, you’ll never innovate. Daniel started the session with a video from David Kelley, founder of IDEO. How they countermeasure solution thinking (what is deep dive) about designing a shopping cart.

Based on this video the question was asked if this design thinking process could be used for organization changes too? In a workshop setup all attendees got the chance to practice some techniques which were explained upfront. E.g. the Design thinking process for change based on a holistic approach: Empathize (scoping, 360 research and synthesize), Ideate (impact mapping: goal – actor – impact – deliverable), Experiment (run controlled experiments, experiment canvas). We practiced the change urgency interview resulting in a first problem statement, we reframed problems into challenges, and we created an experiment setup including an underlying hypothesis. All attendees received a workbook including the used templates and tools and the advice to learn what it takes to solve your own companies’ problems, your way—the agile way.impact mapping

An interesting book to read is Impact Mapping by Gojko Adzic.

In the third session Structure Your Organization For Tomorrow (Roel Trienekens & Just Meddens) we learned how to confront the real challenges of current work-impacting trends. Gain practical knowledge for your organization’s future-fit toolkit. Referring to David Marquet’s book Turn the ship around and showing the Pirates of the Caribbean – At World’s End – Up Is Down Scene.

Using three-dot voting all attendees selected a few themes out of ten. We started to discuss pros and cons of radical transparency. What if you have access to …

  • everyone’s planning?
  • everyone’s experience?
  • everyone’s to do list?
  • everyone’s goals and targets?
  • the complete company finances?
  • everyone’s performance reviews?
  • everyone’s salary and benefits?
  • everyone’s e-mail communication?

There are organizations, e.g. Buffer or Semco, where this works, so why would it not work at your place, but you need for sure a mindset shift to accept this way of transparency.

The second topic we discussed was about a new way of decision making. How are decisions being taken? Do you know how much a reasonable decision costs in your organization? You can use an autocratic decision-making process, a democratic process (“The process of voting creates losers” – Rick Falkvinge), consensus and using the process of consent (holacracy, sociocracy). We experiment with consent decision making starting with the statement is this good enough for now & safe enough to try in stead of ‘is everyone in favor?

swarmwiseAn interesting book to read is Swarmwise by Rick Falkvinge.

height_90_width_90_DeToekomstVanOrganisatiesInteresting Podcasts: http://detoekomstvanorganisaties.nl

The fourth session When Agile Meets Culture … And Clashes (Ellen Barree) helps you to open your eyes to the “invisible elements” that often undermine transformations. If you want to change the culture you need alignment between the three layers: rituals and artifacts, exposed values and behavior and underlaying assumptions. What can we learn from how David Attenborough observes? Take e.g. how David explains The Software Developer.

We experiment how to make culture change more tangible and sustainable by using the corporate culture map (A3 placemat). Starting with the desired cultural change: What do you want to see and hear? What do you believe in and how do we act? What are they not telling you and truly feel, think, percept? Folowed by describing the current culture: what do you see and hear? What do we believe in and how do we act? What are they not telling you and truly feel, think, percept? And as a final step creating the movement from current to desired with care.

9789462760363-480x600Interesting books to read:9789462761759-480x600 De Corporate Tribe – Organisatielessen uit de antropologie by Danielle Braun, Jitske Kramer.

Building Tribes – Reisgids voor organisaties by Jitske Kramer, Danielle Braun

The conference ended with the keynote from Margriet Sitskoorn How Agile is Our Human Brain? Take a trip through the plasticity of your mind and gain insight into how you can express your talents and best accomplish your goals in the age of agility. Magriet explained what it means to live in a VUCA (Volatile, Uncertain, Complex, Ambiguous) world. How can you develop your executive skills to be successful in a VUCA world? These executive skills are related to your pre-frontal lobe and help you to change from puppet to master. We experienced working memory, inhibition and inhibition and flexibility. To develop your pre-frontal lobe, you have to do something new. For this purpose, she developed the EFFECT program (Enriched environment, Flow-focus training, Fixed sleep pattern, Exercise, Connect today with tomorrow, and Time).

Some interesting book to read:

 

When we left, we received a goody bag with a pair of Xebia happy socks and the book Agile NXT insights and foresights for your next step in agile.

The next Agile NXT Future Friday will be held Friday September 13, 2019. If it will have the same quality of this first one, it’s definitely a conference I would like to attend.

Advertisements

Recensie: Scrum in actie – Maak van elk project een succes

9789047008378-480x600Scrum in actie – Maak van elk project een succes is geschreven door een team van schrijvers namelijk Petra de Boer, Martin Bruggink, Maarten Bruns, Nienke van de Hoef, Gideon Peters, Mariëlle Roozemond en Willy Wijnands.

Dit boek over Scrum is alweer 4 jaar oud maar biedt zowel een prima introductie op Scrum, als vele voorbeelden van het toepassen van Scrum buiten IT. En van dat laatste zijn er niet zoveel boeken.

In elf hoofdstukken passeren de theorie van Scrum en verschillende aspecten tijdens het toepassen de revue zoals het loslaten van een langetermijnplanning, het tussentijds opleveren, het afmaken van dingen, het vormen van een team, het zichtbaar maken van het werk, het leegmaken van je agenda, het betrekken van de omgeving, het groeien als team, het werken met plezier en energie en afsluitend een hoofdstuk over het zelf starten met Scrum.

Het boek is doorspekt met cases waarin een aspect van scrum uitgelicht wordt. Cases die zich afspelen bij een scala aan verschillende bedrijven zoals HKU, Rabobank Nederland, TU Delft, Gemeenten Tilburg, De ronde Venen en Uithoorn, TVN Zorgt, Grontmij, Hotel con Corazón, Questionmark, ING België, Nederlands jeugdinstituut, NOS, Pink Elephant, Nationaal Archief, Ashram College, Volkstuin Blijdorp en Sanoma.

Conclusie: een prima introductie op Scrum voor de niet-IT’er. Het boek is fris opgemaakt, leest vlot weg en bevat zoals gezegd heel veel praktijkvoorbeelden. Ieder hoofdstuk wordt verder afgesloten met een bondige puntsgewijze samenvatting.

Bestellen: Scrum in actie – Maak van elk project een succes

 

Review: An executive’s guide to disciplined agile

DAThe book An executive’s guide to disciplined agile – Winning the race to business agility written by Scott W. Ambler and Mark Lines give a good overview of Disciplined Agile.

Disciplined Agile (DA) provides light-weight guidance to help organizations streamline their Information Technology (IT) and business processes in a context-sensitive manner. DA provides the process foundation for business agility.

There are seven principles to highlight the discipled agile mindset: delight customers, be awesome, pragmatism, context counts, choice is good, optimize flow and enterprise awareness. To stress the ability of being disciplined there are additional principles: master your craft, technical excellence, collaborate, measure wisely, transparency, lean continuously, purposeful experiments, deliver continuously, visualize workflow, whole team, stable team and trust and respect.

DA (QRC, 190407) v1.0DA consists of four parts (and are covered in chapters 3-6, the main part of the book):

  • Disciplined Agile Delivery (DAD). DAD addresses all aspects of solution delivery
  • Disciplined DevOps. This is the streamlining of IT solution development and IT operations
  • Disciplined Agile IT (DAIT). DAIT addresses how to apply agile and lean strategies to all aspects of IT
  • Disciplined Agile Enterprise (DAE). DAE is able to anticipate and respond swiftly to changes in the marketplace.

Within DAD we see the following roles:

  • Primary roles: Stakeholder and Team roles (Team lead, Product Owner, Team Member and Architecture Owner)
  • Secondary roles: Specialist, Independent Tester, Domain Expert, Technical Expert and Integrator.

The non-prescriptive DAD lifecycle consists of three phases inception, construction and transition. There are several versions of this lifecycle:

  • Agile/Basis lifecycle based on scrum. This lifecycle starts with the inception phase where modelling, planning and organization takes place and the initial backlog and release plan will be created. The other phases are similar with the Agile continuous delivery lifecycle (see below)
  • Lean/advanced lifecycle based on Kanban. This lifecycle starts with the inception phase where modelling, planning and organization takes place and the initial backlog will be created. The other phases are similar with the Lean continuous delivery lifecycle (see below)
  • Agile continuous delivery lifecycle: a single permanent agile team using Scrum giving a continuous stream of development (construction phase), released at the end of each iteration (short transition phase) and no need for an inception phase
  • Lean continuous delivery lifecycle: a single permanent agile team using Kanban giving a continuous stream of development (construction phase), and short transition phases and no need for an inception phase
  • Exploratory lifecycle based on Lean Start-up. This lifecycle starts with Envision, followed by Build a little, Deploy, Observe and Measure and Cancel or Productize the idea. I would say this is not a complete delivery lifecycle. To productize you have to use one of the other lifecycles
  • When you need more teams to build the service or product you need to coordinate the effort of the different teams to ensure they work together effectively towards the common goal. This is called in DA program management for large agile teams with the corresponding leadership team roles like a Program Manager/Coordinator, Product Delivery, Product Ownership and Architecture Ownership. The book doesn’t describe that much but, on the website, you can find much more information about program management.

The non-prescriptive set-up is emphasised by goal diagrams. Mindmaps to summarize the goals of a specific activity, e.g. addressing changing stakeholder needs, explore the initial scope or continuous improvement to mention a few.

Real life examples are missing in this book but can be found in their book Introduction to disciplined agile delivery

Disciplined DevOps explains what it means to bridge the gap between the agile teams and IT operations. In the book the workflow between Solution Delivery and IT Operations and other departments like Business Operations (BizDevOps), Security (DevSecOps), Data Management (DevDataOps) and Release Management and IT Support are explained. Reasons to adopt a Disciplined DevOps approach are faster time to market, improved market competitiveness, improved customer service, increased dependability, increased staff retention, improved governance and lower cost.

Disciplined Agile IT addresses how to apply agile and lean strategies to all aspects of IT. The workflow of Disciplined Agile IT is explained with a focus Disciplined DevOps, IT Operations, Release Management, Support, Security, Data Management and IT Governance, Reuse Engineering, Enterprise Architecture, People Management, Product Management, Continuous Improvement and Portfolio Management. On several place you get goal diagrams.

Portfolio Management addresses the following issues: spend IT investment wisely, balance exploring new business with exploiting existing value streams, monitor and guide ongoing activities, rolling-wave budgeting and planning, prefer small initiatives over large initiatives, cull “failures” quickly, invest in quality and enable team effectiveness.

To become a Disciplined Agile Enterprise, you have to embrace the following fundamental ideas:

  • Your organization and your people must be agile
  • It’s all about value streams
  • There is no one right answer
  • You need to sense and respond
  • You must be a learning organization
  • Self-organizing teams need fast access to resources.

In the workflow for Disciplined Agile Enterprise we see besides the ones mentioned in the Disciplined Agile IT workflow, Marketing, Sales, Control, Finance, Procurement and Legal. The authors explain the Disciplined Agile approaches in the different functions.

Next the authors give some insights what it means if you want to transform your organisation from a traditional structure and culture to one exhibiting true business agility. This will be very hard and will take a long time. Focus will vary over time in the following areas: executive education, executive coaching, middle-management coaching, agile training, agile/lean pilot teams, delivery team coaching, IT coaching, business coaching, skils training, agile centre of excellence, communication, experiments and communities of practice. The chapter ends with an example of a transformation and adoption roadmap anf how to measure your way to success. A separate chapter focusses on the final step in the transition, your organization has to become a learning organization (continuous improvement) and this will never end.

Conclusion: If you are not familiar with disciplined Agile and you want to get a clear overview of this framework, this book is a very good start. Looking at the different delivery cycles, there must be ones that have the right fit for your projects. If you want to implement disciplined Agile you probable need more information (as explained in the book too), and training and coaching too.

To order: An executive’s guide to disciplined agile – Winning the race to business agility

Positionering of Disciplined Agile in my birds eye view on the agile frameworks forest:Agile (50 shades of gray NTTP, 190415) v0.1

 

 

 

AgilePM documentation based on building blocks

If you look at the AgilePM (The DSDM Agile Project Framework) documentation set-up you could ask yourself if it’s not too much for an agile way of working?

In AgilePM the following documents are described:

  • Terms of Reference
  • Business Case
  • Prioritised Requirements List
  • Solution Architecture Definition
  • Development Approach Definition
  • Delivery Plan
  • Management Approach Definition
  • Feasibility Assessment
  • Foundation Summary
  • Evolving Solution
  • Timebox Plan
  • Timebox Review Record
  • Project Review Report
  • Benefits Assessment

If I look at templates used by organisations you are running the risk of large documents.

How many board members have ever read these bulky documents? How many board members have searched through these documents for the project scope and for their tasks and responsibilities in the project? Documents based on these templates are:

  • standalone;
  • descriptive and not concise;
  • multi interpretable;
  • labour-intensive to complete;
  • bothersome to read;

This begs the following question:

“Is it possible to provide stakeholders with adequate information without falling into the trap of bulky, inaccessible, standalone, and illegible documents?”

If the answer to this question is positive, then it should also be possible to enhance the quality of projects. After all, the stakeholders gain a better insight, which brings about more effective and efficient decision making by the Project Board. The project manager can be more focused upon managing the project instead of writing bulky (progress) reports. In the search for an answer to this question I used storyboarding, telling a story with PowerPoint slides with pictures and tables,and the concept of building blocks[1]. 

Building block concept

AgilePM documents consist in part of identical information blocks. Each block can be seen as a building block of an AgilePM document. A building block is therefore an independent subdivision of a document. Take for example the Terms of Reference with among other parts the business drivers and objectives to the project. If you make a building block for the Terms of Reference, it is information to be used as the trigger for the project, the Feasibility assessment, the Foundation summary and the Project Review Report. The use of building blocks reduces the chance of miscommunication and the loss of information, causing de-motivation of the parties concerned.

The combination of the building blocks and the philosophy behind the storyboard (each picture is a building block) leads to the following requirements for the AgilePM documents:

  • standardization (ensure that comparable documents for projects are built up in the same way);
  • essence (no extensive passages of text, but only the necessary);
  • visualization (make use of pictures, blocks, etc.: one picture says more than a thousand words).

The result of this procedure is that the stakeholders, e.g. Business Sponsor and Business Visionary receives the information in a recognizable and concisely represented manner. With the pressures of work, the time to read and understand documents is limited. Standardization, visualization and essence increase the possibility of reading everything, interpreting, understanding and reviewing. The Business Sponsor and Business Visionary can use their time effectively and efficiently.

Comparable arguments apply to the position of the project manager. The project manager wishes to represent the information concisely, without repeating anything and writing things up only once. The project manager has need of a handle that enforces consistency, promotes clarity and upgrades quality. The growth of a document on the basis of selected building blocks motivates and is efficient and effective.

Structure of AgilePM documents

In the development of the documentation standard I have integrated the following AgilePM documents (see Figure 1 for a simple view of the different documents and corresponding building blocks):

  • Terms of Reference
  • Feasibility assessment
  • Foundation summary
  • Progress reporting
  • Project review report
  • Benefits assessment

The Feasibility report consists of the updated Terms of Reference building block. The building blocks for the business case, the Business impact assessment and the prioritized requirements list complete the Feasibility report. In case multiple solutions are possible the two building blocks Business case and Business impact assessment can be repeated for each proposed solution. For approval and history, a document history building block is created too.

The building blocks of the Feasibility assessment, after being updated and the selected solution, forms the basis of the Foundation summary. The Foundation summary is created through the expansion of the Feasibility assessment by means of the following building blocks: Business implementation strategy, System architecture and Non-functional requirements complete the Solution Architecture Definition (System architecture and non-functional requirements only if part of the solution are IT related), Project approach, Project organisation, Project control, Delivery plan, Risk management and the Project Approach Questionnaire (all part of the Management Approach Definition). For large projects an additional Delivery plan building block is developed to show the high-level picture. For assurance purpose a Governance check building block is added.Project name (AgilePM building blocks 2019xxxx) v1.0Figure 1, AgilePM document building blocks

After the Project Board has approved the Foundation summary, the project manager will report on the progress periodically. The basis of this reporting are the Terms of Reference and the Delivery plan. The project manager, in principle, takes the Terms of Reference building block over unchanged. A change in the Terms of Reference gives cause for the Project Board to review the Business Case once again. A specific Delivery summary building block that can act as a Timebox Review Record can complete the reporting. A standard progress report with e.g. a burn-down and burn-up chart and project control indicators can help with the total picture.

The Project review report is based on the following existing, but updated, building blocks: Terms of Reference, Business Case and Delivery summary. On top of this we see the following additional building blocks Benefits enablement, Recapitulation and Lessons learned. The Benefits enablement building block can be used post-project for the Benefits assessment.

Templates

With graphic templates you are able to comply with the requirements of standardization, visualization and essence. The template describes the elements of a building block. This is practical for the project manager. There is little need for words. Visualization with graphics, drawings and tables is very convenient. The document can be identified by its format and use of colour. It is accessible and easy to understand. On the basis of available building blocks it enables the project manager to create quick reports and presentations.

Usage

For some time now, the application of the proposed procedure has been utilised by a financial service provider (for all their projects). This organisation has developed around 20 building blocks. Each building block has its own form (template). If a building block is not relevant to a particular project, it will not be included. Project Board members endorse the omission of irrelevant building blocks. They emphasise that standardised reporting saves time. They are able to determine the status of a project quickly. The decision points provide insight.

At the time of writing this article, I have given presentations to government authorities, an energy company, a retailer, consultancy companies and project management departments in order to bring the philosophy behind the standard into the limelight. Different organisations are currently implementing storyboards and building blocks.

It seems possible to systematically provide all concerned with adequate information without falling into the trap of bulky, inaccessible, standalone, and illegible documents. I have introduced the technique of storyboarding as a tool for reporting presentations. This promotes legibility and representation of the essence. I recommend the use of visual representations if it is possible. Storyboarding is a powerful tool to determine consistencies and omissions. I have used the overlap between AgilePM documents for the building block approach. Combining this with storyboarding ensures that executives and project managers use their time more effectively and efficiently.

[1]In my book PRINCE2 in practice, I used the same set-up

Building block explanation video

In this short video (14 minutes) I explain in more detail how this building block approach to create AgilePM documents, works.

Get the building block templates

If you are interested to receive a complete set of AgilePM building blocks (in PowerPoint) please send me a mail henny.portman@planet.nl and we can discuss the terms.

To download this article: AgilePM documentation based on building blocks

AGILE NXT FUTURE FRIDAY 2019

Schermafdruk 2019-04-08 15.16.29I give a lot of workshops and presentations and in many cases, attendees ask for the ‘silver bullet’ to become agile. It is far too short-sighted to think that you have to implement one agile framework and you achieve agility. First it is not about frameworks (despite my search which already resulted in 50 different agile frameworks. See my blog: A birds eye view on the agile frameworks forest). Also copying a successful way of working will not do (how many organizations copied Spotify’s tribes and squads’ organization model, bypassing Spotify’s own remark “if you want to use Spotify’s way of working, you have to become a Spotify”)? Achieving agility is all about the mindset of you as an individual or your organization and it’s the culture clash between the agile and traditional mindset that makes agile transitions difficult (reminder the picture I often use showing two rhinos looking at each other, as a metaphor for this clash). I have seen organisations firing project and program managers because they choose for the agile way of working and created a lot of agile teams because their competitor did the same and are now regretting that move. They have to hire much more expensive external program managers who lack the added value of the needed informal networks in the organisation to make transformational changes happen. Having only agile teams is not enough.

I got across the AGILE NXT FUTURE FRIDAY 2019 conference organized by Xebia. Last year I read the magazine AGILE NXT – Insights and foresights for your next step in agile so I was triggered, and the program looks awesome.

If I look at the program, I hope to get some answers or at least directions to my own thoughts. The conference offers seven thought leaders to sharpen my and your own mind and will help to improve your own organization’s performance.

  • How Agile is Our Human Brain? (Keynote, Margriet Sitskoorn): Take a trip through the plasticity of your mind and gain insight into how you can express your talents and best accomplish your goals in the age of agility.
  • Stop Copy-Past Agility, Start Agile Problem Solving (Daniel Burm): Is your agile “copy-paste” or “problem-solving-specific? If you only imitate, you’ll never innovate. Learn what it takes to solve your own companies’ problems, your way—the agile way.
  • Structure Your Organization For Tomorrow (Roel Trienekens & Just Meddens):Learn how to confront the real challenges of current work-impacting trends. Gain practical knowledge for your organization’s future-fit toolkit.
  • When Agile Meets Culture … And Clashes (Ellen Barree): Open your eyes to the “invisible elements” that often undermine transformations. Learn how to make culture change more tangible and sustainable.
  • Why the Agile “Fixed-Team” Dogma is Wrong (Laïla Noujeh & Laurens Bonnema): Solve poor performance with a shift in perspective on the fixed-team dogma. Discover how to implement dynamic reteaming experiments in your organization.

I will definitely attend AGILE NXT FUTURE FRIDAY 2019 and I look forward to the insights the speakers will offer. Afterwards I will write a blog with the highlights of this conference. Interested too, get your ticket at: https://www.agilenxt.com/

Review Praxis Framework – De handleiding voor Foundation

Praxis CoverWim Leenders en Wijand Lens hebben het boek Praxis Framework – De handleiding voor Foundation geschreven en mij toegestuurd. Ik was heel benieuwd omdat de website een grote wiki met hyperlinks en een grote navigatiebalk is.  Ik heb het lastig gevonden om op basis van de website een helder en compact beeld te krijgen wat Praxis nu precies inhoudt. Gaat deze handleiding mij daarmee helpen?

Praxis is een vrij beschikbaar framework waarin verschillende methoden zoals bijvoorbeeld PRINCE2, MSP, MoP maar ook de PMBoK en de ICB (IPMA) en P3M3 en OPM3 bij elkaar gebracht zijn en voorzien zijn van gelijke terminologie en insteek. De makers van de genoemde frameworks hebben hier echter niet in geparticipeerd.

Het Praxis framework bestaat uit vijf samenhangende onderdelen (secties)

  • Kennis (context en managementfuncties)
  • Methode (project- en programma- en portfolioprocessen en documentatie)
  • Competentie (management en proces)
  • Volwassenheid (vaardigheid en volwassenheid)
  • Bibliotheek (encyclopedie).

In totaal negen aandachtsvelden (verwarrend dat de omschrijvingen management en volwassenheid twee keer voorkomen).

Het boek is onderverdeeld in 6 delen:

  • Deel 1: Kennissectie onderdeel context
  • Deel 2: Kennissectie onderdeel integratiemanagement
  • Deel 3: Kennissectie onderdeel opleveringsfuncties
  • Deel 4A: Methodesectie onderdeel proces voor projecten en programma
  • Deel 4B: Methodesectie onderdeel proces voor portfolio
  • Deel 5: Kennissectie onderdeel persoonlijke vaardigheden
  • Deel 6: competentie & volwassenheid sectie

Deze zes delen beschrijven samen met bijlage A documenten en bijlage B rollen de negen aandachtsvelden waarbij sommige aandachtsvelden weer verder uit elkaar zijn getrokken en in verschillende delen zijn weergegeven. Aan de Praxis bibliotheek of encyclopedie wordt verder geen aandacht besteed, behalve de opmerking dat het de andere vier secties aanvult met extra details en denkprovocerend debat(?).

In het eerste deel wordt de organisatieomgeving geschetst waarbinnen projecten, programma’s en portfolio’s zich bevinden. De besturing komt aan bod en vervolgens verschillende uitingen van programma en project levenscycli (seriematig, parallel, iteratief) en de portfolio-levenscyclus. Er wordt verder kort ingegaan op de rol van sponsor en ondersteuning. Het deel wordt afgesloten met een hoofdstuk over professionalisme waarin onder andere aspecten zoals vakgroepen en ethiek aan bod komen.

Deel 2 gaat over integratiemanagement waarbij de integratiefuncties plannen, business case, beheersing, informatie, organisatie, stakeholders en borging worden afgezet tegen de onderdelen van oplevering zoals scope, planning, financiën, risico, verandering en resource (de integratiematrix). De verschillende integratiefuncties worden verder uitgewerkt waaronder de verschillende organisatiestructuren voor project, programma en portfoliomanagement. Op het niveau van de stuurgroep wordt de sponsor gepositioneerd. Een nadere uitwerking van een stuurgroep ontbreekt. Bij het plannen komen de bekende zeven vragen aan de orde: waarom, wat, hoe, wie, wanneer, waar en hoeveel?

Deel 3 beschrijft de zes onderdelen van oplevering. Binnen scopemanagement komen vervolgens requirementsmanagement, oplossingsontwikkeling, batenmanagement, configuratiemanagement, configuratiemanagement en wijzigingsbeheer aan bod. Planningsmanagement omvat product definitie (decompositie) technieken, tijdsplanningstechnieken en resourcemanagement. Financieel management gaat in op de investeringsbegroting, financiering en de begroting en kostenbeheersing. Bij risicomanagement komen verschillende risicotechnieken en maatregelen en de risicomentaliteit en risicobereidheid aan bod. Vervolgens wordt verandermanagement en resourcemanagement behandeld. Resourcemanagement omvat onder andere inkoop, contractmanagement en mobilisatie.

Deel 4A beschrijft een generiek procesmodel voor zowel programma’s als projecten. In dit model komen de volgende processen aanbod (hierbij herkennen we de verschillende processen van PRINCE2 en MSP):

  • Identificatieproces (Voorbereiding van een project- of programmavoorstel)
  • Sponsorschapproces (formele go/no go beslissingen bij faseovergangen en escalaties en ad-hoc ondersteuning).
  • Definitieproces (definitieve beoordeling of het project of programma gerechtvaardigd is aan de hand van een gedetailleerd beeld van en hoe het werk wordt gemanaged).
  • Opleverproces (de dagdagelijkse werkzaamheden van de project- of programmamanager).
  • Overgangsproces (afsluiten voorgaande fase en plannen van volgende fase).
  • Ontwikkelproces (de daadwerkelijke realisatie van de (deel)producten of services).
  • Afsluitingsproces (gepland of vroegtijdig afsluiten van het project of programma en eventuele lessen vaststellen).
  • Batenrealisatieproces (voorbereiden en uitvoeren van de transitie en baten oogsten).

Deel 4B gaat in op het portfolioprocesmodel. In dit model zien we de volgende processen:

  • Initiatieproces (ontwerpen, voorbereiden en invoeren van portfoliomanagement). Een programma op zichzelf.
  • Besturingsproces (ondersteunen van het portfolio, vakgebied en specialisme)
  • Managementproces (vgl. de definitiecyclus van MoP. Selecteren, categoriseren, prioriteren en balanceren).
  • Coördinatieproces (dagelijkse coördinatie).

Deel 5 beschrijft en aantal persoonlijke vaardigheden zoals communicatie, leiderschap, delegeren, teamwork, conflicthantering, onderhandelen, beïnvloeden.

Deel 6 behandelt de inrichting van de competentiesectie en volwassenheidssectie op de website, inhoudelijk wordt er niet op ingegaan.

Bijlage A beschrijft de te hanteren documenten, onderverdeeld in managementplannen (besturing), scopedocumenten en opleverdocumenten. Documenten ter ondersteuning van portfoliomanagement ontbreken zowel in het boek als op de website.

Bijlage B geeft een opsomming van Praxis rolbenamingen en overeenkomstige benamingen zoals die gehanteerd worden binnen PRINCE2, MSP, MoP, PMBoK en IPMA.

Conclusie:  Persoonlijk vind ik het jammer dat de structuur van de website is aangehouden en dat de teksten veelal 1 op 1 in het boek zijn overgenomen. Dit boek was een mooie kans geweest om een andere doorsnede te maken en daar de tekst op af te stemmen. Bijvoorbeeld. Ik ben een projectmanager en wat betekent dat, hoe ga ik te werk, met welke context moet ik rekening houden, welke competenties heb ik nodig, welke technieken kunnen mij daarbij helpen, hoe weet ik dat ik het goed doe? Dit is waarschijnlijk mede ingegeven door mijn afkeer tegen het onderscheid in Praxis Foundation en Practitioner. Ik zie de doelgroep niet. Ik denk dat een insteek vanuit een project of programma of portfolio rol een veel betere is. Stel je bent als projectmanager bezig, je wil je kwalificeren maar je moet je nu ook in de details van programma- en portfoliomanagement verdiepen om je te kunnen certificeren. Ik heb mijn twijfels of dit dus werkt. Kijk ik naar portfoliomanagement, dan wordt dat wel heel beperkt behandeld. Ook op de website staat geen extra informatie waardoor het erg kort door de bocht is dat Praxis frameworks als MoP of de Standard for Portfolio Management vervangt. Om met portfoliomanagement aan de gang te willen gaan heb je toch echt meer nodig.

Ik heb ook een overzicht van de belangrijkste rollen met bijbehorende taken en bevoegdheden gemist.

Lezing en heen en weer springen naar de website heeft in ieder geval mijn beeld bevestigd dat Praxis geen volledige vervanging is van PRINCE2, MSP en MoP en de technieken uit de PMBoK en IPMA-competenties en volwassenheid volgens P3M3. Agile werken zoals beschreven in PRINCE2 Agile of AgilePM vind ik verder slechts summier terug in een paar artikelen op de website. Ook de bij de genoemde frameworks gehanteerde principes heb ik gemist. Praxis zal ik persoonlijk dan ook niet snel aanbevelen.

De auteurs hebben middels hun Praxis Framework Compact model een totaaloverzicht willen geven. Een figuur die in het inleidende hoofdstuk wordt uitgelegd en bij ieder deel weer terugkomt om dat deel te positioneren (m.u.v. Deel 1 Kennissectie Onderdeel context). Wat mij betreft een lastig te lezen figuur. Te kleine letters, te grote letters, door het figuur verticaal af te drukken staan een aantal omschrijvingen op zijn kop en bevatten spelfouten. Daarnaast ontbreekt het portfoliomanagementproces. Ook het geforceerd blijven vasthouden aan de navigatie van de website maakt het lastig lezen. Bijvoorbeeld een pijl met daarin de tekst Competentie: Mgmt: Oplevering. Wat bedoeld wordt zijn Oplevercompetenties.

Een ander punt betreft de Nederlandse taal. Zoals gezegd, vaak rechtstreeks overgenomen van de site maar het zijn vaak ‘Google translate’ zinnen met uiteindelijk ‘tenenkrommend’ Nederlands. Zinnen worden niet altijd afgesloten met een punt, enkelvoud of meervoud wordt niet toegepast (heeft of hebben) en een spellingchecker had wellicht ook handig geweest. Verder is er een inconsequent gebruik van hoofd- en kleine letters. Daar de teksten veelal rechtstreeks van de website zijn overgenomen door de auteurs kan je ze dat enerzijds niet direct aanrekenen, maar aan de andere kant, als je er een boek van maakt, dan heb je de plicht om een redactionele toetsing te laten plaatsvinden. Het boek is in eigen beheer uitgegeven dus ik vermoed dat dat achterwege is gebleven. Om de leesbaarheid te vergroten had ik voor de gehele tekst in het boek voor een iets groter font gekozen. Er staat nu wel heel veel tekst op een bladzijde. Eigenlijk ben ik al afgehaakt bij de inleiding van deel 1. Achter iedere zin plaatste ik voor mijzelf de opmerking “ik snap niet wat hier wordt bedoeld?”.

Wat mij betreft is dit boek het stadium van concept nog niet voorbij en dus nog niet rijp voor publicatie. Als de auteurs een volgende versie maken dan zou ik daar ook veel voorbeelden aan toevoegen zodat dit boek een duidelijke meerwaarde heeft t.o.v. de website.

Reactie auteurs op deze recensie:

“Beste Henny

Bedankt voor de mogelijkheid om te reageren op jouw recensie.

Wij willen beginnen met te benadrukken dat het boek opgezet is om een samenvatting van de Praxis website te maken; vandaar dat de tekst bijna 100% gelijk is aan de website. Het boek is bedoeld voor beginnende P3 managers die niet de verschillende aparte methoden willen leren, maar een geïntegreerd geheel met daarbij een verwijzing naar persoonlijke vaardigheden en competenties. Maar ook voor meer ervaren managers binnen project-, programma- of portfoliomanagement zie zich willen verbreden. Daarnaast kan het boek dienen als ondersteuning voor het Foundation examen.

Het is de bedoeling dat na de zomer een boek verschijnt waarin het Praxis Framework praktisch wordt toegelicht. Daarin worden m.b.v. diverse scenario’s de theorie toegelicht (zoals ook in de conclusie aanbevolen wordt). Ook willen we daarbij dieper ingaan op het traject voor de Praxis processen: hoe komt een projectmandaat tot stand.
Omdat dat te ver in de toekomst ligt wilden we alvast een samenvatting maken. Dat geeft ook een verklaring van de beperkte behandeling van portfoliomanagement. En het ontbreken van de bijbehorende taken en bevoegdheden.

Het boek is een samenvatting van de huidige website. Praxis Framework is community driven en nog steeds in ontwikkeling; het is niet af. Vandaar dat op de website en in het boek diverse aspecten summier zijn dan wel ontbreken.

Jouw conclusie dat Praxis geen volledige vervanging is van PRINCE2, MSP, MoP en dergelijke, is waar en is ook logisch. Immers in de oude gedachtegang is er een methode nodig voor projectmanagement, programmamanagement en portfoliomanagement. Praxis Framework gaat echter uit van de gedachte dat een initiatief wordt gerealiseerd met aansturing door een P3 manager en de aansturingswijze wordt bepaald door de complexiteit van scope en omgeving. Hierdoor heb je geen aparte beroepsgroep meer en dus ook geen aparte methode.

De opmerking m.b.t. de figuur en de Nederlandse taal nemen we ter harte. We gaan er beter naar kijken en zullen dit aanpassen.
Er zijn in het algemeen opmerkingen m.b.t. de navigatie en inzicht in de Praxis website. Wij waren misschien te eager en te snel om een samenvatting te publiceren als ondersteuning bij de Praxis Framework foundation training

Je geeft aan dat “Wat mij betreft is dit boek het stadium van concept nog niet voorbij en dus nog niet rijp voor publicatie“. Dat is heel jammer, en we zullen dit met het vertaalteam bespreken. Zeker m.b.t. de opmerking over de inleiding van deel 1: die tekst is afkomstig van de webpagina’s “Overzicht” en “Context” aan het begin van het kennissectie-menu.

Aan het begin stel je de vraag “Ik heb het lastig gevonden om op basis van de website een helder en compact beeld te krijgen wat Praxis nu precies inhoudt. Gaat deze handleiding mij daarmee helpen?” Gezien de recensie die verdeeld is in een inventarisatie en een conclusie zou ik zeggen dat het wel gelukt is om dit beeld te krijgen en weer te geven. Dat het beeld dat daaruit naar voren komt voor jou negatief is, is jammer en voor ons als samenstellers en lid van het vertaalteam een duidelijk signaal wat we op moeten pakken.”

Review: Introduction to Disciplined Agile Delivery

9200000046318020Scott W. ambler and Mark Lines are the creators of the Disciplined Agile Delivery framework and the authors of the book Introduction to Disciplined Agile Delivery – a small Agile Team’s journey from Scrum to Disciplined DevOps (2ndedition).

Disciplined Agile Delivery (DAD) is one of the four elements of Disciplined Agile (DA). The other parts are Disciplined DevOps, Disciplined Agile IT (DAIT) and Disciplined Agile Enterprise (DAE).

DAD is characterized by the following aspects:

  • Hybrid: combines Scrum, Agile Modelling, XP, Unified Process, Kanban, Lean, Outside-In Development (OID) and other methods
  • Full delivery cycle. Scrum offers only a development cycle. DAD starts from team initiation all the way to delivering the solution to its end users
  • Supports multiple lifecycles based on inception, construction and transition: an agile/basic version that extends the Scrum construction lifecycle with proven ideas form Unified Process to support early mitigation of risk and lightweight governance; an advanced/lean lifecycle based on Kanban; an agile continuous delivery lifecycle; a lean continuous lifecycle; and an exploratory lifecycle based upon a Lean Start-up approach
  • Complete: DAD includes advice how development, modeling, documentation, and governance strategies fit together
  • Context-sensitive: instead of prescriptive frameworks like Scrum, DAD promotes a goal- or object-driven approach.

The core of the book is a case study. We follow a team on their journey to use DAD and more specific the Scrum-based agile/basic lifecycle. It starts, after the introduction of the team and other stakeholders, with the Inception phase. The goals of the Inception phase are: form initial team, develop common vision, align with enterprise direction, explore initial scope, identify initial technical strategy, develop initial release plan, secure funding, form work environment, identify risks and develop initial test strategy.

In the construction phase the team uses, as described in the release plan, ten construction iterations to produce a potentially shippable solution. Every iteration starts with an iteration planning cycle. Every day there will be a coordination meeting and the iteration ends with the iteration review/demo and the retrospective. Additional to scrum, DAD will have a proven architecture and the sufficient functionality milestone reviews too and you have to pass both successfully before you can go into the Transition phase.

The focus of the Transition phase is for a team to release/deploy their consumable solution into production successfully. To ensure that the solution is ready to deploy the team focusses on the final testing and fixing, the support training of the helpdesk staff, the finalization of the deliverable documentation, the support of the development of end-user training (videos), and the validation of the deployment scripts.

As a next step we follow the team on their road to Disciplined DevOps. In this case the team decided to have seven 2-week iterations. Some highlights of the iterations are the adoption of Test Driven Development (TDD), working from home, improvement tracking, the evolvement of the team, the usage of parallel independent testing, how to cope with vacations and the sharing of their learnings, ATDD or BDD training and adoption, requirements envisioning, quality and continuous integration and deployment. At a certain moment, after several releases, the release cadence was tightened, and their lifecycle evolved towards the lean lifecycle and the team stopped with sizing their work.

Conclusion: if you are looking for a comprehensive overview of DAD this is the book to read. The case gives a good overview of the Scrum-based agile/basic lifecycle and may help you to take the first steps to implement DAD.

More information can be found on disciplinedagileconsortium.org

To order: Introduction to Disciplined Agile Delivery

Disciplined Agile and Disciplined Agile Delivery positioned in my birds eye view on the agile forest

Grasp session (Scaling Agile T-Mobile, 2019 Q1) v0.1