Tag Archives: Agile

Recensie Zet het op een bierviltje

9789089654779-480x600Michiel van der Molen heeft ondertussen een aantal boeken over o.a. business cases, batenmanagement en opdrachtgeverschap geschreven en vele organisaties geholpen met vraagstukken binnen deze onderwerpen. Ondertussen weet hij steeds helderder de essentie hiervan te benoemen en te beschrijven. Zie zijn laatste boekje Zet het op een bierviltje – Verandering vraagt om eenvoud waar dit alles tezamen komt.

Het boekje bestaat uit twee delen. In het eerste deel krijg je vijf manieren waarop je een bierviltje kan gebruiken om ieder type of soort project eenvoudiger te maken.

Het tweede deel gaat meer in detail in op deze vijf wegen naar eenvoud. Voor iedere weg krijgen we eerst een valkuil, inclusief voorbeelden, hoe we het onnodig ingewikkeld kunnen maken, vervolgens een toelichting op de te bewandelen weg naar eenvoud en aansluitend het voordeel dat het oplevert om het op een bierviltje samen te vatten. Iedere weg wordt tenslotte puntsgewijs kort samengevat.recensie bierviltje

De vijf wegen naar eenvoud:

  1. Ga terug naar het waarom. Wat we nodig hebben is een kort en krachtig antwoord op de waaromvraag (werkt verbindend en daardoor kom je makkelijker samen tot oplossingen en detailbeslissingen)
  2. Neem zorgen serieus. Zorgen delen geeft verbinding en realiteitszin (geef ruimte aan de schaduwkanten, maak een zorgen-top 3, zoek de eigenaar)
  3. Stel duidelijke prioriteiten. Prioriteiten stellen geeft focus en maakt decentrale besluitvorming mogelijk (maak duidelijk dat prioriteiten noodzakelijk zijn, prioriteiten vaststellen, prioriteiten benoemen)
  4. Creëer eigenaarschap. Wie is het meest verantwoordelijk voor het succes en hoe geef je de daarbij passende invloed (werk aan gezamelijke focus, geef de juiste mensen invloed)
  5. Blijf communiceren. Om een bijdrage te kunnen leveren, moeten mensen begrijpen wat de bedoeling is (het resultaat: wat kunnen we als het klaar is, het effect: datgene waar het uiteindelijk om begonnen is, het waarom: het hogere doel, het symbool: een krachtig beeld dat op het netvlies blijft staan)

Conclusie. Een prettig en vlot leesbaar boekje dat fraai is opgemaakt en dat de titel eer aan doet. Duidelijke handvatten en voorbeelden wijzen de weg naar de essentie. Persoonlijk ben ik het meest geportretteerd van de vijfde weg waarbij het resultaat, het effect en het waarom in tekst en gevisualiseerd middels een symbool op een bierviltje worden gezet. Dat maar veel projecten, traditioneel of agile, dit bierviltje mogen creëren!

Bestellen (managementboek.nl): Zet het op een bierviltje

Bestellen (bol.com): Zet het op een bierviltje

 

Review 97 Things Every Scrum Practitioner Should Know

9781492073840-480x600The 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”

My “Bird’s eye view in the agile forest” article translated in Russian

I am pleased to inform you that my featured paper “A bird’s eye view on the agile forest” has been translated and published in Russian by the Magazine of COBHET (SOVNET), the Russian Project Management Association, with the title “ОБЩЕЕ ПРЕДСТАВЛЕНИЕ О ГИБКИХ МЕТОДОЛОГИЯХ”. To download: https://grebennikon.ru/article-nzgp.html

The original paper, which is an extract of one of the chapters of my Book “Scaling Agile in organisaties (Dutch)”, has been published by PM World Journal, and it received the “2019 PM World Journal Editor’s Choice Award”. Have a look at the latest updated version of this article.

Agile PM2: a new tree in my agile forest

It looks like my forest is changing into a jungle. This time I added Agile PM2. Agile PM2 is an extension of PM(initiative of the European Union, see: https://www.pm2alliance.eu/forum/an-overview-of-agile-pm2/). To be honest I have some problems with this initiative. As a European citizen, I ask myself, looking at my agile forest, why do we need to spend tax money to develop a new (agile) methodology when there are already so many frameworks and methodologies available?

AgilePM2 overview plaatjeThe Agile PM² Extension

The PM² Methodology supports the use of Agile practices in PM² projects through Agile PM² which is an extension to the core methodology that provides the necessary collaboration framework. Agile teams should be able to collaborate effectively with teams and stakeholders following alternative approaches.

The extension provides:

  • Agile roles & responsibilities: The Agile Project Core Team (A-PCT) is part of the overall Project Core Team (PCT). In Agile PM, the additional agile specific roles comprising the Agile Project Core Team (A-PCT) are:
    • Team Coordinator (TeCo) – equivalent to the well-known Scrum Master role
    • Product Owner (PrOw)
    • Architecture Owner (ArOw)
    • Agile Team Member (ATeM) – equivalent to the Scrum Development Team role.
  • integration with the overall PM² project lifecycle: The Agile PM² has iteration cycles at three levels – daily cycles, iterations, and releases. Regardless of their duration, these cycles follow what is termed in Agile PM² the CIR rhythm (Coordinate, Implement, Review)
  • a set of suggested Agile artefacts: Agile Specific Artefacts capture information regarding the planning of specific (implementation) processes, activities, releases, iterations, and other milestones (Development Handbook, Development Work Plan, Deployment Plan, Testing Plan, Agile Logs (Testing Log, Retrospectives Log)
  • A set of Agile PM² Mindsets

In my bird’s eye view I positioned Agile PM2 in the project level box.Agile Myths Busted (webinar PMI Bulgaria, Belgium, IPMA NL, 200429) v1.0See my blog for the complete Bird’s eye view on the agile forest article.

Recensie Agile Design

9789492618375-480x600Een van de principes van het Agile Manifesto luidt: “The best architectures, requirements, and designs emerge from self-organizing teams”. Het bestaansrecht van een design wordt echter door veel organisaties in twijfel getrokken. Op het moment dat meerdere teams aan één product werken wordt het hebben van een globaal ontwerp al duidelijker maar ook indien in de ideale situatie slechts één autonoom team verantwoordelijk is voor een product of service is er nog steeds behoefte aan een design. Een design is essentieel voor het borgen van kennisoverdracht, ondersteuning van beheer en het nakomen van wet- en regelgeving. En dit is precies waar het in het boek Agile Design Best Practices – Een set van best practices voor een evolutionair design van informatiesystemen geschreven door Bart de Best over gaat.

In het boek staan twee aspecten centraal. Het veranderparadigma en de design pyramid.

Het veranderparadigma laat zien dat bij een verandering van werkwijze ook het delen van gemeenschappelijke uitgangspunten vereis is. Het is belangrijk dat er eerst een synchronisatie van denkbeelden plaatsvindt. Dit betreft zowel de denkbeelden van de business case (beeld), het eigenaarschap (macht), de werkwijze (organisatie) als de benodigde mensen en middelen (resources). De auteur projecteert dit op zowel een agile aanpak, een waterval aanpak alsmede op een uitgewerkte casus.

QRC (Agile Design, 200504) v1.0

Downloaden: QRC (Agile Design, 200504) v1.0

De design pyramid geeft een classificatie van onderdelen waaruit een design moet bestaan. De non agile design pyramid komt kort aan bod en de ideal design pyramid bestrijkt de hoofdmoot van het boek.

Een non agile design pyramid beschrijft de architectural, functional, technical, requirements, test en code view van een traditionele aanpak. Hierbij wordt in het voortraject de meeste tijd gestopt en naarmate je verder in de tijd bent wordt er steeds minder tijd gestopt in de volgende views en lopen de views vanuit de business (wat) naar de techniek (hoe). Deze pyramide wordt gevisualiseerd door een omgekeerde pyramide.

Het boek beschrijft in detail alle lagen van een ideal design pyramid waarbij de lagen wederom vanuit de business (wat) naar de techniek (hoe) lopen maar waarbij de inspanning omgekeerd is. Aan het begin minder inspanning en naarmate men verder in het project is steeds meer. De lagen en bijbehorende op te leveren producten, die ieder in een hoofdstuk aan bod komen, zijn:

  • Business view: system context diagram en value stream canvas
  • Solution view: use case diagram, system building blocks (Informatie, applicatie en technologie) en value stream mapping
  • Design view: use cases bestaande uit use case narrative en use case scenario
  • Requirements view: Behavior Driven Development (BDD) feature files (Given-When-Then format)
  • Test view: Test Driven Development (TDD) met testframework, testcases en testdatasets
  • Code view: code as documenten of documentation as code of continuous documentation.

In de bijlagen onder andere aan tabel van agile tools inclusief verwijzingen naar websites.

Conclusie. Het boek geeft veel praktische handvatten hoe een agile design vormgegeven kan worden. Als rode draad loopt het ontwerp van een koffiemachine door het boek. Bij iedere laag van de ideal design pyramid krijgen we de bijbehorende  ingevulde op te leveren producten. Verder per laag verschillende tips en trucks (trucs of tricks?).

Bestellen: Agile Design

Review: The art of business value

38907639._SY475_Mark Schwartz is the author of The art of business value. You could see this book as his quest to the concept of business value.

Is business value the same as customer value? The question of business value is the question of purpose, motivation, mission, and direction. It is a question of value and values.

In the first two chapters the author examines many different ways how known (agile) experts use or describe ROI, NPV, MVA, Profitability Index, IRR and payback period. All these measures are really just proxies for what the company ultimately values, like shareholder value, and they are unlikely to be useful to a product owner making feature trade-off decisions.

The author abandoned the idea that business value is a simple formula, known ahead of time and simply applied to user stories, and accept that business value requires interpretation and asks himself whether the model of a product owner (or business representative) doing all the interpretation continues to make sense. Many Scrum teams struggle with getting the product owner to prioritize non-functional requirements, such as security stories, work that reduces technical debt, alongside functional user- facing requirements. Following Eric Ries’ lean start-up approach, the product owner is no longer the interpreter of business value. Instead, value is discovered by the team that does validated learning experiments and hypothesis testing.

In a next chapter bureaucracy is put in the spotlights. Bureaucracy is all about rules and proving that they have been followed. Bureaucracy often leads to compliance requirements. But what if those requirements actually are adding business value?

Management, just as culture and bureaucracy are often viewed as impediments. Is the CIO responsible for executing projects, or responsible for delivering business value from IT investments? The CIO’s challenge is to show that IT is adding concrete business value to the organization. The IT organization must become an interpreter of business value as well as a provider of technical skills, and its interpretation must influence not only the behavior of project teams but also the enterprise’s business strategies.

The author finally gives his definition of business value: “Business value is a hypothesis held by the organization’s leadership as to what will best be accomplish the organization’s ultimate goals or desired outcomes”. He states that the agile team will be responsible as a whole for delivering business value.

The last chapter describes thought experiments to see if they influence the way you think about business value. E.g. adopting a DevOps culture and a Continuous Delivery pipeline or six ways to think about the CIO’s role.

Conclusion: The book The art of business value is not easy to read but after you have read it and executed one or more of the experiments, you have a much better idea how to cope with business value. And it gives valuable insights in the role of the product owner and the agile team too.

To order (Amazon): The art of business value

PMWJ article: Are incremental and iterative the same phenomenon or not?

Happy to see that the Project Management World Journal (PMWJ) published my article:

Portman, H. (2020).  Are incremental and iterative the same phenomenon or not? PM World Journal, Vol. IX, Issue IV, April.

During training classes I often notice that students mix the words iterative and incremental together. After reading this article I hope you understand the relationship between incremental and iterative development. I will start with a comparison of a waterfall and an agile approach by delivering a payment app. In the second part of this article, I position waterfall and agile in an incremental versus iterative matrix and shows what happens in the other two quadrants too. As a last step I elaborate on the minimum viable product (MVP) and the minimum marketable product (MMP) and shows where these fit in the different approaches and a story map.

To download the article: pmwj92-Apr2020-Portman-are-incremental-and-iterative-the-same

To support the article, I Created two mini webinars

Mini webinar: Waterfall versus agile delivery

Mini webinar: Incremental versus iterative

AGILE NXT 3rd edition

AgileNXT_Magazine_3In this third edition of AGILE NXT — a magazine designed by Xebia’s thought leaders and experts to inspire and inform you, offers 15 new insights:

  • The Ultimate Model for Managing Performance in Agile Environments (Daniel Burm). The Agile performance management model consists of five main building blocks: purpose, strategy and goals, whole system alignment, performance models and metrics, coordinated performance management routines and high-performance culture and behavior.
  • Schiphol’s Customer Value Takes Flight With A New Mindset (Esmé Valk and Ellen Barree). The program is all about changing mindsets and behaviors bottom up, without having a structural blueprint thought out in advance.
  • Stop Focusing on Agile & Start Adding Real Value (Kevin Bakker). In many organizations, Agile and Scrum have become container concepts—their true definition and purpose forgotten. So, it makes sense to regularly reflect with your whole team on the what and ways of working Agile. As an organization, keep asking, “what problem do we want to solve?” Does your approach add the most value, or are there other options?
  • Need Business Agility? Boost Your IT Capabilities (Bart Bouwers). 5 capabilities are explored: Build the Right Product, Continuous Delivery & Release on Demand, Detect & Recover Fast, Easy Infra & Containers, and Always Compliant & Always Secure.
  • Change the Way You Change – A result-Driven Growth Hack (Ron Meyer and Paul Immerzeel). Based on an agile transformation that is not yet showing results, the sponsor asks himself the following questions: What do I sense?, What do I feel?, What do I think?, What do I want?, and, What can I do about it?
  • Agile Doesn’t Create Future-Proof Organizations (Riët Broekhuizen and Ellen Barree). The 4th revolution requires radical innovation, where organizations experiment with new revenue models and structures, automate all repetitive actions, eliminate bureaucratic processes and employ the latest technologies in an open and transparent environment.
  • Digital Business: Make it Happen, and Make it Stick! Digital Success Requires a Healthy Dose of Common Sense (Edwin Oldenbeuving). There are seven skills for life and work in the 21st century: cooperation, communication, problem solving, self-reliance, creativity, critical thinking and social and cultural skills.
  • Portfolio Management – Through Different Glasses (Jarl Meijer). Five Tips to Reduce Portfolio Management Complexity are discussed: Nurture a culture of trust and transparency; Scale down to independent units of max. 125 people; Provide clear company-wide goals and priorities; Focus portfolio management sessions on strategic choices and solutions for impediments; Drive performance growth and predictability.
  • Cloud Migration Will Disrupt Ops as You Know It (Mark van Holsteijn). Three strategies for cloud migration and their effect on IT Operations are explained: rehost, redesign and re-platform.
  • Artificial Intelligence for Leadership decision-making (Rik de Groot). AI supports decision-making by: Analyzing the situation based on data, trends, historical information, and information from outside the organization; Giving leaders insights and options; Providing fact-based information; Looking at the big picture instead of local optimization.
  • You Can’t Escape Team Behavior (Anne Davidse and Marianne Pot). The escape room creates a bubble within which you can better understand team behavior. By analyzing how individuals’ function in a high-pressure team challenge, you can identify opportunities for improvement, spot natural leaders, and build trust.
  • Deep Democracy: Listening to the Wisdom of the Minority (Kenny Baas-Schwegler). Checking in, spreading perceptions (listen to all options, share other options and different viewpoints, and raise hands for recognition), deep democratic voting (majority vote is needed, sincere apology to those members who aren’t part of the majority, collect their arguments and vote again and repeat cycle if there is no full consensus), go fishing (make explicit agreements with each other, everyone says what they have to say), equality in differences (vote again).
  • Scoring an “A” for Agile in Architecture (Winfried Scheulderman). An overview of characteristics of a modern IT architecture process and six considerations to take into account if you want to introduce modern architecture.
  • The Agility Gap: What’s Really Behind It? (Daria Nozhkina). When an organization primarily focuses on its financial priorities, it directly impacts its approach to Agile transformation, which, in turn, influences the transformation’s success.
  • Common Sense Scaling: The 10 Do’s and Don’ts for Delivering Value with Multiple Teams (Evelien Acun-Roos). Start small, involve, change habits and behavior, measure and seek knowledge and experience.

Conclusion: a mix of articles. Some articles are too short to make a difference. Other articles definitely offer new insights. In total it’s definitely worthwhile to download and read the magazine.

To download: www.agilenxt.com

 

Scaling agile in organisaties

9789401806213-480x600Ondertussen is de tweede geheel herziene druk van mijn boek Scaling agile in organisaties verschenen. Sprak ik in de eerste druk over ruim 30 agile frameworks of aanpakken, in deze druk passeren 70 agile frameworks of aanpakken de revue. Het boek beval de meest recente versie van mijn bird’s eye view on thew agile forest en neem ik de lezers mee wat het betekent voor organisaties als ze doorgroeien van een enkel permanent agile team naar vele agile teams. Daarbij ga ik ook in op de vraag wat dit betekent voor de rol van projectmanager, PMO en portfoliobureau. Uiteraard zijn de hoofdstukken die gewijd zijn aan SAFe (nu versie 5.0), LeSS, Nexus, Scrum @ Scale, spotify, AgilePM en PRINCE2 Agile gebleven. Er zijn echter nieuwe hoofdstukken bijgekomen met daarin uitgebreide beschrijvingen van Disciplined Agile (ondertussen overgenomen door PMI), AgileSHIFT en bimodal portfoliomanagement. Daarnaast van vele agile aanpakken korte beschrijvingen. Ten opzichte van de eerste druk komen er nu verschillende frameworks aan bod die helpen bij het creëren van een agile cultuur of mindset zoals AgileSHIFT, Open Space Agility en Agile Fluency. Ik wens jullie veel leesplezier en mocht de behoefte er zijn dan ben ik gaarne bereid om in een sessie van een uur of langer uitgebreid in te gaan op de inhoud van het boek en jullie een overzicht te geven wat er zoal speelt in het agile landschap.

Bestellen: Scaling agile in organisaties

Are incremental and iterative the same phenomenon or not? (part 2)

webinarIn the first part of this article (see previous post) I compared a waterfall and an agile approach when creating a payment app. In this second part of the article, I position waterfall and agile in an incremental versus iterative matrix and shows what happens in the other two quadrants too. As a last step I elaborate on the minimum viable product (MVP) and the minimum marketable product (MMP) and shows where these fit in the different approaches and a story map. At the end you will find the corresponding mini webinar.

As stated, I noticed that students often mix the words iterative and incremental together. In figure 4 you can find four quadrants as a result of a horizontal line presenting incremental or not and a crossing vertical line representing iterative or not[1].

In the left lower corner, we see the approach where there are no iterations and no increments. This is the waterfall approach. All activities (design, analysis, build, test and deploy) are performed once for the entire project. In this case we see a single delivery of the final product based on a fixed scope. Customer value can only be achieved after the delivery of the final product. One of the key goals in this approach is to manage cost. See also the waterfall approach to develop the payment app in the first part of the article.

In the lower right quadrant, we see an incremental approach without iterations. This is a staged or incremental delivery of smaller parts the product. All activities for a given stage (design, analysis, build, test and deploy) are performed once. Within a given stage the scope is fixed, but the total product is based on a more dynamic or flexible scope. Customer value can be achieved after every delivery of the product. One of the key goals in this approach is speed of delivery.

Dia8Figure 4: Iterative versus incremental

In the left upper quadrant, we see a spiral or iterative approach without increments. This is a single delivery where the final product is created by using several iterations. A good example of this approach is design thinking. In the graph you see a sequence of the activities framing, analysis, idea generation, realization and reflection. This sequence will be performed repeatedly or iteratively where in every iteration you get closer to the final, correct or required, product. In many cases this final product is a prototype or model. In this spiral approach we have a dynamic or flexible scope. Customer value can only be achieved after the delivery of the final product. One of the key goals in this approach is the correctness of the solution.

In the upper right quadrant, we see the agile approach with increments and iterations. Scrum is a good example[2] of this approach. At the end of each increment, often called a sprint or timebox there is a delivery of an increment of the product. This increment is the result of many iterations to develop small but correct parts, often called user stories or backlog items, of the product. The final product will be delivered piece by piece. In this agile approach we have a dynamic or flexible scope. Customer value can be achieved after every delivery of the product. One of the key goals in this approach is customer value via frequent deliveries and customer feedback. See also the agile approach to develop the payment app in the first part of the article.

MVP or MMP?

In figure 4 you can also find the acronyms MVP and MMP. MVP stands for minimum viable product (Eric Ries, Lean Startup) and is a version of a new product or service which

allows a team to collect the maximum amount of validated learning about customers with the least effort. The MVP for the Dropbox service was a simple movie. This means that the P in MVP could be a completely different product in comparison with the final product.

I often use the following example of a new financial product. An enthusiastic sales manager has a great idea regarding a new financial product. He thinks that they can sell at least 100.000 of these products. Together with some finance experts, they design the product in a couple of months. A development team is assigned, and it takes them 4 months to develop the product. In parallel commercial brochures are developed and the product is launched with a big event. Unfortunately, just a few people buy the product. If we follow Eric Ries’ approach we could make the assumption that 10% of their web users are interested in this product. To test this hypothesis, they develop a MVP. In this case a simple button on the homepage. If you click you get a screen with a message regarding this new product and the question to leave your mail address behind if you are interested. Less than 1% of the visitors pressed the button. The product will not be developed. They saved a lot of scarce resources.

If we take a closer look at figure 4, we see the potential usage of MVP’s in all quadrants. When using a waterfall approach, you could create a MVP in the first design phase to check if there is a business justification for the project. The same can be done in the first phase of the first increment when following a staged delivery. In some cases, the result of your spiral, or design thinking approach could be a MVP. At the beginning of an agile approach the MVP could be beneficial too.

Many people see the first product delivered at the end of your staged delivery as the MVP. This could be the case but, in most cases, this is not a MVP but a MMP. MMP or minimum marketable product is the smallest product that can bring value to your customer. See the staged delivery or agile approach where a MMP could be deployed.

How does an agile delivery looks like?

Now it is clear that incremental and iterative are not the same and we understand the usage of MVP and MMP, we can explore in more detail how an incremental and iterative delivery could look like. You probably have seen Jeff Patton’s famous example of the Mona Lisa where the painting is created piece by piece (staged delivery) or in the first increment only a rough sketch and every new iteration more details are added to the sketch and ultimately you have the final painting (incremental and iterative or agile delivery). In the first situation you must already have a detailed idea of the final product and in the second situation you just need a high-level outline and changes are much easier to make. If we look at figure 5, we see a story map for a new product called ABC.

Dia9Figure 5: Story map for product ABC

The product owner envisioned seven features for this product. The first four features are must haves. Feature 5 and 6 are should haves and the last feature is a could have. Many would call this MoSCoW prioritization (Must haves, Should haves, Could haves and Won’t haves). Every feature in itself can be sliced down in smaller parts. In the figure you see features with must, should and could have user stories. A feature can be a must have but that doesn’t mean that all the underlying user stories are must haves too. Or a feature can be a should have but if you implement that feature some user stories are must haves and others are should or could haves.

To implement this ABC product, you see five increments or releases. The first one is the minimum marketable product. This MMP consists of the first two must have user stories of feature 1, and the first must have user stories of feature 2 and 3. Release 2 contains the next two must have user stories of feature 1, 2 and 3 (iterative development). Product development continues by implementing the next releases. With every release the customer value increases. After release 5 the product owner stops implementing user stories. Feedback from the customer showed him that the ABC product is ‘fit for purpose’ and he takes the Agile manifesto’s principle Simplicity – the art of maximizing the amount of work notdone – is essential, into account and stops further development.

Mini webinar Incremental versus iterative

[1] See YouTube for a very simple version of this figure: https://www.youtube.com/watch?v=20SdEYJEbrE&t=31s

[2] See my article with more than 70 agile frameworks or approaches: Portman, H. (2019). A bird’s eye view on the agile forest; PM World Journal, Vol. VIII, Issue X, November.