Tag Archives: agilePM

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

A new kid on the agile block: Agile Digital Services (AgileDS)

Last week I followed an APMG ATO / trainer briefing regarding Agile digital Services.

This agile framework, developed by Agile Business Consortium, focusses on building and delivery of digital services. The AgileDS framework will help organizations to develop a consistent agile approach, a common language and a skilled workforce regarding digital services. It uses the same terminology as other agile frameworks. It is based on the GDS lifecycle (Government Digital Service, UK), themes and responsibilities have evolved from the roles and responsibilities in AgilePM and its agile practices come from other existing frameworks (e.g. WSJF from SAFe).

AgileDS (QRC, 180718) v1.0To create this quick reference Card I used the handbook that is available for feedback (beta phase). To download the QRC: AgileDS (QRC, 180718) v1.0

Generic and governance principles

The ten generic principles are:

  1. Start with needs
  2. Do less
  3. Design with data
  4. Do the hard work to make it simple
  5. Then iterate again
  6. This is for everyone
  7. Understand context
  8. Build digital services, not websites
  9. Be consistent, not uniform
  10. Make things open: it makes things better

The six governance principles are:

  1. Don’t slow down delivery
  2. Decisions when they’re needed, at the right level
  3. Do it with the right people
  4. Go see for yourself (GEMBA)
  5. Only do it if it adds value
  6. Trust and verify

Service Lifecycle

There are five phases discovery, alpha, beta (privat and public), life and service retirement which can be tailored to meet the needs of different organizations. The aim is to deliver  incrementally within each phase with a significant delivery at the end of a phase.

Products

The following products are described (purpose, when created, updated, needed): Terms of Reference, Business Case, Backlog, Roadmap, Service Architecture Definition, Development Approach Definition, Management Approach Definition, Delivery Plan, Service Lifecycle Transition Report.

Themes and responsibilities

AgileDS defines a set of responsibilities that are collected into simple themes. All responsibilities must be covered and it’s vital that the team acts as a collaborative and effective whole, with clarity about individual responsibilities. Within the Service Delivery Team the following responsibilities must be covered: service ownership, delivery management, product management, business analysis, service development, user research, technical design, service assurance, service design and service deployment.

When needed specialist guidance should be available: assisted digital guidance, accessibility guidance, performance analysis and agile coaching.

Within Steering and Leadership we encounter the following responsibilities: business sponsorship, service ownership, technical leadership and change coordination (in case of multiple service delivery teams).

Techniques

Several techniques are explained: Kano method, relative prioritization, stack ranking, MoSCow prioritization, WSJF, iterative development and incremental delivery, MVP and MMP, requirements and user stories, user research and personas, timeboxes and sprints.

Conclusion

Where AgilePM is there for the delivery of a product or service (temporary agile project, using a project lifcycle), AgileDS is there for the delivery and the continuous operations, support and maintenance of that service (permanent agile delivery team, using the product/service lifecycle). There will be a foundation and a practitioner certification in line with other APMG certifications.

In the next picture I have positioned AgileDS.Grasp session (Scaling Agile, 180526) v1.1

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.

20170613_133950

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.

OMS_SCALING_AGILE_v6Business 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.

dia1

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:

dia1

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

 

Book review: Agile Project Management and Scrum v2

front-cover-webIn two of my previous posts I wrote about DSDM and UX Design and Agile Project Management and Scrum v2. This is another little book in the same style. And this booklet too can be read as an addendum to DSDM’s Agile Project Management Framework.

Andrew Craddock is the author of the book ‘Agile Project Management and Scrum v2‘.

The booklet starts with a comprehensive overview of Scrum based on the Scrum guide 2013 and an explanation of the Agile manifesto.

Next we get an overview the combined AgilePM / Scrum process framework. The project delivery context is based on AgilePM and the evolutionary development context is pure Scrum.

In this combined framework we see the following changes / additions in comparison with the original AgilePM framework:

 

AgilePM AgilePM/Scrum
Process Evolutionary Development Scrum Development
Product Prioritized Requirements List Product Product Backlog

 

Timebox Plan and Timebox Review Record Sprint Goal, Sprint Backlog and Sprint Review Record
Roles adding the PO, SM roles

An enhanced Scrum two-week Sprint contains some minor embellishments to the standard Sprint:

  • In comparison with a standard Sprint we now see a split in two parts: Refinement (7 days) and Consolidation (2 days).
  • Within the Consolidation part we see a Consolidation Scrum to confirm progress to date and to explain what will be ‘Done’ by the end of the Sprint.

A new event, the Project Planning Event, is added. This event takes place at the boundary of timeboxes and can be used, by project stakeholders, to influence the the work of the Scrum Team without compromising the way Scrum is used.

Dia1

All roles are explained within this combined framework with special attention for the Product Owner role including relationships and interactions with the Technical Coordinator, PM, Business Visionary, Technical and Business Advisors and the Development Team.

Final paragraphs explain the usage of multiple Scrum Teams, Regulatory, and financial governance, the usage of Barry Boehm’s Cone of Uncertainty and some optional techniques (MoSCoW prioritisation, Facilitated Workshops and Modelling).

Conclusion: For those who are using AgilePM in combination with Scrum this is a must read. It gives a nice overview of the changes and a good explanation of the PO role including all relationships and interactions.

To order: Agile Project Management and Scrum v2

This is the last post in a series of three. DSDM and UX design was the first and Agile risk management and DSDM the second.

Review: Agile Risk Management and DSDM

riskIn one of my previous posts I wrote about DSDM and UX Design. This is another little book in the same style. And this booklet too can be read as an addendum to DSDM’s Agile Project Management Framework or separately to enlarge your knowledge about risk management in an agile context.

Talking about a little book, in the foreword you can find a reference to the famous episode, The Protégé, of the programme Seinfeld. It’s about a 700 page risk management book. Look for yourself and have fun.

Alan Moran is the author of the book “Agile Risk Management and DSDM“. He did a great job explaining risk management in an agile environment.

Agile risk management considers, like PRINCE2, not only treats (negative risks) but also opportunities (positive risks) and is concerned with the identification, assessment, prioritization, treatment and monitoring of project risks.

As a starting point for risk identification the following generic risk drivers are high lighted: requirements risk, technical risk, schedule risk, project (approach) risk, supplier risk and people risk. These can be highlighted in the enterprise and project risk driver maps.

In a next paragraph the agile risk management process is explained. It starts with the understanding of the project objectives, context and risk environment, risk scoping (identification of risk drivers and appetite), risk tailoring (embedding risk management in agile process), risk management (identify, analyse, manage and monitor) resulting risk optimized agile process.

Agile risk management is founded on three principles: flow (ensure that events do not inhibit or delay progress), balance (deliver the same reward with less risk) and transparancy (make visible and accessible all risk artefacts). In the book you will get a mapping to the eight DSDM principles.

In the following paragraphs you get an explanation who (DSDM role) performs which risk management activities and how you have to make amendments to the practice of DSDM to cover the overall project risks.

The author explains several risk tools: enterprise and project risk driver maps, the risk log (register), risk reward prioritization matrix, the risk rainbow mapping of risk exposure to risk response strategies (when to apply which risk response strategy), risk tagging (identify the agile (DSDM) practice(s) to mitigate the risk), risk modified timebox plan, risk modified team board, risk burndown chart, risk walling (making visible the project risk driver map, risk log, risk modified timebox plan or team board, risk burndown chart). See the attached figure for some examples.

Dia1The final chapter explains the social and cultural aspects. A common typology of risk stances is: risk-averse, risk-seeking, risk-tolerant and risk-neutral. Individuals tend to be influenced by conscious, subconscious and affective factors.

In summary DSDM enables a new perspective on risk management by injecting elements of cadence (e.g. performing risk analysis at the start of each timebox), transparancy (e.g. using risk modified team boards including risk burndown charts) and agility (e.g. by using risk tagging). 

Conclusion. Many people will say we are using agile techniques so no need to have a separate risk management strategy. This book gives a good approach to cope with risk management within an agile environment. You get an overview of risk management and how it can be tailored and used in a DSDM environment and it can be applied within other agile frameworks too.

To order: Agile risk Management and DSDM

This is the second post in a series of three. DSDM and UX design was the first and Agile Project Management and Scrum v2 will follow

Vlog: Managen van agile projecten

Samen met Van Haren Publishing heb ik een vlog gemaakt van ons boek Managen van agile projecten. In drie minuten leg ik uit waar ons boek over gaat.


9789401800242_CoverLR-230x290Bestellen: Managen van agile projecten.