Tag Archives: Agile

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.


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.


White paper: Exploring the delta in AgileSHIFT

Schermafdruk 2020-03-18 10.29.34Happy to see that my white paper Exploring the delta in AgileSHIFT is now live on the AXELOS content hub.

Enterprise agility is key. It is not just about implementing an agile way of working in your IT department but a transformation for your whole organization. You have to understand where the market is going, where your competitors are moving, where your customers want to be, and, as a result, where your organization needs to be. One technique to understand this is the concept of the delta. The difference between where the organization wants to be, expressed as ‘what great looks like’, and where it currently is.

This paper explores the concept of the delta, explaining how this is addressed in AgileSHIFT®, and providing practical recommendations and examples on the subject. It is aimed at senior managers, portfolio officers and transition directors who are overseeing fast-moving environments and are running the risk of competitors or disruptors taking over their organization’s market share.

AgileSHIFT helps prepare individuals and organizations for transformational shift by creating a culture of enterprise agility. This cultural change is not driven by simply adopting an agile framework, method or tool, but by understanding and distilling the ethos behind agile ways of working and leveraging them across the entire organization.

A key theme within AgileSHIFT is the delta and the importance to narrow your company’s delta. The delta is the difference between where an organization wants to be and where it currently is. This could be measured in terms of capability, performance, or value delivered. The larger the delta, the greater the vulnerability of the organization to competitors and disruptors. Unfortunately, the delta is not static, so it will grow again. Narrowing the delta will be an ongoing process and you must keep changing to manage the delta, otherwise competitors will be ahead of you and take it all.

In the article I explore what it means where you want to be. This is what you could call ‘great’ and this could relate to your products, services, technology, processes et cetera. I explain that this could be related to the technology. Can you expect a (digital) tech-shift in your company’s work (tech-supported, tech-enabled or tech-centric)? If the delta is large your company is at risk and vulnerable to other competitors who could destroy your own business. What would be the impact of disruptors or exponential organizations on your own business? Will you survive?

I make use of some scenario’s like a dentist practice and a Cyclecity bike shop to explain the concept of the delta and how you could narrow the delta by closing the existing gap. For the Cyclecity bike shop I use a business model canvas to explain the as-is and the to-be situations. I use the GDS/IPS’s 7 lenses of transformation (vision, design, plan, transformational leadership, collaboration, accountability and people) to give a first, but incomplete, impression of how the transformation programme to bridge the gap between the as-is and the to-be could be outlined.

I hope this white paper will be useful and feel free to give me your comments.

To download: AgileSHIFT_wp_Exploring-the-delta-in-AgileSHIFT

Are incremental and iterative the same phenomenon or not? (Part I)

webinarDuring training classes I often notice that students mix these words 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. At the end you will find the corresponding mini webinar. In the second part of this article, I position waterfall and agile in an incremental versus iterative cross or matrix and shows what happens in the other two quadrants too (will be part of a next blog post).

The development of a payment app

Waterfall approach

If this app is developed according to a traditional waterfall approach, the following steps could be observed (see figure 1).

It all started with a project sponsor from the marketing department who was able to free up the necessary funds for this app. It was his assumption that the app will improve the retention figures and the inflow of new clients will grow. He visualized three high level function groups.

At a certain moment this project gets the approval to commence. A project manager is assigned, and a project team built. After many discussions and requirement gathering workshops there was an agreement to deliver a payment app with 250 features. All these features are recorded in an extensive and very detailed requirements document and signed by the project sponsor and customer representative (and some others).

In the next step the project team translates the requirements into a design for the app. The architect checks the design towards the design principles. He checks if all needed data attributes are available in the backend system too.

Dia3Figure 1: waterfall delivery of an app

We are now two months underway and the customer hasn’t seen anything working yet, only some progress reports. Probably some sort of ‘melon’ reporting[1] so they have no clue if the project is on track or not. It takes six months to develop the app and when that’s done the customer representative is asked to deliver some people who can help with a user acceptance test. During the test it becomes clear that several features are not working. The project team doesn’t understand why. It’s exactly what was described in the requirements document. Lots of discussions, rework, delays and customers who aren’t happy with the results. If we look at the final result, we can also notice that many of the developed requirements are not or rarely used[2] by the customer. It could even be worse. Suppose the development of the app took 1.5 year and another bank delivers a payment app when you are halfway. What would you do at that moment? Would you still have a viable business case to continue and finish your own app?

If you look at figure 1 it becomes clear that in case of a waterfall approach the scope and underlying quality criteria are fixed with a single delivery. All steps are performed once for the entire project and management control is focusing on cost and time. Value delivery to the customer only takes place after the deployment of the complete app.

Agile approach

If we develop the app in an agile way, we see the following pattern. The development team stated that they are able to deliver the first two features prioritized by the product owner (balance information and submit feedback) in the first iteration. The project team delivers every three weeks (sprint, iteration or timebox) an increment of the product. After the first deliveries or increments we see a customer who has confidence that the project will deliver. He/she already has a working app. He understands that not all features are there yet but what he has is working. Looking at the latest release and the provided features, he mentions a completely new feature. One that nobody had on his mind at the start of the project but a feature that can make his life as a customer much more productive. After every increment the customer feedback results in new features (not on the list) or adjustments of potential features and the product becomes more and more mature. Every time when the customer receives a new version you can see a happier customer.

Dia4Figure 2: Agile delivery of an app

If we look at figure 2, we see a steady flow of delivery within a fixed duration and using permanent agile teams (fixed costs). The scope and underlying quality criteria are flexible (dynamic) with frequent small deliveries (increments). All steps are performed repeatedly (iterative) to deliver a feature or user story until the required quality is reached. Management control is focusing on customer value delivery. Value delivery to the customer takes place after every deployment of an increment of the app.

Waterfall versus agile delivery results

If we take a closer look at the two products from both the waterfall as well as the agile approach, we see a product with 250 features and a not so happy customer and one with only 150 features and a very happy customer (see figure 3).

Dia5Figure 3: Waterfall versus agile delivery results

And if we even look in more details to the product delivered by the agile approach, we only see 100 features from the original list and 50 are new or adjusted features. This is in line with some important principles of the agile manifesto[3]:Simplicity – the art of maximizing the amount of work not done – is essential (only 150 features instead of 250 features) and Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage (50 new or adjusted features were delivered). And as a result, a very happy customer (Our highest priority is to satisfy the customer through early and continuous delivery of valuable software)!

Mini webinar Waterfall versus agile delivery

[1] ‘Melon’ or better ‘watermelon’ reporting is a progress report with green indicator(s). In reality the green indicator is red inside.

[2] Standish Group research shows that 60% of the developed requirements are not or rarely used (https://www.standishgroup.com).

[3] https://agilemanifesto.org

Is Scream a new tree in the Agile forest?

Schermafdruk 2020-03-01 13.58.15Via my network I received the first version of the Scream Guide; a comprehensive guide (22 pages) to organizational screaming, written by Michael Küsters.

Scream is a framework built as an imitation of Scrum, giving unwitting observers the appearance that the organization might be using Scrum. Scream is a framework for cementing the status quo, preserving existing mindsets and creating an illusion that things are improving. Scream is lightweight and easy to do, but difficult to get rid of.

Scream is intended as a humorous reflection opportunity of anti-patterns you might observe and not meant to be implemented.

Scream uses the pillars of obfuscation, asymmetric information and moving targets and the following value definitions:

    • “Courage” means accepting more work than can be done
    • “Commitment” means doing it in unpaid overtime
    • “Openness” means still taking another task whenever asked
    • “Focus” means juggling many balls without being caught dropping any
    • “Respect” means not complaining about any of the above when talking to managers.

The Scream Team consists of a Product Owner (responsible for maximizing the workload of the Development Team), the Development Team (consists of people who do the work that they are told to do), and a Scream Master – plus their manager (a strong, demanding manager who suppresses autonomy, creativity and personal growth within the Scream team). Scream Teams appear self-organizing and cross-functional when indeed the entire show is run by the manager.

Prescription is an important element of Scream, and Scream events (sprint, sprint planning, daily scream, sprint review and sprint retrospective) are used to interrupt work, control team members and maximize the dependency on outside management interference.

Schermafdruk 2020-03-01 14.06.54After detailed descriptions of the roles, events, artifacts and rules you get a list of supporting practices. E.g. Scream practice supports a number of special sprints: kick-off sprint, sprint zero, document sprint, refinement sprint, testing sprint, integrating sprint, hardening sprint, deployment sprint, release sprint, stabilization sprint and innovation sprint.

Conclusion: Scream isn’t a new tree in the agile forest. It is fun to read and every sentence is an agile antipatern. This guide will definitely help to mature your own chosen agile framework tree implementation.

To download: www.agilegothenburg.org/blog/2019-posts/the-scream-guide-is-out

To refresh your memory have a look at the latest Bird’s eye view on the Agile forest.birds eye

See for the corresponding article: a-bird’s eye view on the agile forest article

The SCRUM Fieldbook

9780525573210-480x600J.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