Tag Archives: Agile

Bimodal Portfolio Management

Introduction

1*ORjFcvHHbyWBTA1WIijXYwAt the moment, many organizations are in the middle, or on the brink of, a radical change to more business agility. I receive quite often the question how to cope with both an agile portfolio as well as a more traditional portfolio with temporary projects and programs. Existing frameworks supports either an agile IT portfolio or a more traditional portfolio, but I haven’t seen frameworks which supports both.

If I look at existing traditional and agile IT portfolio management frameworks, I asked myself if combining these frameworks can bring an answer for those organizations who need to manage an agile as well as a more traditional portfolio?

In this article I will start with a brief explanation of the existing portfolio management frameworks by explaining the principles and the process (Management of Portfolios, Standard for Portfolio Management, Disciplined Agile Portfolio Management, Agile Portfolio Management, Evidence-Based Portfolio Management, and SAFe Lean Portfolio Management).

MoP P3O SAFe Hybrid (190621) v0.1In the second part of this article I focus on Bimodal Portfolio Management where I combine the best of these worlds and offer a solution for both worlds in the form of a Bimodal Portfolio Kanban (see figure), Bimodal Portfolio Management Principles and Bimodal Portfolio Roadmaps.

To download the article: Bimodal Portfolio Management (article, 190626) v1.0

 

Advertisements

The Agile Fluency model

The Agile Fluency model, developed by Diana Larsen and James Shore in 2012 and substantially updated in 2018, is a framework to help teams understand their current position and to help them develop an individual road map. Agile teams pass through four distinct zones of fluency as they learn (fluency evolves). Diana Larsen defines fluency as things that you do automatically without thinking. Each zone brings specific benefits:

  1. Focusing teams produce business value (agile fundamentals). The team thinks and plans in terms of the benefits their sponsors, customers, and users will see from their software.
  2. Delivering teams deliver on the market cadence (agile sustainability). The team can release their latest work, at minimal risk and cost, whenever the business desires.
  3. Optimizing teams lead their market (innovative business agility, agile’s promise). The team understands what their market wants, what your business needs, and how to meet those needs.
  4. Strengthening teams make their organizations stronger (possible future of agile). The team understands its role in the larger organizational system and actively works to make that system more successful.

Schermafdruk 2019-05-30 15.52.02A team’s fluency comes from the ability of team members to self-organize so that individual skills are applied to the right problems at the right times. A team is fluent in a zone when it’s fluent in all of the zone’s proficiencies, including predecessor zones.

The appropriate zone for your teams depends on your organization and can be different from team to team. It is not a ranking system, but is about understanding and working towards the appropriate level of fluency for your needs at a particular point in time. Delivering or Optimizing are often the best targets, but Focusing and Strengthening can also be good choices. Fluency is more a matter of habits than skills.

Video: The Agile Fluency Model Explained: A Brief Guide to Success with Agile

The Agile Fluency Model whitepaper

Agile Fluency Simulation — an educational, exciting board game

This model definitely fits into the culture-targeted block of my bird’s eye view on the agile frameworks forest (see also the complete article):Grasp session (Scaling Agile, 190506) v1.1

 

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.

Conclusie

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.

FOCUS-Bord

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.