Tag Archives: Agile

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





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


Recensie: Agile Leiderschaap

9789463673617-480x600Een niet veel goeds voorspellend bericht op de vertrekborden op de luchthaven in Manchester. Relex, Shop and Eat. En ja hoor, bijna twee uur vertraging. Het vervelende dus maar met het aangename verenigen en het boek Agile Leiderschaap, geschreven door Twan en Kees Lintermans, gelezen. Deze keer geen doorwrocht managementboek maar een luchtig managementsprookje.

We volgen een door een herder en zijn hond strak geleide kudde schapen. Problemen worden niet gedeeld en alles moet volgens vooraf vastgestelde graasplannen verlopen. We leven mee met Hugo, een jonge ram, die van mening is dat het ook anders zou moeten kunnen. Deze Hugo krijgt de kans om een tijdje met een kudde moeflons mee te draaien. Een kudde waar geen plek is voor een herder of hond. We zijn getuige van een aanval door een roede wolven en hoe de kudde daar mee omgaat. Waarbij zowel de roede wolven als de kudde moeflons vooraf hun strategie hebben bepaald en achteraf er beiden van leren.

En hiermee kunnen we de parallel leggen met een command en control aansturing versus een zelf organiserend team. Ook maken we de transitie mee van de strak aangestuurde kudde schapen naar een zelf organiserende kudde en hoe deze kudde het probleem van de klauwen van beren weten op te lossen. En dit succes wordt door de pers groot opgepakt.

Het verhaal leest vlot weg, is prettig geschreven, laat het je glimlachen en kan zelfs spannend zijn. De moraal moge duidelijk zijn, alle ingrediënten voor een sprookje zijn aanwezig en geeft je een eerste inkijk wat het betekent om als team zelf organiserend je weg te vinden.

Wellicht had er nog een afsluitende bijlage toegevoegd kunnen worden waarin een stukje bijbehorende theorie was samengevat.

Dit boek is het eerste sprookje van de website managementsprookjes.nl dat in boekvorm is verschenen. Op de website vind je nog een aantal (kortere) sprookjes waaronder Tesla en het drama van het zelfsturend team en Het voetstuk van de Farao.

Bestellen: Agile Leiderschaap

Recensie: 50 tinten nee – effectief stakeholdermanagement voor de product owner

9789024427079-480x600Ik vraag wel eens een product owner om zijn/haar product backlog te laten zien. Als deze backlog erg groot is, is dat voor mij een indicatie dat de product owner wellicht nog moet groeien in vak-volwassenheid of dat hij/zij te weinig mandaat heeft. In workshops of presentaties vraag ik wel eens naar de belangrijkste competentie van een product owner. Wat mij betreft NEE zeggen of wil je als product owner te boek staan als ‘shopping list manager’, order taker, of backlog secretary? Kortom, ik ben benieuwd naar dit boek 50 tinten nee – effectief stakeholdermanagement voor de product owner geschreven door Robbin Schuurman en Willem Vermaak.

Het boek begint met het neerzetten van de product owner rol en typen product owners (scribe, proxy, business representative, sponsor en entrepreneur). Vervolgens wordt ingegaan op een belangrijke competentie van de product owner namelijk stakeholdermanagement. Uit het boek Stakeholdermanagement – Start met wie worden 33 typen stakeholders gehaald waarvan velen ook voor de product owner interessant zijn. Als product owner helpt het om een stakeholder map te maken waarin het belang van (laag – hoog) en invloed door (laag – hoog) de stakeholders geplot kan worden om daarmee te bepalen hoeveel tijd je in de relatie moet stoppen (monitoren, informeren, tevreden houden en actief samenwerken).

Een volgend hoofdstuk gaat in op het effectief nee zeggen en waarom nee zeggen zo moeilijk is. Wat gebeurt er als je nee zegt, hoe kijkt men dan tegen je aan? Verder bespreken de auteurs vier patronen die het lastig maken om nee te zeggen zoals angst voor conflicten, angst voor teleurstelling bij anderen, angst voor hiërarchie en nee zeggen betekent ‘het patroon’ doorbreken.

QRC 50 tinten neeDownloaden: QRC 50 tinten nee

Het boek beschrijft een eenvoudig vijf stappenmodel om op een effectieve wijze nee te zeggen (zie ook bijgaande quick reference card):

  1. Wie – Tegen wie ga je nee zeggen?
  2. Wat – Wat is de vraag van de stakeholder?
  3. Intentie – Wat is jouw intentie?
  4. Zeg nee – Formuleer de juiste nee – wat je zegt
  5. Wederhoor – Heeft de ander het begrepen? En wat is de reactie van de ander?

De 50 tinten nee zijn in negen categorieën verdeeld:

  1. De duidelijke nee
  2. De vanuit de klant/gebruiker geredeneerde nee
  3. De vanuit waarde geredeneerde nee
  4. De vanuit budget geredeneerde nee
  5. De vanuit timing geredeneerde nee
  6. De vanuit de impact op de omgeving geredeneerde nee
  7. De vanuit kwaliteit geredeneerde nee
  8. De nee als alle andere nee’s niet (meer) werken
  9. Bonus: De nee om je mandaat mee te vergroten

Iedere categorie wordt toegelicht en er wordt een link gelegd met het type stakeholders in de stakeholder map. Niet ieder kwadrant met stakeholders in de stakeholdermap leent zich voor alle tinten in die categorie. De eerste zeven categorieën zijn onderverdeeld in zeven voorbeelden (tinten). Categorie acht beschrijft een uitzonderingssituatie waarbij geen van de voorgaande vormen werkt en je een stakeholder hoger in de organisatie laat beslissen. De laatste categorie laat een aantal tinten zien waarmee je meer mandaat verdient. Iedere categorie wordt afgesloten met een praktisch voorbeeld ter inspiratie en verheldering.


Een vlot leesbaar boek dat je aan de hand van een vijf stappenplan en negen categorieën met in totaal 50 tinten nee, meeneemt om op de juiste wijze nee te zeggen. Op verschillende plekken vind je kaders met daarin dingen om over na te denken. Dit helpt je om daadwerkelijk te begrijpen waar het over gaat. Ook krijg je praktijktips en vele praktijksituaties waarin op de juiste wijze nee wordt gezegd. Kortom verplichte literatuur voor product owners!

Af en toe had ik het idee dat heb ik in een ander boek ook gelezen maar ik miste verwijzingen naar bestaande boeken. Bijvoorbeeld de beschrijving van product owner-typen of de zin ‘moeten we dat nu doen’, In het hoofdstuk over nee zeggen had wellicht een link gelegd kunnen worden met het boek De kracht van Nee! – Positief Nee! zeggen om tot Ja! te komen geschreven door William Ury, daarnaast had een literatuurlijst niet misstaan (op mijn blog staan o.a. The Professional Product Owner, The Product Samurai).

Bestellen: 50 tinten nee – effectief stakeholdermanagement voor de product owner

Recensie Agile focus in besturing

9789401803878-480x600Agile focus in besturing – pocket guide voor executives in transformaties is geschreven door Marjolijn Feringa en Jeroen Venneman en biedt een praktische methode om als managementteam de focus te houden op de belangrijkste initiatieven en kwartaal voor kwartaal nieuwe focus aan te brengen zodat je als organisatie wendbaarder wordt.

Door het boek loopt een casus van een fictief bedrijf waarin het managementteam, onder begeleiding van een coach, het FOCUS-bord leert toe te passen. Dit visuele bord staat centraal in dit boek.

Het boek begint met een korte introductie op het Agile Manifesto en de vertaling van dit Manifesto voor directieteams in het Agile Executive Manifesto:

  1. Samenwerken aan teamdoelen boven gaan voor individuele mijlpalen
  2. Prioriteren van onderwerpen boven volgen van de agenda
  3. Wegnemen van belemmeringen boven stimuleren van resultaten
  4. Bijsturen op actuele inzichten boven analyseren van rapportages
  5. Visueel overzicht boven spreadsheet rapportages
  6. Verdeling van voorbereiding boven iedereen bereid alles voor
  7. Experimenteren binnen kaders boven plannen maken
  8. Elke kans om te verbeteren benutten boven tijd plannen voor verbeteren
  9. Stellen van vragen op de werkvloer boven accorderen van voorstellen in de vergaderzaal

Daarnaast wordt het belang van het hebben van een visie toegelicht en wat een verandering naar een meer wendbare organisatie betekent.

Het FOCUS-bord heeft drie doelen namelijk visuele ondersteuning, bevorderen van de samenwerking en het aanbrengen van focus. Het verbindt de strategie met de belangrijkste initiatieven, vertaalt de strategie (thema’s) in doelen op de lange termijn, het lopende jaar en het lopende/komende kwartaal (en uitgesplitst per maand). Er worden KPI’s gebruikt om eenduidig meetbare punten te creëren (status). Doelen worden middels initiatieven gerealiseerd. Initiatieven zijn verzamelingen van mijlpalen om een doel te bereiken. Mijlpalen worden als deliverables beschreven. Ieder initiatief heeft haar eigen facilitator die in de stand-up een update geeft over dit initiatief.

Het is de bedoeling dat wekelijks dit bord wordt bijgewerkt en besproken. Waarbij de voorkeur voor staand vergaderen wordt benadrukt. Voor deze stand-up hebben de auteurs een standaard agenda en grondregels opgesteld (Noot recensent: hoe verhoudt zich dit tot het tweede punt uit het Agile Executive Manifesto (Prioriteren van onderwerpen boven volgen van de agenda?). De agenda bestaat uit de volgende punten: check-in, status impediments, doorlopen initiatieven, hulpvragen/impediments/mededelingen, parkeerplaats-punten, fist of five (mini retro: vuist: kon niet slechter, 5 vingers: kon niet beter).

Iedere drie maanden moet het FOCUS-bord ververst worden, de zogenaamde kwartaalwissel. Hier vinden de volgende gebeurtenissen plaats: review resultaat afgelopen kwartaal en aanpassen/aanscherpen doelen, retrospective, planning komend kwartaal.

Het FOCUS-bord staat niet op zichzelf. Strategie verbindt alle teams en middels het cascaderen van strategische doelen naar onderliggende managementteams bereik je dat iedereen op dezelfde golflengte zit. Een mooie manier hiervoor is dat individuele directieleden op eenzelfde manier met een FOCUS-bord aan de slag gaan voor hun eigen MT.

Om in lijn met ontwikkelteams te blijven en hun werkwijze te begrijpen, wordt aanbevolen dat directie of MTs ook, een maar dan op maat gemaakte, Scrum werkwijze gaan hanteren. Verder beschrijven de auteurs een aantal technieken (FOCUS toolbox) zoals de manifesto workshop, strategy deployment (X-matrix) of Hoshin Kanri, veranderkompas, kanban-bord, focus radar, BCP-methode, feature mapping, de retrospective, delegation poker en de anticipate workshop.

Het boek eindigt met een drietal tips om te starten met agile focus in besturing, een agile leiderschap maturity niveau checklist en een beschrijving van de Rabobank case, de FOCUS way of working.

Conclusie: Vlot leesbaar boek met een praktische aanpak en voorbeelden waarmee je als managementteam direct aan de gang kan gaan om een meer agile focus in de besturing aan te brengen.

Jammer dat de voorbeeld FOCUS-borden zo klein gedrukt zijn (zal wel aan mijn ogen liggen maar ik kon de bovenste regel niet lezen). Daarnaast heb ik persoonlijk moeite met het gebruik van het woord facilitator van het initiatief. Deze facilitator kan volgens de auteurs periodiek wisselen. Ik zou liever geen wisselingen willen zien en dat het de eigenaar/sponsor van een initiatief is die toelicht als er problemen zijn. Daarnaast wordt eigenaar initiatief en facilitator door elkaar gebruikt in de tekst. Verderop in het boek wordt vervolgens het begrip facilitator gebruikt als iemand buiten het team die optreedt als procesbewaker.

Bestellen: Agile focus in besturing

via de auteurs heb ik een voorbeeld van een FOCUS-bord gekregen.


Downloaden van de drie in het boek genoemde voorbeeldborden: FOCUS bord

In de kop vind je de omschrijvingen van de kolommen, respectievelijk: Thema, Over een jaar doelen, Dit kwartaal doelen, Status van doelen, Belangrijke initiatieven mijlpalen afgelopen kwartaal, mijlpalen maand 1, mijlpalen maand 2, mijlpalen maand 3, mijlpalen komende kwartaal en mijlpalen later, Impediments / Acties (To do, Doing, done) en rechtsonder de Parkeerplek.

Review: The Professional Product Owner

poDon McGreal and Ralph Jocham wrote the book The Professional Product Owner – Leveraging Scrum as a competitive advantage.

This book gives you the insights how you, as a product owner, can identify, measure, and maximize value throughout your entire product lifecycle.

The authors explain that you can call yourself a professional product owner if you can excite, can envision, can cause the product to emerge and you can manage and administer the product as it matures.

The chapters in the book are clustered into three parts strategy, Scrum and tactics. Every chapter starts with a little quiz (statement: agree/disagree) and at the end of each chapter you will find the answers.

The first part – strategy focusses on proper agile product management and maximizing the return on investment (ROI of a product by looking at the three Vs (vision, value, and validation) as a way to achieve this.

Vision creates transparency, value provides you with something to inspect and validation causes adaption. The authors explain why the world of product management a lot bigger is than Scrum. There are many types of product owners starting with scribe, proxy, business representative, sponsor and entrepreneur. Going from left to right the expected benefits from the product owner type will increase heavily. We got an explanation of the business model canvas, the added value of a good vision and what it means to deliver value. Evidence-based management with current value, unrealized value, ability to innovate and time to market is illustrated (in grey boxes you will find the corresponding text from the EBMgt Guide (see review on my blog). In the last chapter – validation, the authors discuss feedback, the usage of different types of MVP’s, the Kano-model and the build-measure-learn feedback loop (based on Eric Ries’ book Lean Start-up).

Part II – Scrum explains empirical process control and how Scrum is a tool for managing complexity and continuous delivery of value. In the text you will find, in grey boxes, corresponding text form the Scrum guide too.

It starts with an explanation of complexity. You get a certainty quiz to measure the uncertainty of your own environment/team. To visualize complexity a modified Stacey graph (categorization model) is explained as well as the usage of Dave Snowdon’s Cynefin model (sense-making) with the five domains obvious, complicated, complex, chaos and disorder. The empiricism of Scrum helps to address risks (misunderstanding of requirements, lack of top management commitment and support, lack of adequate user involvement, failure to gain user commitment, failure to manage end user expectations and changes to requirements and lack of an effective project management methodology). For the rest of this part the focus is on Scrum itself. The pillars (transparency, inspection and adaptation), The Scrum roles (product owner, development team and scrum master) and stakeholders, the Scrum artifacts (product backlog, sprint backlog and the increment) and not official Scrum artifacts (Definition of done, burn-down, burn-up charts), and Scrum events (sprint, sprint planning, daily scrum, sprint review, sprint retrospective). For every element the authors explain the relation with the product owner.

qrc (backlog items, 190121) v1.0To download: qrc (backlog items, 190121) v1.0

The last part – tactics introduces more concrete practices and tools for managing product backlogs (see the attached QRC) and release plans and concludes by examining what it means to be a professional product owner.

It starts with an explanation of a requirement and you get an explanation of the different items on a product backlog (feature requirements, non-functional requirements, experiments, user stories, bugs/defects, user cases, capabilities, …) and an example of a product backlog item template with acceptance criteria and common ways of writing acceptance criteria (Test that …, Demonstrate that …, Gherkin syntax (given, when, then)). How you can order a backlog based on business value, risk, cost/size and dependency including measuring value, risk and size is a next topic. The definition of “done” is defined as well the meaning of ready. A lot of other techniques are discussed e.g. story mapping, impact mapping, specification by example and agile testing. Release management is the next big chapter in this part. What are release management, reasons to release, release strategy, major, minor and functional releases? How can you use estimation and velocity to answer the question when will I get it? Scaling in terms of more products or more teams as well as a brief overview of the Nexus framework are introduced. This chapter ends with some more techniques like the Monte Carlo simulation to estimate a product backlog, velocity breakdown by type (features, bugs, technical debt and infrastructure), budgeting, governance and compliance, release kick-off and quality (definitions, product and technical quality, keeping quality). This part ends with the skills and traits of a good product owner.

Conclusion: If you are a product owner this is absolutely a must read. You get explanations, techniques, examples and real-life cases from the authors how you have to and can play your role as a professional product owner.

To order: The Professional Product Owner

A birds eye view on the agile frameworks forest

Some years ago, you could say “Scrum is agile” and ask “is agile Scrum?” Now we know there is more flesh on the bones. At this moment there are more than fifty known and less known agile frameworks available. To get a first impression of the different frameworks, I try to bring some structure in the jungle to methods and frameworks. In Figure 1, I position the best-known agile frameworks in a structure. The frameworks are positioned within the ‘One-time programs / projects’ sections or within ‘Business as usual’ / indefinite, or both.

Grasp session (Scaling Agile T-Mobile, 2019 Q1) v0.1Fig. 1 Overview agile framework[1]

On the other side the frameworks are clustered around team, product or programme and portfolio level. In the dark blue boxes in Figure 1 we see agile frameworks that are only applicable in IT-focused organizations. All other frameworks can be used within IT and non-IT-oriented organizations (light blue coloured). I haven’t mapped all the known frameworks in this figure, and to be honest, I think there is a lot of duplication and probably commercial drivers play a role too to ‘develop’ the next kid on the block without added value in comparison with the existing frameworks.

The team level, including Scrum and Kanban, is applicable in both IT-oriented and non-IT-oriented products and services development and operations. The engineering level focuses specifically on IT-oriented product development. The one-time, temporary projects and programme frameworks are suitable for both IT and non-IT. The permanent umbrella frameworks (both product-targeted and team-targeted) focus specifically on IT and product development and the business-targeted frameworks help organisations to increase their agility.


If we start at the team level in Figure 1, then we see of course Scrum as described by Ken Schwaber and Jeff Sutherland in their Scrum Guide. In addition, you will see frameworks such as Kanban (as described in the Kanban Guide for Scrum Teams), Scrumban and DevOps or BusDevOps. The team level can be used both within the IT environment and the non-IT environment. At this team level we can position the following IT frameworks too: Crystal family (developed by Alistair Cockburn with Crystal Clear and Crystal Yellow, Orange, Orange Web, Red, Maroon, Diamond, and Sapphire), Rapid Application Development (RAD developed by James Martin), Adaptive Software Development (ASD by Jim Highsmith, Sam Bayer), Agile Unified Process (AUP) as a simplified version of Rational Unified Process (RUP) which was superseded by Disciplined Agile Development (DAD) which was superseded by Disciplined Agile (DA). If you want to deliver quality as a team within the IT world, only following these frameworks is not enough. To improve quality and minimize technical debt (e.g., inefficient code due to many iterative adjustments), you could make use of eXtreme Programming (XP, developed by Kent Beck, Ward Cunningham, and Rom Jeffries) with Pair Programming, Acceptance Test Driven Development (ATDD), Test Driven Development (TDD), Behaviour Driven Development (BDD), Feature Driven Development (FDD), Example Driven development (EDD), User Experience (UX) Design, Continuous Integration and Continuous Deployment. AgileBA delivers the techniques to perform business analysis.

Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles, that can be applied on an (agile) software development project. There are several core practices: documentation, document continuously, document late, executable specifications, single-source information, active stakeholder participation, architecture envisioning, inclusive tools, iteration modeling, just barely good enough (JBGE), look-ahead modeling, model storming, multiple models, prioritized requirements, requirements envisioning.

 Scrum or Kanban?

When teams start working with Agile, Scrum is often chosen. An obvious choice, but the question is whether this is always the right choice. In a Roman Pichler[2] blog the link was made with the life phase of a product. During the first phase of a commercial product lifecycle, in which the commercial product is finally put on the market for the first time, the uncertainty is high, and the focus is on on-time delivery of the first market-ready product. A deadline has been set and that date must be met. During this phase, the focus of the entire team is on delivering a commercially marketable product. This development is perfect for Scrum with its iterative approach, being able to deal with uncertainty and working together on the result (the commercial product). Optionally, a second launch can take place with a next set of important functionalities, so that eventually a mature product is put on the market. During the further course of the product lifecycle, we see the amount of uncertainty and requested changes decrease. At this moment you can make good use of Kanban. In a continuous flow, User Stories can be picked up, developed and deployed one by one by individual team members.

If one looks at the often difficult transfer to production environments, the time-to-market can be shortened by properly arranging the transfer and reducing the number of transfer errors when development and production teams are merged, and the integration testing and deployment are automated (Continuous Integration and Continuous Deployment CI/CD). In this way a DevOps team is created.

Scrumban is the combination of Scrum and Kanban. In the first instance it was intended as a transitional model to switch from Scrum to Kanban and let the team experience Lean- and Kanban concepts. Nowadays it is an approach in which the team has chosen to work according to Scrum with Sprints, but to use the Kanban system to continually view and improve its working method to optimize the flow of units of work (e.g. User Stories).

Scaling up towards product- or program level

In order to be able to use an agile way of working in an organization of some size, just having individual agile teams is not enough. The agile way of working needs to be scaled up and where possible the overarching alignment needs to be institutionalized.

To institutionalize coordination, management of dependencies and integration between the different permanent agile teams within ‘the run-the-business’ / ‘business-as-usual’ side there are various frameworks available, including:

  • Nexus, as described in The Nexus Guide, is a framework for developing product or software development initiatives with three to nine Scrum Teams, in Sprints of up to thirty days. Nexus is the answer of Ken Schwaber, one of the founding fathers of Scrum, to the scalability of Scrum. It requires more than just the will and the agile behaviour of the different Scrum Teams to work together to deliver an integrated product. Nexus is based and builds on Scrum and the rules and roles formulated in The Scrum Guide. We can position Nexus over the team and program levels of SAFe, but it does not offer provisions on portfolio level.
  • Scrum at Scale (S@S, developed by Jeff Sutherland and Alex Brown) is a modular framework. The starting point at S@S is that an all-encompassing one-size-fits-all framework is not possible, but that every time we have to look at scaling of the underlying Scrum principles. The framework can be tailored for your own organization by adding the needed S@S modules. S@S builds on the well-known Scrum framework. By analogy with Nexus you could therefore say that S@S is the answer from Jeff Sutherland, next to Ken Schwaber, the other founding father of Scrum, on the scalability of Scrum.
  • Large-Scale Scrum (LeSS, developed by Craig Larman and Bas Vodde) is an agile framework with rules, based on principles and doing experiments. The LeSS Company offers a freely accessible knowledge base (less.works) containing the integrated approach, principles, process descriptions, definitions, roles, examples, et cetera, for large-scale, mainly IT-related, product development. Transparency is also a key concept within LeSS. The first version dates from 2005 and since then, work is constantly being done on the use and further development of LeSS.
  • Scaled Agile Framework (SAFe, developed by Dean Leaffingwell) is a framework to enable scaling up of agile teams in order to create better systems, create higher employee engagement and make use of correct cost considerations. This is the mission of the scaled agile organization and of the founder of SAFe, Dean Leffingwell. The scaled agile organization offers a knowledge base that is freely accessible to everyone (www.scaledagileframework.com) with an integrated approach in the form of process descriptions, definitions, roles, examples, etc. for Lean / Agile product development. SAFe is based on five core competences: Lean-Agile Leadership, Team and Technical Agility, DevOps and Release on Demands, Business Solutions and Lean Systems and Lean Portfolio management.

Figure 1 (see the ‘Business as usual’ / indefinite block), makes use of a division between product and team targets, namely on the basis of cooperation, if necessary, of teams or not. Or with other words, can the individual teams work autonomous (team focus) or do they have to work together to deliver a new or modified product (product focus). The fore mentioned frameworks all relate to examples where multiple teams work on a single complex product or value stream (product targeted frameworks). Not visual in the figure several frameworks make a distinction between products where you are working together in with a maximum of nine teams (in total the team of teams must not exceed the Dunbar number of 125-150 people) and a team of teams of teams (e.g. SAFe large solutions, Nexus+, LeSS Huge).

The other group concerns frameworks to support IT departments that have to maintain dozens or hundreds of applications or services, whereby the dependencies between the teams are minimal (multiple team targeted frameworks). Here the Spotify model (developed by Henrik Kniberg, Anders Ivarsson and Joakim Sundén) can be positioned, but also Scaled Agile Lean Development (ScALeD, developed by Peter Beck, Markus Gartner, Christoph Mathis, Stefan Roock and Andreas Schliep). For both groups, there are essential interfaces between the teams in areas such as data integrity, security and architecture that may not or sometimes will ask for coordination when implementing changes.

In addition, there are many, less known, frameworks that can offer support at the product level, including Agile Integration Framework (AIF), Agile Team Portfolio Management (AgileTPM), AgilePath, Continuous Agile, Disciplined Agile (DA), Enterprise Scrum, Enterprise Agility, FAST Agile, RAGE, Surge, XSCALE, Industrial XP, and AgileDS.

On the left side of figure 1 we see the one-time projects and programs as part of ‘change the business’. Here a distinction is made between projects and programs. Within the project block we see three frameworks and/or methods, all three of which are a further development of the more traditional project management frameworks:

  • Agile Project Management (AgilePM, which is derived from DSDM);
  • PRINCE2 Agile (derived from PRINCE2 from AXELOS)
  • PMI-ACP (in addition to the PMBoK Guide of PMI)
  • Project Half Double (Project Half Double is run by a community of dedicated project management practitioners who are passionate about what they do)
  • Agile Project Management (APM), not mentioned in the figure, can be positioned here too.

On the program side we see:

  • Managing Successful Programs (MSP from AXELOS) that is very agile in itself with the step-by-step growth (via tranches) towards the intended goal (and connects to PRINCE2 (Agile)) and
  • AgilePgM (Agile Program Management of Agile Business Consortium) that connects with AgilePM on the one hand and is comparable with MSP on the other hand.

Praxis covered the portfolio, programme and team levels. Praxis is a free framework for the management of projects, programmes and portfolios (based on PRINCE2, MSP, MoP, AgilePM and other frameworks). It includes a body of knowledge, methodology, competency framework and capability maturity model. The framework is supported by a knowledgebase of resources and an encyclopaedia.

Disciplined Agile (DA) covers both one-time projects and programs as well as business as usual product development. The DA toolkit is a process decision toolkit that describes how agile software development, DevOps, IT, and business teams work in enterprise-class settings.

Portfolio management level

Traditional portfolio management focuses on ‘change the business’. In the previous chapters it has become clear that more and more changes are being handled by the line organization, that is to say: by the permanent agile teams. This means that portfolio management must now also provide an overview of what takes place in ‘run the business’ / ‘business as usual’ for to be implemented change initiatives. Existing portfolio frameworks such as Management or Portfolios (MoP from AXELOS) and Standard for Portfolio Management (SfPfM from PMI) only cover the change-the-business part. Agile Portfolio Management (AgilePfM from ABC) covers ‘run the business’ / ‘business as usual’ as well as ‘change the business’.

In addition, there are a number of agile frameworks that also include a portfolio management component:

  • SAFe offers a portfolio management layer to control ‘run the business’ / ‘business as usual’ permanent team(s) of teams.
  • Disciplined Agile (DA) offers a portfolio process in which, in addition to projects, a number of ‘run-the-business’ / ‘business-as-usual’ aspects are taken into account, such as the permanent teams and the operational management of existing IT solutions.
  • Scrum @ Scale contains modules Strategic vision and Organizational development to which portfolio management can be related.
  • Spotify also provides its own portfolio management approach with its strategic planning.
  • AgilePfM use some basic concepts of an innovation hub, an agile portfolio process, maturity of the initiatives within the portfolio as well as horizons for an agile portfolio.

At the moment (Jan’ 2019) there are no mature portfolio management frameworks that include ‘change the business’ as well as ‘run the business’ / ‘business as usual’. AgilePfM was launched by the Agile Business Consortium (previously DSDM Consortium) as part of their Agile Business Change Framework. However, it is becoming increasingly clear that the overarching agile portfolio management principles are based on frameworks like SAFe, Agile PfM and Disciplined Agile.

Business level

The culture targeted block provides frameworks to increase business agility by changing the mindset of all staff in the organisation. What does it mean to work in an agile way? How can we make sure that the Agile Manifesto values and principles are understand and applied, and the Scrum values (courage, focus, commitment, respect and openness) are part of what we are doing? If the right mindset is in place it makes it much easier to implement an agile framework. In figure 1 the following frameworks are mentioned:

  • Open Space Agility (OSA) is a safe, pragmatic and repeatable technique for getting a rapid and lasting Agile adoption. It works with the framework you are currently using, and OSA can be added at any time. OSA is used to actively engage as many employees as possible in your Agile program.
  • AgileSHIFT (developed byAXELOS) is a framework that prepares people for transformational change by creating a culture of enterprise agility. The AgileSHIFT framework helps organizations to undergo a transformational change, to adopt a ‘survive, compete and thrive’ mindset. It will help to bridge the gap between the current and the target state (the Delta in AgileSHIFT) by embracing a range of agile, structured and hybrid approaches across the organization. The existing severe split between ‘run the business’ and ‘change the business’ will vanish.
  • Agility scales (developed by Jurgen Appelo) helps organizations achieve agility at scale from the bottom up – with measurable evidence of organizational transformation.
  • Lean Startup (developed by Eric Ries) is a methodology for developing businesses and products, which aims to shorten product development cycles and rapidly discover if a proposed business model is viable; this is achieved by adopting a combination of business-hypothesis-driven experimentation, by using a minimum viable product (MVP), iterative product releases, and validated learning.
  • Holacracy (developed by Ternary founder Brian Robertson) is a method of decentralized management and organizational governance, in which authority and decision-making are distributed throughout a holarchy of self-organizing teams rather than being vested in a management hierarchy.

Not mentioned in the figure:

  • Goal Driven Agile (GDA) rests on three main pillars: autonomy, alignment and structured improvement. It’s a very simple framework and consists of only one base structure, the diamond, five roles and ten building blocks.

Already more than 50 agile frameworks and it’s still growing. The figure can help you in your agile framework selection process, but it cannot be said often enough, do not act dogmatically, see a framework not as a panacea that can be implemented out of the box. Common sense helps too to achieve more agility and probably the best route to become more agile is dividing your products and services into smaller autonomous parts and have them supported by an individual team.

To download this article: A birds eye view on the agile frameworks forest v1.3

[1] This picture is based on a simpler version in the book Scaling Agile in organizaties (Portman, 2017)
[2] Pichler, Roman, ‘Is Scrum right for your product?’, 19 september 2016, see: www.romanpichler.com