Recensies: Het bochtenwerk van de opdrachtgever en Schaalsprongen in de opdracht

Van Edwin van Dieën Kreeg ik bijgaande eerste twee publicaties Het bochtenwerk van de opdrachtgever en Schaalsprongen in de opdracht uit de Kennedy-reeks over goed opdrachtgeverschap. Naar John F. Kennedy vernoemd omdat zijn moon speech (1962] symbool staat voor inspirerend leiderschap en dat kunnen we zien als een sleutelcompetentie van opdrachtgeverschap.

Het bochtenwerk van de opdrachtgever

9789082061611-480x600De eerste publicatie Het bochtenwerk van de opdrachtgever is geschreven door Herman Walta. Geen theorieboek, geen business roman maar een toneelstuk (sketch) over opdrachtgeverschap. Deze sketch is voor het eerst opgevoerd tijdens de IPMA Parade (2012).

In het stuk volgen we een wethouder Onderwijs die als opdrachtgever optreedt bij de bouw van een nieuwe basisschool. In vijf bedrijven krijgen we verschillende dilemma’s en keuzes voorgeschoteld en zien we de consequenties van de gemaakte keuzes waarbij de wethouder steeds verder uit de bocht vliegt. Hierbij staan de vijf bedrijven voor: het goede begin ofwel het besluit tot bouwen, ik ben goed dus ik ben gulzig, als u haast heeft, neem geen tijd, uit de bocht! En ten slotte nog verder uit de bocht.

Een korte leesbare en aansprekende tekst waarin duidelijk wordt dat een opdrachtgever een project kan maken of breken. Prima bruikbaar voor opdrachtgevers in spé die voor hun eerste opdracht staan.

Bestellen: Het bochtenwerk van een opdrachtgever

Schaalsprongen in de opdracht

9789082061628-480x600In het boek Schaalsprongen in de opdracht, geschreven door Edwin van Dieën, wordt een link gelegd met het Cynefin model van Snowdon waarbinnen de auteur verschillende vormen van opdrachtgeverschap positioneert. Daarnaast wordt ook het situationeel leidershapsmodel van Hersey en Blanchard binnen het Cynefin model geplot.

De auteur schetst de samenwerking tussen opdrachtgever en opdrachtnemer aan de hand van het zandloper-model. Informatiestromen lopen van boven (de opdrachtgever) naar beneden (de opdrachtnemer) en terug waarbij de opdrachtgever de ruis van boven filtert en de opdrachtnemer niet alle details naar boven stuurt. Dit model wordt vervolgens geprojecteerd in de kwadranten van Cynefin model:

  • Simpel (klus): Opdrachtgever rol is heel beperkt, de opdrachtnemer voert uit
  • Gecompliceerd: Opdrachtgever beslist over oplossing, opdrachtnemer stelt oplossing voor en realiseert
  • Complex: stuurgroep (coalitie) die de rol van opdrachtgever invult
  • Chaos: opdrachtgeverschap zal gedurende de looptijd van het project door verschillende (combinaties van) personen worden ingevuld

Persoonlijk had ik een andere keuze gemaakt met de positionering van opdrachtgeverschap waarbij ik de rol van opdrachtgever gedurende de looptijd van een project in principe bij één persoon houd. In het gecompliceerde domein passen aanpakken zoals PRINCE2 prima waarbij een stuurgroep uit opdrachtgever, sr gebruiker(s) en sr. Leverancier(s) bestaat. In het complexe domein kan je, je juist afvragen of een agile aanpak (experimenteren) met veel decentrale besluitvorming, dus kleine stuurgroep niet beter werkt. In het chaos domein zou ik nog steeds voor één opdrachtgever bijgestaan door anderen gaan, waarbij juist de opdrachtnemer in de tijd kan wisselen (eerst opdrachtnemer om de crisis te stoppen dan een andere opdrachtnemer om puin te ruimen en dan iemand om op te bouwen).

Het tweede gedeelte van het boek koppelt situationeel leiderschap van de opdrachtgever wederom aan de kwadranten van het Cynefin model.

  • Simpel: Delegeren
  • Gecompliceerd: hier passen we, in lijn met de situatie, de bijbehorende stijl van leiderschap toe
  • Complex: hier vragen we van de opdrachtgever om de vier verschillende leiderschap stijlen tegelijkertijd toe te passen
  • Chaos: hier stelt de auteur dat de assen van taakbekwaamheid en motivatie verder doorlopen

Ik vind de opsomming wat gezocht en snap de weergave van het model binnen chaos niet. M.i. kan je afhankelijk van de situatie aan de hand van het model van Hersey en Blanchard de bijbehorende leiderschapsstijl bepalen en naarmate het project complexer wordt zal je vaker binnen dat project als opdrachtgever een andere leiderschapsstijl moeten kiezen.

Kortom een mooie poging om opdrachtgeverschap en stijlen van leidinggeven te positioneren in het Cynefin model maar persoonlijk hecht ik meer waarde aan de wijze waarop besluitvorming tot stand komt binnen de vier kwadranten van het Cynefin model:

  • Simpel: waarnemen – categoriseren – reageren
  • Gecompliceerd: waarnemen – analyseren – reageren
  • Complex: uitproberen – waarnemen – reageren
  • Chaos: handelen – waarnemen – reageren

Neemt niet weg dat ik de Kennedy-reeks een mooi initiatief vind en ik hoop dat er nog vele interessante delen mogen verschijnen. Naar wat ik begrepen heb zullen mogelijke volgende publicaties ingaan op paradigma’s rond opdrachtgeverschap en talentontwikkeling bij opdrachtgevers.

Bestellen: Schaalsprongen in de opdracht

Advertisements

Recensie NR. 6 – 2019 Vakblad Projectmanagement

12985_vkbl_projectmng_6_cover_14Zojuist een sneak preview van het zesde nummer van het vakblad Projectmanagement van KWD Resultaatmanagement gehad. Je zal nog een paar weken moeten wachten voordat het in de bus ligt maar ook deze keer weer een ruim aanbod aan verschillende artikelen.

In het eerste artikel Psychologische valkuilen in grote IT-projecten belicht Arno Nuijten een viertal valkuilen die de projectmanager er toe kunnen zetten om risico’s te nemen: doelsubstitutie (Noot recensent: PRINCE2 was zo gek nog niet met haar principe continue zakelijke rechtvaardiging), zelfbevestiging, de meters op het dashboard sturen onze beslissingen (casino-gedrag, completion effect, noot recensent: ik noem dat het 90% syndroom. Het is bijna af en dat wordt week na week herhaald) en de laatste valkuil perceived control. Vervolgens wordt ingegaan op een onderzoek waarin een aantal hypothesen worden getest om te zien in hoeverre het uitmaakt of de waarschuwing wordt gegeven door iemand die gezien wordt als ‘partner’ of juist als tegenstander.

Het volgende artikel Samenhang in het bouwen is verdwenen, geschreven door Cok de Zwart gaat over zijn interview met architect Hans Ruijssenaars. Vroeger was je zowel architect als bouwmeester en dus ook projectmanager. Tegenwoordig worden alle rollen los van elkaar gecontracteerd en mag je als projectmanager dit alles aansturen zonder te beschikken over een samenhangende, vooraf overeengekomen visie.

Gerard Meijer, Kaj Wijnands en Peter Storm gaan in op de trends binnen en de impact op het vakgebied projectmanagement zoals die tijdens de 12e KWD Projectmanagement vakdag door deelnemers zijn besproken. In het artikel worden de 7 belangrijkste besproken met als top 3: verschuiving van waterval naar agile neemt verder toe, er zullen steeds meer mengvormen worden toegepast in de aanpak van projecten en als nummer 3 de business kant van projecten zal nog meer geïntegreerd worden met de IT-kant. Waarbij het artikel eindigt met een scenario waarbij AI de rol van de projectmanager overneemt.

In een volgend artikel, als eerste in een serie van vier, gaan Liesbeth Rijsdijk en Maike de Bot in op wicked vraagstukken die per definitie niet projectmatig kunnen worden aangepakt maar vragen om een multi-actor procesmanagementaanpak binnen een netwerksamenwerkingsstructuur. In dit artikel worden de kenmerken van wicked vraagstukken besproken en hoe deze kunnen variëren op de dimensies: grenzen overschrijdend, wederkerige afhankelijkheid, einddoel, invloed en context, informatie en belangen, maatschappelijke relevantie en benadering/aanpak. Middels het 4Emodel voor waarde creatie (Explore, Engaging, Elaboration, Evaluation) kan een overzicht gecreëerd worden van oorzaken, gevolgen, oplossingen, stakeholders, activiteiten en gecreëerde waarden.

In het artikel Integrated agile pleiten Saskia Giebels en George Miles voor een combinatie van nadenken vooraf en agile ontwikkelen. Beginnen met het vaststellen van een visie, vervolgens risico’s adresseren (technologie, financiën en businessmodel, kennis en middelen, stakeholders, propositie en wet en regelgeving) en daarna agile ontwikkelen. M.i. Gaan de auteurs soms wat kort door de bocht. Bij agile ontwikkeling hoort een product owner en de professionele product owner begint met een productvisie, verder is de voorgestelde combinatie precies wat we tegenkomen in methoden zoals PRINCE2 Agile en AgilePM.

Roeland Rustema gaat in zijn artikel Agile werken kan wringen in bestaande organisatie in op zijn onderzoek om de interactie tussen agile softwareontwikkeling en de organisatie daaromheen te begrijpen en wat een organisatie kan doen om agile softwareontwikkeling beter te faciliteren. De belangrijkste bevindingen zijn de besturing rond/boven het teamniveau, het begrijpen van agile en de tijd die een agile transitie kost.

Luuk Ketel en Peter Storm gaan opzoek naar de menselijke factor in risicomanagement in het gelijknamige artikel. Zij stellen dat risico’s niet in de technologie maar in menselijke en organisatorische zaken zitten, risico-inventarisaties met oogkleppen op worden uitgevoerd en teams leren te weinig. In projecten die ontsporen zien we dat meerdere vicieuze cirkels (van vertraging, van publiek schandaal) aan elkaar worden gekoppeld en elkaar versterken en het is dus zaak om aan de hand van systeem- en gedragsignalen dit vroegtijdig te onderkennen en daarop te acteren.

Uiteraard ontbreken de drie ‘projectfilosofen’ John Hermarij die de balans zoekt tussen ik en wij, Ben Berndt die het falend toezicht door Raden van Commissarissen aan de kaak stelt en Peter Storm die zich afvraagt of het nog wat wordt met de Chief Project Owner, niet?

Deze keer twee een boekrecensies. Een van Remmelt van der Wal over Projectstrategie, ritmes en routine en een van mijn hand over het boek Teams door het vuur en voorzien van een quick reference card.

Het vakblad biedt weer een veelheid aan verschillende artikelen. Als ik deze uitgave echter vergelijk met de eerdere nummers dan vind ik het praktisch toepasbare gehalte voor de projectmanager deze keer wat minder.

Geen abonnee maar wel belangstelling voor het blad, en ik kan het van harte aanbevelen, dan is het een kwestie van abonneren. Zie: KWD Resultaatmanagement.

Review: DevOps a business perspective

9789401803724-480x600Oleg Skrynnik wrote the book DevOps a business perspective. It’s the core literature for the EXIN DevOps Foundation certification and gives a good overview of DevOps.

Definition DevOps: “DevOps is an evolution of the ideas of agile software development and lean manufacturing, applied to the end-to-end value chain in IT, which allows businesses to achieve more with modern information technology due to cultural, organizational and technical changes

The book is built around 6 chapters. The first chapter explains DevOps in general. Next, we get key facts and challenges of lean production and agile as the foundation for DevOps. Followed by an explanation of the five DevOps principles.in a next chapter DevOps is compared with traditional practices and 10 DevOps practices are explained and ends with the practical application of DevOps.

The evolution of Agile software development methods created the need for a new approach to IT management. Management of IT infrastructure as a code enabled by virtualization and cloud computing provided the opportunity for the same new approach to IT management. This new approach was the inspired emergence of DevOps.

Why DevOps:

  • reduce time to market (business idea testing, hypothesis evaluation)
  • Reduce technical debt (the debt occurs when a programmer chooses a non-optimal way to solve a problem in order to shorten the development time)
  • Eliminate fragility (fragile systems first and foremost need stability, they need to be changed as little as possible, and changes should be carefully checked both before and after the intervention)

DevOps is based on five principles:

  • Value stream. Creating value in response to a customer’s request
  • Deployment pipeline. The most automated transition of changes through all steps of the value stream, starting from the Development is complete’ point, down to ‘Deployment into operations’ (including continuous integration, delivery and deployment)
  • Everything should be stored in a version control system: source code, tests, scripts, artifacts, libraries, documentation, configuration files, development tools
  • Automated configuration management. Any changes to any environment can be made only by scripts stored in a version control system
  • The Definition of Done. Creation of new functionality is done only when the application is running in the production environment and all the assembly, testing and deployment activities are done automatically.

Ten DevOps key practices:

  • Unusual teams: not a temporary construct, responsible for a small domain, full time, cross-functional, small, versatile professionals, self-organizing, collocated, responsible for the tool in use
  • Work visualization: helps to build a pull system, improves visibility of tasks in progress, remaining amount of work, prioritization, reduces the number of hand-offs and helps to identify inefficiencies
  • Limit the WIP: helps to build a pull system, improves estimating of the lead time, identification, visibility, evaluation and elimination of constraints, decreases specialists’ work interruptions and work re-scheduling
  • Reduce batch size: reduces total amount of work, lead time and number of defects, and improves the rhythm of the flow, the quality of the products
  • Mind the operational requirements: the product owner as interested in the fully operational IT system, including both functional and other (or operational) requirements
  • Early detection and correction of defects: testers develop tests and the test environments correspondent to the production environment as accurately as possible to support fast detection of defects
  • Managed, not controlled improvements and innovations: banning any normal work during the time allocated for improvement, Kaizen Blitz (with a very definite and tangible result), hackathons
  • Funding that enables innovations: funding of products rather than projects would be more appropriate, and this means a completely different way of budgeting and resource planning
  • Task prioritization based on cost of delay divided by duration
  • Continual identification, exploitation and elevation of constraints

The last chapter describes some practical applicability and limitations of DevOps, consequences when using COTS (Commercial Off-The-Shelf), an evolving architecture towards a microservice architecture, DevOps and ITSM, Cargo Cutting (thoughtless copying), start where you are, progress iteratively and use a value stream as the core for DevOps.

Conclusion: If you want to understand what DevOps really means, this is a good book to start your journey and bring it into practice.

To order: DevOps a business perspective

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

Review EBM Evidence-Based Management Guide

schermafdruk 2019-01-19 17.32.18The Evidence-Based Management Guide was developed by Ken Schwaber, Christina Schwaber, Scrum.org, the professional Scrum Trainer community and the Engagement Manager community.

EBM is an empirical approach that provides organizations with the ability to measure the value they deliver to customers and the means by which they deliver that value, and to use those measures to guide improvements in both.

EBM consists of four Key Value Areas (KVAs):

  • Current Value (CV): Reveals the value that the product delivers to customers, today
  • Time to Market (T2M): Expresses the organization’s ability to quickly deliver new capabilities, services, or products
  • Ability to Innovate (A2I): Expresses the ability of a product development organization to deliver new capabilities that might better meet customer needs
  • Unrealized Value (UV): Suggests the potential future value that could be realized if the organization could perfectly meet the needs of all potential customers

qrc (evidence-based management, 190119) v1.0To download: qrc (evidence-based management, 190119) v1.0

To produce genuine and long-lasting improvements the guide explains a five-step learning loop:

  1. Quantify Value
  2. Measure KVMs (Key Value Measure)
  3. Select KVAs to improve
  4. Conduct practice experiments to improve targeted KVAs
  5. Evaluate results

In the appendix an overview of KVMs, clustered by KVAs, and how to measure them.

Conclusion an easy to read guide to get a better understanding of business value, how to measure and how to improve it.

To download the guide (for free): Evidence-Based Management Guide

Recensie: Wendbare strategie op één A4

9789089654311-480x600Ondertussen zijn al vele canvassen verschenen. In het boek Wendbare strategie op één A4 beschrijft Sjors van Leeuwen het wendbaarheidscanvas.

Het wendbaarheidscanvas is een hulpmiddel, denkmodel en ‘praatplaat’ om het begrip wendbaarheid handen en voeten te geven. De auteur geeft aan dat er geen voorgeschreven volgorde tussen de 11 bouwstenen van het canvas is. Via de bouwstenen externe gerichtheid, rolling strategy, innovatie, merk en klant vindt de afstemming met de continu veranderende omgeving plaats. quote (wendbare strategie op a4)De bouwstenen kompas, scope en leiderschap zorgen voor een heldere koers en slagvaardigheid. De bouwstenen businessmodel, werkorganisatie en technologie vormen de ‘motor’ van de organisatie, die snel en flexibel aangepast moet kunnen worden. Per bouwsteen krijgen we een uitgebreide toelichting, verschillende binnen de bouwsteen passende technieken en voorbeelden uit de praktijk. Ieder bouwsteenhoofdstuk sluit af met een samenvatting en een set canvasvragen die je helpen om de discussie te voeren. Binnen deze 11 bouwstenen krijg je in totaal 43 wendbaarheidsknoppen op basis waarvan je meer of minder wendbaar kan zijn.

Het wendbaarheidscanvas;wendbaarheidscanvas

De 11 bouwstenen:

  • Kompas: Waar gaan we heen en wie gaat mee. Visie, ambitie, waarden en een goed verhaal
  • Scope: Hoe groot is de transformatie-opdracht. Wat betekent wendbaarheid voor onze organisatie. De breedte, diepte en toegevoegde waarde van meer wendbaarheid op organisatie, portfolio en/of operationeel niveau
  • Leiderschap: Goed voorbeeld doet volgen. Van functies naar rollen, sturen op strategische doelen, prioriteiten stellen
  • Externe gerichtheid: Wat gebeurt er om ons heen. Snelheid van signaleren (reactietijd), de snelheid van reageren en beslissen (actietijd) en de vertaling van signalen (ontwikkelingen en trends) naar bruikbare inzichten en initiatieven?
  • Rolling strategy: Flexibel inspelen op veranderingen. Je kijkt vijf tot tien à twintig jaar vooruit (visie en ambities) en redeneert terug naar nu (huidige situatie), vervolgens bepaal je wat je op de korte en langere termijn wilt bereiken
  • Innovatie: gericht verbeteren en vernieuwen. De keuze voor open en klant gedreven innovatie, het omgaan met verbetering (exploitatie) én vernieuwing (exploratie) en de keuze voor first mover of fast follower
  • Businessmodel: Van strategie naar praktijk. Het aanpassingsvermogen van het businessmodel kun je versterken met netwerkstructuren, modulaire processen en continu verbeteren, maar je moet daarbij wel in control blijven
  • Werkorganisatie: Bevlogen teamwork vormt de basis. Om snel te kunnen handelen worden taken, verantwoordelijkheden en bevoegdheden zo laag mogelijk in de organisatie belegd, en gedelegeerd naar resultaatgerichte en zelforganiserende eenheden die op een agile manier werken
  • Technologie: Design for agility. Een flexibele enterprise-architectuur met verschillende soorten businessapplicaties (backoffice-, frontoffice- en innovatieprocessen) en een plug-and-play infrastructuur op basis van standaardisatie, modularisatie en integratie
  • Merk & Klant: Win hart (emotie), hoofd (ratio) en routine (onbewuste). Hoe kan men verbeteren in love to buy, easy to remember en easy to buy)

Conclusie: Het boek maakt op een overzichtelijke wijze helder wat wendbaarheid inhoudt voor een organisatie en hoe je als organisatie meer wendbaar kan worden. De titel suggereert dat we op één A4 een wendbare strategie kunnen vastleggen en hanteert hiervoor het wendbaarheidscanvas. Het boek maakt dat wat mij betreft niet waar. Om het canvas te kunnen gebruiken had wat mij betreft de positionering van verschillende onderdelen op het canvas meer met elkaar in lijn gebracht of geclusterd kunnen worden. Ook had ik graag een paar ingevulde canvassen willen zien. Nu is het beschreven canvas niet meer dan opsomming van de 11 aandachtsgebieden en blijft onduidelijk wat er nu in het canvas ingevuld moet worden. Sterker nog, bij een aantal bouwstenen wordt weer verwezen naar werkwijzen waarbij een canvas, wederom omschreven als een hulpmiddel op één A4, voor die specifieke bouwsteen moet worden ingevuld (b.v. Waarde Propositie Canvas, Business Model Canvas).

Bestellen: Wendbare strategie op één A4

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, 190110) v1.1

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

Teamlevel

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.

 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.

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 business focus 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.1

[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