The 2020 Scrum Guide launch

Yesterday, November 18th, there was a 3-hour virtual event to celebrate the launch of the 2020 Scrum Guide with nearly 20,000 registrants. I connected 15 minutes before the start but received a message that the limit of 1000 participants was reached, and I couldn’t participate. Luckily the event was streamed, and you can now watch it on demand (see below). Can you imagine It’s been 25 years since the launch of the first Scrum Guide?

The guide is now crisper, leaner (only 13 pages), more transparent and even less prescriptive. The concept of a separate development team within the team is now eliminated. Just the self-managing Scrum team with three sets of accountabilities (PO, SM, and Developers). Each of the three artifacts now contain ‘commitments’ to them. For the Product Backlog it is the Product Goal, the Sprint Backlog has the Sprint Goal to be defined during the Sprint Planning when discussing the “Why”, and the Increment has the Definition of Done. They exist to bring transparency and focus on the progress of each artifact.

A pity the guide only contains plain text. I think some pictures could add value too. On the other hand, other organizations, e.g., Scaled Agile could take an example to bring back the framework to being a minimally sufficient framework. With every new release of SAFe, the framework is growing without any removements, and as a consequence making it more complicated.

To download the 2020 Scrum Guide

To watch the event

Review 97 Things Every Scrum Practitioner Should Know

The book 97 Things Every Scrum Practitioner Should Know edited by Gunther Verheyen contains the wisdom of 69 practitioners around the world and helps you to improve your understanding of Scrum (nb. Who are we missing on the cover of the book?).

Gunther organized these 97 essays around ten themes. These themes cover all aspects of Scrum and beyond. The events, the different roles, their behavior, the skills, collaboration and the artifacts. The book ends with a simple Scrum glossary. To summarize, some topics that are discussed in the ten themes:

• Start, adopt, repeat. This first theme gives you insights what it means when you start using Scrum. Use it, as it is or adapt? Why using Scrum? Are multiple Scrum teams the same as Multi-team Scrum? And many more.
• Products deliver value. What are your products? How is this reflected in your backlog? What do we mean by value? Who’s value? And what does this mean for the product owner?
• Collaboration is key. Collaboration, communication and interaction between whom? With the customer, within the team? Are you just following your job description or not? Are tools considered harmful?
• Development is multifaceted work. What are you developing? What’s on your product and sprint backlog? How to size your PBI’s? What do we mean with backlog items, user stories, abuser stories, bugs?
• Events, not meetings. Here we get several ideas how to make the events work and effective. The impact of sprint goals, who plays which role during the events and what are these events not.
• Mastery does matter. Here we get the spotlights on the Scrum master. The Scrum master as servant leader, court jester, (technical) coach, or is he just an impediment hunter?
• People, all too human. Teams are more than collections of technical skills. Are people impediments? Can Scrum masters replace team members?
• Values drive behavior. Scrum is more about behavior than it is about process. What is self-organization? How to be a more humane Scrum master and an essay on the sixth Scrum value.
• Organizational design. It’s all about agile leadership, culture, improving the organization, the importance of networks, respect and a save environment.
• Scrum off script. Probably you think you know the origins of Scrum, but it might not be what you think they are. Here we also get some examples of Scrum outside software development, e.g. at the police, in the classroom, in education.

Conclusion. This book is definitely food for thought for Scrum practitioners. Sometimes you get different views or opinions e.g. on backlog items and user stories but that’s also the beauty. It’s not carved in stone. When using Scrum, you have to think, rethink, discover and adapt. And don’t forget it’s all about people! A must read!

Throughout the book you get many references to articles, et cetera on the web. It would help the reader if small QR codes were added to the text (I often make mistakes by reading/typing a I, i, L or l).

In the book there is a reference to the Flow framework. In a next blog I will dive into this framework to see where it fits in my Bird’s eye view on the agile forest.

To order (managementboek.nl) : 97 Things Every Scrum Practitioner Should Know

To order (Amazon.com): 97 Things Every Scrum Practitioner Should Know

To order (Bol.com): 97 Things Every Scrum Practitioner Should Know

Youtube: Gunther Verheyen answers questions about “97 Things Every Scrum Practitioner Should Know”

The SCRUM Fieldbook

J.J. Sutherland wrote The SCRUM Fieldbook – A master Class on Accelerating Performance, Getting Results, and Defining the Future. I would say a virtual master class build around a backlog of approximately 40 items and clustered in 10 groups. Every chapter is dedicated to one group.

The first clusters of backlog items are related to the Agile Manifesto and the usage of Scrum itself. Important but the information can be found in other books too. The other clusters will move you into the master class. Have a look at some examples from the book related to specific backlog items:

• Decision latency as a result of a study from The Standish Group. How much time is wasted waiting for a decision to be made? Measure your meetings. More than 40% of decisions made in meetings are overturned. Think about the last time you or your organization faced a crisis. Could you have acted more quickly? How could you change your decision-making process next time?
• Too much structure, too much processes will have a negative impact on agility. If you have just enough structure to ride the edge of chaos, that’s where interesting things happen. Creativity blossoms and can be channeled. Ideas are generated and applied. There is freedom of expression but also some controls in place to focus.
• A structural reorganization emerged as the goal shifted from output (making sure everybody was busy) to outcome (getting to done).
• Know the power of no. Choices have to be made.
• Find your ba. It’s a shared space between individuals that is the foundation for knowledge creation. When you are in a partnership or participating on a team or teams aligned on a single goal, you create something larger than the sum of the parts.
• Your structure is your culture. And your culture is your limits. A rigid structure begets a rigid cultural and product architecture.
• You need to create an environment that ensures the Scrum values are present. This is when you strike out at the bureaucracy that slows things down and frustrates everyone. But what structure should you have? Where do you begin? For the most part you do need some hierarchy, because you don’t want chaos, but you want just enough hierarchy – the minimal viable bureaucracy.
• Once you reshape your structure, a new culture emerges. Organizations, families, people are all complex adaptive systems.
• Focus maximum team effort on one item in the product backlog and get it done as soon as possible (swarming).
• Watch out for anti-patterns. The problem with à la carte Scrum. Use data for decisions, not opinions. Don’t outsource competence. If you outsource how to do it, you don’t internalize the knowledge. Remove them one by one.

Conclusion. A book about the world behind Scrum. It will help to expand your knowledge how to use Scrum to accelerate performance and getting things done. You got a lot of examples using Scrum in and outside IT. Definitely worth reading.

To buy: The SCRUM Fieldbook

 

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

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

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

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

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

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

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

 

Review: The Professional Product Owner

Don 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 adaptation. The authors explain why the world of product management is a lot bigger 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 get 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.

To 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

Recensie: Het Scrum modellenboek – 41 slimme tools & tips voor een betere én leukere sprint

Rik van der Wardt heeft Het Scrum modellenboek – 41 slimme tools & tips voor een betere én leukere sprint geschreven waarmee beginnende Scrum teams een aantal praktische handvatten krijgen.

Zoals uit de titel al blijkt biedt het boek 41 modellen. Van ieder model krijgen we het doel uitgelegd, waarvoor het model gebruikt kan worden (in de vorm van een of meer user stries met Als … Wil ik … Zodat …), uitleg bij het model, vaak een verwijzing om verder te lezen en afhankelijk van het model een praktijkvoorbeeld of een oefening.

Het boek begint met een aantal algemene modellen zoals de waarde proposities van Scrum, het agile manifest, je strategie scrummen, alignment en autonomie. Verderop in het boek nog een aantal algemene modellen waaronder het Cynefin-model, organiseren voor intrinsieke motivatie, hoe ontstaat vertrouwen, management 3.0, Scrum opschalen met Nexus, PDCA als basis voor kwaliteit, het progressieprincipe in Scrum, Theorie X en Y en waarom starten we met Scrum.

Voor de product owner draagt de auteur de volgende modellen aan: planning in Scrum, DEEP product backlog-management, persona’s, productvisie en user stories: de 3 C’s en INVEST. Ook de scrum master kan putten uit een aantal modellen zoals het belang van feedback, GROW-coaching, leerstijlen van Kolb, uitdagingen in teamwork volgens Lencioni, rekentool voor de duur van Scrum meetings, situationeel leiderschap, SOAR (strengths, opportunities, aspirations, results), state of mind model, groepsinterventies en hoe ontwikkelt een Scrum team zich. Als lid van een ontwikkelteam kan je kijken naar de modellen teamrollen volgens Belbin, flow-ervaring en T-shaped mensen. Stakeholdermanagement wordt gerubriceerd onder stakeholders.

Het boek biedt bruikbare praktische checklists voor de sprint planning, de daily Scrum, de sprint review en de sprint retrospective. Daarnaast ter ondersteuning van de sprint planning het plannen in Scrum. Tenslotte een aantal modellen om de kwaliteit van de sprint retrospective te verhogen waaronder het Johari-venster, Karasek (waarom Scrum uitdagend en motiverend is), reflexiviteit van het team en het Scrumteam zelfassessment.

Conclusie: Een veelheid aan modellen waarbij de meeste modellen praktisch en direct toepasbaar zijn voor een beginnend Scrum team. Op de achterflap wordt gesproken van een complete verzameling van Scrum modellen en tips en trucs. Persoonlijk had ik ook aandacht besteed aan het ‘nee’ zeggen door de product owner, het slicen of opdelen in kleinere user stories en wellicht een hoofdstuk over flow, pull en velocity in het ontwikkelteam. Wellicht hadden een paar modellen die als algemeen worden aangeduid dan achterwege gelaten kunnen worden omdat hier een beginnend Scrum team nog niet op zit te wachten. Bijvoorbeeld je strategie scrummen, het Cynefin-model of Nexus.

Ik heb niet kunnen ontdekken of er een logische volgorde in de hoofdstukken zit en dat doet me denken aan de Argentijnse schrijver Julio Cortázar. Hij heeft o.a. het boek Rayuela, een hinkelspel geschreven. Dit boek kan van kaft tot kaft gelezen worden maar de hoofdstukken kunnen ook kriskras door elkaar gelezen worden waarbij aan het eind van ieder hoofdstuk een verwijzing staat naar het volgende te lezen hoofdstuk. In het Scrum modellenboek geeft de auteur aan dat de meeste mensen dit boek per rol of per meeting gebruiken om te zien welke modellen toepasbaar zijn. Als je dit als auteur uitspreekt dan is het geboden plaatje in de inleiding m.i. onvoldoende. Ik heb een leeswijzer toegevoegd waarmee het voor de lezer makkelijker wordt om te kiezen waarbij de insteek algemeen, je rol (PO, SM, Ontwikkelteam) of wanneer (sprint planning, daily Scrum, Sprint review, sprint retrospective, refinement). Een model kan dan op meerdere plekken bruikbaar zijn (zowel binnen een rol als bij een meeting). De ingekleurde velden geven de keuze van de auteur weer, de X’en op een niet ingekleurd veld betreffen mijn eigen mening.

Bestellen: Het Scrum modellenboek

Downloaden: Het Scrum Modellenboek (cross reference tabel, 181215) v1.0

Recensie: agile werken in 60 minuten

Zojuist het boekje agile werken in 60 minuten van Rob van Lanen en Rini van Solingen in een klein uurtje uitgelezen.

In dit boekje nemen de schrijvers je mee in de wereld van agile. Als je kleine stapjes zet en al doende leert kun je veel sneller resultaat boeken en eerder inspelen op veranderingen. Maar om agile te kunnen werken zal je moeten samenwerken en zal je anders moeten denken.

In het eerste gedeelte van het boekje geven de auteurs uitleg over het waarom van agile en wat agile werken inhoudt zonder daarbij direct in de terminologie van bijvoorbeeld Scrum te belanden. Uiteraard krijgen we ook uitleg over het Agile Manifesto en de agile mindset.

Scrum komt vervolgens aan bod waarbij alle rollen, de artifacts en de gebeurtenissen worden toegelicht. Een paragraaf over de Scrum waarden ontbreekt en dat had m.i. toch wel op zijn plaats geweest.

Daarnaast krijgen we ook een korte toelichting op Kanban en Lean. Dit stuk wordt afgesloten met het op grotere schaal toepassen van agile. Hoe laat je teams met elkaar samenwerken aan een en het zelfde product en welke frameworks ondersteunen dit?

De schrijvers spreken zich vervolgens uit wanneer je nu wel of niet met agile aan de gang moet gaan. Niet alles leent zich voor agile werken. Als helder is wat er gedaan moet worden ga je dan al experimenterend op onderzoek uit of volg je gewoon een stappenplan? Hoe gecompliceerder hoe meer je van agile werken de vruchten kan plukken.

In de laatste twee hoofdstukken krijgen we enerzijds een zevenstappenplan om te starten met agile werken (“agile werken leer je vooral door het te doen”) en anderzijds een verfrissend hoofdstuk over hoe je zelf agile kan worden. Persoonlijk wendbaar zijn door je eigen handelen in lijn met het Agile Manifesto te brengen.

Kortom een handig boekje als je nog niets van agile weet en je niet te veel tijd kan besteden aan het lezen van meer uitgebreidere boeken over agile of Scrum.

Bestellen: agile werken in 60 minuten

Review: The Kanban Guide for Scrum Teams

Daniel Vacaniti and Scrum.org developed The Kanban Guide for Scrum teams.

In this guide we get an explanation how Kanban can help the Scrum team by visualizing work, using lean thinking, product development flow and queuing theory to optimize the flow. Combining Scrum and Kanban is nothing new, we find this for example in SAFe too.

We get a definition of workflow to understand what flow means in a Scrum context. Furthermore the following Kanban practices, used to optimize flow, are explained:

• Visualization of the workflow – the Kanban Board
• Limiting WIP – uses a pull system to improve workflow by creating focus, commitment and collaboration
• Active management of work items in progress – responding to blocked worked items, incoming – out coming rates, completed according to expectations, unclogging work
• Inspecting and adapting their definition of ‘workflow’ – explicit policies for its process

Using Kanban requires analysis of flow metrics. The following four basic metrics of flow should be tracked:

• WIP: number of work items started but not yet finished
• Cycle time: elapsed time when a work item “started” and when “finished”
• Work Item Age: elapsed time when a work item “started” and the current time
• Throughput: number of work items finished per unit of time

Not mentioned but a Cumulative flow Diagram (CFD) is a great help when analyzing these flow metrics.

The final part explains the usage of a flow-based perspective in the existing Scrum events making them flow-based by using the metrics of flow.

Conclusion. A simple and easy to read guide to get a better understanding of the added value of using Kanban by your Scrum Teams.

To download: The Kanban Guide for Scrum Teams

2017 Scrum guide revision

Yesterday (November 7) Ken Schwaber and Jeff Sutherland presented the Scrum Guide revision.

They started with a brief history of Scrum and explained the essence of Scrum followed by the main part of this webinar. The Scrum Guide 2017 is updated on responses to input from Scrum users.

The following topics were discussed:

• Uses of Scrum (beyond IT)
• Refined the role of the Scrum Master (promoting and supporting Scrum by helping everyone understand Scrum theory, practices, rules, and values, within the culture of the organization)
• Daily Scrum is for inspection and adaption to ensure progress towards the sprint goal (how can we move the backlog to done?)
• Time-boxes cary a maximum length (the words “at most” are added)
• Sprint Backlog includes feedback from the sprint retrospective. To ensure continuous improvement, the sprint backlog must contain at least one high priority process improvement identified in the previous retrospective meeting).

In the last part of the session some common misconceptions were addressed:

• Is Scrum only relevant to software delivery? No
• Can I release before the end of the sprint? Yes
• What about DevOps? Already after the first sprints you have to prove the product is viable and will produce value. This asks for an operational environment.

To download the new Scrum guide: www.scrumguides.org

To watch the video of the Scrum Guide Revision Webinar: video of the Scrum Guide Revision Webinar, where you can download the used presentation too.

 

Sent from my iPad

Boek launch: Scaling agile in organisaties – Wegwijzer voor projectmanagers en agile leads

Tijdens het 20ste BPUG seminar vond ook de launch van mijn nieuwe boek plaats. Altijd leuk zo’n mijlpaal en ondertussen al vele enthousiaste reacties ontvangen. Ook hebben wij, Bert Hedeman, Hajati Wieferink en ik van de gelegenheid gebruik gemaakt om de nieuwe naam van onze organisatie wereldkundig te maken. Het is geen Hedeman Consulting meer maar HWP Consulting om daarmee de complementaire kennis en ervaringen van ons drieën te benadrukken.

Boek preview

Scaling agile in organisaties gaat over organisaties die stappen willen zetten om teams meer autonomie te geven door besluitvorming decentraal neer te leggen en managementlagen en managers weg te halen om de teams zelforganiserend te laten optreden.

Business agility (oftewel de vraag: hoe wendbaar is je organisatie) is meer en meer onlosmakelijk verbonden met het bestaansrecht van organisaties. Het snel en accuraat kunnen inspelen op consument- of klantbehoeftes is van levensbelang. Iteratief en incrementeel ontwikkelen biedt betere oplossingen en waarborgen om producten fit-for-purpose te laten aansluiten bij de eisen van klanten; beter dan een watervalaanpak waarbij alle eisen al aan de start gedefinieerd worden en gedurende het ontwikkelproces in principe bevroren blijven.

Vele organisaties hebben stappen gezet om teams meer autonomie te geven door besluitvorming te decentraliseren. Ze hebben managementlagen en managers weggehaald om de teams zelforganiserend te laten optreden. In dit eerste deel komen enkele agile aanpakken van het eerste uur aan bod. Dit betreft agile aanpakken op teamniveau. Daarnaast beschrijf ik wat het betekent als er meerdere teams met elkaar moeten samenwerken.

Kijkend naar zo’n agile team, werkend met Scrum (met voorgeschreven rollen) of Kanban (zonder voorgeschreven rollen), komen de vragen op of er in zo’n constructie met een ontwikkelteam en Product Owner (typische Scrum-rol) nog wel sprake is van een project en of er dus nog wel plaats is voor een projectmanager. Een project is een tijdelijke multifunctionele organisatie, werkend met een start- en einddatum, opgezet om een uniek product of unieke dienst of release van een product of dienst op te leveren, rekening houdend met onzekerheid en onderbouwd door een businesscase, waarbij de juiste mensen voor het projectteam worden gezocht. Er zijn ondertussen verschillende cases bekend van organisaties die alle project- en programmamanagers hebben laten afvloeien en hiervoor in de plaats zijn gaan werken met Product Owners en Scrum Masters.

Zelf ben ik van mening dat het compleet afbouwen van alle project- en programmamanagers een brug te ver is. Wel geloof ik dat het aantal project- en programmamanagers bij veel organisaties sterk kan afnemen, maar er zullen situaties zijn waar toch een beroep op project- en/of programmamanagers gedaan moet worden. Wellicht worden ze dan anders genoemd, maar de rolinvulling zal veel gelijkenis vertonen met die van de project- of programmamanager. Ondertussen word ik gesterkt in dit idee door het feit dat ik organisaties in Nederland toch weer project- en/of programmamanagers zie aantrekken. Hierbij moet ik wel de kanttekening maken dat de opnieuw aangetrokken of overgebleven project- en programmamanagers veel vaker op de relatie zitten (stakeholdermanagement) en dat ze om zaken voor elkaar te krijgen invloed moeten uitoefenen zonder macht te kunnen hanteren.

Dit boek kan dus ook gebruikt worden door meer traditionele projectmanagers die zich een beeld willen vormen wat business agility gaat betekenen voor hun eigen rol. Blijven er traditionele of hybride projecten bestaan (projecten waarbij gebruikgemaakt wordt van zowel tijdelijke als permanente ontwikkelteams en waarbinnen gebruikgemaakt wordt van zowel agile als meer traditionele aanpakken) waarbinnen zij een projectmanagerrol kunnen blijven vervullen? Of is het zinvol dat zij zich binnen de lijnorganisatie meer gaan ontwikkelen in de richting van portfoliomanager, Agile Leader, Integration Manager, Roadmap Manager of Roadmanager, Release Train Engineer, Scrum Master, Agile Coach of Product Owner?

Ik ga in op verschillende agile frameworks die het op organisatiebrede schaal agile gaan werken ondersteunen. Ik schets eerst een handvat om de verschillende agile aanpakken mee te positioneren en vervolgens ga ik in detail in op een aantal van de meest gebruikte frameworks en geef ik een korte introductie van enkele minder gebruikte en minder bekende frameworks.

Ten slotte vergelijk ik verschillende frameworks en sluit ik af met een aantal, soms aan een specifiek framework gerelateerde, aanpakken om een agile framework te implementeren. Verder krijgt u mogelijke valkuilen waar u bij het implementeren van een agile aanpak rekening mee moet houden en antipatronen waar u tegenaan kunt lopen bij het gebruik van een agile framework.

Bestellen (Managementboek): Scaling agile in organisaties

Bestellen (bol.com): Scaling Agile in organisaties