One of the magic powers of Product Managers is to conduct customer discovery interviews. It had been a long time since my last session, so yesterday I set a day aside and went out for interviews.

You see, I’m researching possible solutions to a problem that may affect everyone working from home: how might we foster valuable relationships and expand our social network without a “watercooler” moment at the office?

A perfect place for networking is my neighborhood coffee shop. Any day of the week you’ll find people working there for hours. They bring their laptop charger and headphones and…. Isolate themselves.

So, this seemed the perfect audience for my study: working professionals who don’t go to the office.

With my interview guide at hand, I sat with the first guy. He told me that he was about to leave, to go to the office. In my mind: interesting edge case. So, I asked for just a couple of minutes of his time, and he explained that the coffee shop for him is a nice, quick stop in the morning to get heads-down work done, before going to the office where he will be interrupted all day by colleagues.

“Exactly what I’m doing right now, right?” I joked, but he acknowledged that it was true.

LEARNING #1: Not everyone has the same needs. That’s why it’s important to talk to different people

On to my second interview. This man declined to talk to me. Too busy doing “work” stuff. So did the next person. And the one after them.

LEARNING #2: People actually do work from coffee shops and they don’t want to be interrupted. Not everyone cares about social connections.

I moved a few tables away and saw an empty seat in front of a lady.

I asked her if she would spend 10 minutes of her time by answering a few questions for an interview. She was very polite, but also I could read in her face the signs of discomfort and annoyance.

She replied “Well, not really. What’s this about? I’m busy.”

I explained the problem I was working on and why I was conducting these interviews. Her face lit up and she smiled, inviting me to sit down. She could spare a couple of minutes.

She said: “Look, I work full time in the office. I’m here today because I just met a friend. I’m not your target audience.”

Fair enough. And also interesting, again maybe some unexpected learning.

And then she added: “A suggestion for you. When you approached me asking for an interview, I thought you were selling me something: High-speed fiber internet? Fight-the-hunger non-profit? Help-the-homeless? I don’t know…”

LEARNING #3A: People have their guards up in public spaces.

LEARNING #3B: When asking people for their time, don’t ask for their time. Explain what problem you are working on, and see if that resonates with them. If that does, they will offer their time to you.

With that new learning in mind, I moved on to my next interview. Two ladies at a table having a chat and enjoying a meal. I thought “this is going to be hard.” I started off by explaining the problem I was working on, and they invited me to their table to have a chat. It worked.

And after that, it worked again for my last interview of the day.

LESSON #4: Approaching people can be intimidating. Some may decline to talk to you. That’s OK. Don’t let that be in the way. If you are working on something valuable, someone will be interested in helping you.

I appreciated everyone I spoke to — including those that declined my request — because I learned something from each one of them.

The artificial intelligence revolution is no longer a distant promise-it’s reshaping industries today, and companies that hesitate risk being left behind. With 66% of CEOs reporting measurable business benefits from generative AI initiatives, particularly in enhancing operational efficiency and customer satisfaction, and 74% predicting that GenAI will make changes to their company’s business model, the strategic imperative for AI adoption has never been clearer. Yet despite this compelling opportunity, 74% of companies struggle to achieve and scale value from their AI investments, revealing a critical gap between AI’s potential and its practical implementation.

The difference between AI success and failure lies not in the technology itself, but in leadership’s approach to adoption. McKinsey research reveals that employees are three times more likely to be using generative AI than their leaders expect, highlighting a fundamental disconnect between C-suite assumptions and ground-level reality. This gap underscores a crucial truth: successful AI transformation requires more than technological investment-it demands visionary leadership, strategic planning, and systematic execution.

Despite AI’s potential to drive efficiency and innovation, integrating AI into business operations remains a complex process that requires organizations to navigate technical, financial, and ethical challenges. The path forward requires leaders to approach AI adoption as both a technological and organizational transformation. This means developing clear strategies that align AI initiatives with business objectives, investing in the right talent and infrastructure, implementing robust change management processes, and maintaining a relentless focus on measurable outcomes. The companies that master this balance-treating AI as a business enabler rather than merely a technology project-are already pulling ahead of competitors and establishing market positions that will be difficult to challenge.

The following case studies from JPMorgan Chase, BMW, and Duolingo illustrate how industry leaders across financial services, manufacturing, and edtech have successfully navigated AI adoption challenges to achieve remarkable results. Their experiences provide a roadmap for other organizations seeking to harness AI’s transformational potential while avoiding common pitfalls that derail AI initiatives.

Revenue growth and tangible business value creation proved consistent across all implementations. JPMorgan can directly attribute $1–1.5 billion in annual value from their AI initiatives, BMW achieved quantifiable savings of over $1 million annually from a single AI application while exceeding productivity expectations by 5x, and Duolingo drove 41% revenue growth through AI-powered subscription tiers and enhanced user engagement.

Case Study: JPMorgan Chase Cracked the AI Code While Others Waited

JPMorgan Chase — Financial Services: AI technology already contributes $1 billion to $1.5 billion in value to the bank annually, with Coach AI improving response times by 95% during market volatility and contributing to a 20% increase in gross sales in asset and wealth management.

Read the case study

Case Study: BMW’s AI-Powered Manufacturing Transformation

BMW — Manufacturing: AI implementation allowed BMW to achieve “five times more than what they thought was possible” in manufacturing productivity, while enabling workforce redeployment to higher-value roles.

Read the case study

Case Study: Duolingo’s AI-Powered Language Learning Revolution

Duolingo — Education Technology: AI-powered features drove a 51% surge in Daily Active Users to over 40 million and enabled revenue guidance increases to over $1 billion, while 78% of users reported feeling more prepared for real-world conversations after using AI conversation practice.

Read the case study

Key Success Factors for Leadership

What does this mean for Executives, and how can Leadership drive a successful AI adoption? The three case studies mentioned above provide insights into the role of leadership and key steps to follow.

Strategic Foundation

• Start with Clear Business Problems: All three companies targeted specific, measurable pain points rather than implementing AI for innovation’s sake
• Secure Executive Commitment: JPMorgan added Chief Data and Analytics Officer to technology leadership team, BMW developed solutions in-house, Duolingo’s CEO actively championed the AI integration

Implementation Approach

• Begin with Pilot Projects: Each company started with targeted use cases before scaling organization-wide
• Focus on Back-Office First: JPMorgan prioritized back-office efficiency enhancements before rolling out customer-facing AI solutions, ensuring compliance and minimizing risks
• Integrate Rather Than Replace: All companies positioned AI as augmenting human capabilities rather than replacing workers

Data and Infrastructure

• Build Strong Data Foundations: BMW developed SORDI, the world’s largest reference dataset for AI in manufacturing; JPMorgan invested heavily in data modernization.
• Invest in Internal Capabilities: BMW’s AI technology was developed internally and is patent-pending; Duolingo used internal skills to integrate the OpenAI’s GPT LLM into its product. All companies built in-house expertise rather than relying solely on vendors.

Measurement and ROI Focus

• Establish Clear Metrics: Organizations tracking well-defined KPIs for AI solutions see the biggest EBIT impact.
• Quantify Business Value: Each company can demonstrate specific financial returns from AI investments.
• Track Both Leading and Lagging Indicators: Monitor adoption rates, user engagement, and business outcomes.

Change Management

• Invest in Training: JPMorgan increased training hours by 500% and made AI training mandatory for new hires.
• Plan for Workforce Transformation: BMW redeployed workers from routine tasks to higher-value roles.
• Maintain Human Oversight: Duolingo maintains human experts who constantly review AI-generated content for accuracy and tone.

Scaling Strategy

• Create Dedicated Teams: Establish dedicated teams (transformation offices) to drive AI adoption across business units.
• Build Integrated Solutions: Focus on AI ecosystems where multiple applications work together rather than isolated point solutions.
• Plan for Continuous Evolution: All companies view AI adoption as an ongoing transformation rather than a one-time implementation.

Governance and Risk Management

• Implement Responsible AI Practices: Establish frameworks for ethical AI development and deployment
• Balance Innovation with Risk: JPMorgan’s systematic approach to compliance, BMW’s focus on safety-critical applications, Duolingo’s content quality controls
• Maintain Regulatory Awareness: Particularly critical in highly regulated industries like financial services

Bottom Line for Leaders

The success of JPMorgan Chase, BMW, and Duolingo demonstrates that effective AI adoption requires more than just technology implementation-it demands strategic vision, systematic execution, and organizational transformation. Leaders who focus on solving specific business problems, invest in data infrastructure and human capabilities, measure outcomes rigorously, and scale gradually from proven successes are most likely to achieve transformational results from their AI investments.

The common thread across all three companies is their approach to AI as a business enabler rather than a technology project, with clear alignment between AI initiatives and core business objectives, supported by strong leadership commitment and comprehensive change management.

Originally published at https://www.5dvision.com on August 26, 2025.

What is the role of the Scrum Master and how does the role grow together with the career opportunities for a Scrum Master? The Scrum Master Competency Ladder shows how the Scrum Master role evolves over time as the Scrum Master grows, as the team that they are supporting grows, and as the focus of the Scrum Master shifts from helping one Scrum team to helping multiple Scrum teams and then helping the rest of the organization become an agile organization.

One way for the Scrum Masters to look at the evolution of their job over time as they grow in their role is the Scrum Master Competency Ladder.

Level 1 — Learn to fly

When the Scrum Master starts working, when they are new to the role, or they start working with a new team, they are in Level 1 and I call it “Learn to Fly”. They are really learning to fly. As their focus is on one Scrum team, they are also helping the Scrum team learn to fly.

Activities at this stage include facilitating Scrum events, coaching the Scrum team on how to adopt Scrum more effectively, supporting the Product Owner in refining the product backlog effectively so that value can be delivered each sprint, and helping the team solve any impediments, and then finally, helping the Scrum team adopt the Scrum patterns, so it can be successful in executing the Scrum process.

Level 2 — Spread the wings

As the Scrum Master grows in the role, they move on to the next level and that is when the Scrum Master starts to “Spread their wings”.

The Scrum Master shifts the focus a little bit from just one team to supporting other Scrum teams and creating a community of practice within the organization. The Scrum Masters connect with each other, share best practices, help to elevate all the Scrum teams. They contribute to everybody’s growth, so not to have just one Scrum team high performing and the others lay behind.

How do you do that? At level 2, the Scrum Master focuses on fostering continuous improvement for the Scrum team they’re working with or the Scrum teams across the organization by partnering with other Scrum Masters. Maybe they cross-facilitate each other’s events so that they can learn new practices and each Scrum team get exposed to different ways of thinking, different ideas, from different Scrum Masters.

They can start coaching the Product Owner on the product patterns to also help the Product Owner elevate and learn more about their own job and their own practices. Product patterns are documented activities that successful Product Owners implement in their daily jobs to drive product validation and development. While the Scrum Master is not expected to be an expert in product management, they can guide the Product Owner in learning more and practicing with new techniques that make them more effective.

Level 3 — Reach for the sky

As the Scrum Master grows in their experience, and as the Scrum teams mature, the Scrum Master can “Reach for the sky”. What it means is that they shift the focus onto the rest of the organization, the leadership, and the overall culture of the organization. Now the Scrum Master dedicates most of their time to working with stakeholders and leaders in the organization to guide the organization in adopting Agile values and principles.

The Scrum Master also helps leaders understand how their role is key to successfully become an Agile organization, and also is key to the success of the Scrum teams. For the Scrum teams to be successful, they need to be empowered and they need to be given the support, the flexibility, the resources to be able accomplish their objectives. And this is the role of the leadership.

At level 3, the Scrum Masters identify and solve cultural impediments, looking for things that are in the way in how the organization typically operates. They coach leaderships on adoption of Agile principles and values. They engage with stakeholders in supporting the Scrum teams. They work with the product leadership, senior management, product managers, other leaders in adopting Scrum patterns and enabling a culture of product thinking throughout the rest of the organization.

The Scrum Master may even facilitate workshops for product people with the customers and stakeholders to bring everybody on the same page, for example, on a shared product vision or an updated roadmap. When I say facilitate, it means that the Scrum Master creates the space where the stakeholders and the product people can actually have the conversation and create that alignment. For example, the Scrum Master may recommend organizing a workshop on “product vision” to make sure everyone is aligned on the vision and top priorities for the product.

That’s how the role of the Scrum Master evolves over time.

I invite all the Scrum Masters to think that your job is not to facilitate Scrum events. At least not only this. Maybe, 10% of your time is spent on facilitation.

The rest is to help the Scrum teams grow, help the organization grow, adopt Agile values and principles more effectively, and help everybody understand how to empower the Scrum teams. The goal is to create Scrum teams that are self-organizing units that can take an idea, test an idea, understand those assumptions behind the idea, experiment, and then possibly update their own plans as frequently as needed with a goal of building a better product for your customers.

The Scrum Master plays a pivotal role in enabling the people on the Scrum teams to be highly productive and in guiding the organization towards delivering higher value products using Scrum effectively.

Running the Sprint Retrospective always in the same way (e.g. “What went well, what didn’t go well, what can we improve?”) is not going to provide much insight after a few times. The questions become stale, and the retrospective feels mechanical.

A good Scrum Master changes the retrospective exercise every time. By doing so, they can help the team members see issues from different perspectives, come up with new ideas, and identify areas of improvement that were hidden before.

However, coming up with new ideas and exercises for retrospectives is not an easy task. Yes, there are tools and websites that can help, but that still requires some effort.

I asked Bard, the generative AI engine from Google, to provide some suggestions. I started with a simple question, and got the usual answer.

Then, I pushed Bard to think a bit outside the box, and it started generating new ideas for retrospectives that are both unusual and though-provoking.

I’m sharing below the results.

If you want to try on your own, copy and paste the prompts below into Bard, and read the results.

Prompt 1: “Suggest a good retrospective exercise”

A good retrospective exercise is one that is engaging, informative, and productive. It should help the team to reflect on what went well, what could be improved, and what they will do differently next time.

One such exercise is the Start, Stop, Continue retrospective. This exercise is simple but effective, and it can be used by teams of any size.

To do this exercise, start by writing down three columns on a whiteboard or flipchart: Start, Stop, and Continue. Then, ask the team to brainstorm a list of things that they would like to start doing, stop doing, and continue doing in the next sprint.

Once the team has finished brainstorming, take some time to discuss each item on the list. Why does the team want to start, stop, or continue doing each thing? Are there any patterns or themes emerging?

Finally, the team should agree on a few action items that they will implement in the next sprint. These action items should be specific, measurable, achievable, relevant, and time-bound.

Here are some examples of Start, Stop, and Continue items:

Start:

· Daily stand-up meetings

· Code reviews

· Test-driven development

Stop:

· Working late hours

· Multitasking

· Cutting corners

Continue:

· Pair programming

· Retrospectives

· Celebrating successes

The Start, Stop, Continue retrospective is a great way to get the team thinking about how they can improve their workflow and processes. It is also a good way to build consensus and commitment to change.

Another good retrospective exercise is the Sailboat retrospective. This exercise is a bit more creative than the Start, Stop, Continue retrospective, and it can be a lot of fun for the team.

To do this exercise, start by drawing a picture of a sailboat on a whiteboard or flipchart. The sailboat should be sailing towards an island, which represents the team’s goal.

Then, ask the team to identify the things that are helping the sailboat to move forward (e.g., good communication, clear goals, effective tools and processes). These are the team’s strengths.

Next, ask the team to identify the things that are preventing the sailboat from moving forward (e.g., lack of communication, unclear goals, ineffective tools and processes). These are the team’s areas for improvement.

Finally, the team should brainstorm some ideas for how they can overcome their areas for improvement and reach their goal.

The Sailboat retrospective is a great way to help the team to visualize their progress and identify the things that they need to do to achieve their goals. It is also a good way to get the team thinking creatively about how they can improve their workflow and processes.

No matter which retrospective exercise you choose, the most important thing is to create a safe and supportive environment where the team can share their thoughts and feedback honestly.

Prompt 2: “Suggest non typical retrospective exercise”

Here are some non-typical retrospective exercises:

Mad Libs retrospective:

This exercise is a fun and creative way to get the team thinking about what went well, what could be improved, and what they will do differently next time. To do this exercise, simply create a Mad Libs template with prompts related to the team’s work. For example, you could have prompts like:

· My favorite thing about this sprint was [adjective].

· One thing I learned this sprint was [something].

· One thing I would like to do differently next sprint is [something].

Once you have created the template, hand it out to the team and have them fill it in individually. Then, read the completed Mad Libs aloud to the team. This is sure to get some laughs and get the team thinking about their work in a new way.

Image retrospective:

This exercise is a great way to get the team thinking visually about their work. To do this exercise, start by collecting a variety of images related to the team’s work. For example, you could collect images of successful teams, images of teams facing challenges, and images of tools and processes that the team uses.

Once you have collected the images, display them in a prominent location and have the team take some time to browse through them. Then, ask the team to choose one image that represents their experience of the sprint.

Once the team has chosen an image, ask them to share why they chose that image and what it represents to them. This exercise can help the team to identify patterns and themes in their work, and it can also help them to identify areas where they can improve.

Storytelling retrospective:

This exercise is a great way to get the team to share their experiences and learn from each other. To do this exercise, start by asking the team to share a story about something that happened during the sprint. The story can be positive or negative, but it should be something that the team member learned from.

Once the team member has finished sharing their story, ask the rest of the team to share their thoughts and reactions. What did they learn from the story? How can the team apply the lessons from the story to their future work?

This exercise can help the team to build empathy for each other and to learn from each other’s experiences. It can also help the team to identify patterns and themes in their work, and it can help them to identify areas where they can improve.

These are just a few examples of non-typical retrospective exercises. There are many other creative and innovative ways to run a retrospective. The most important thing is to choose an exercise that is appropriate for your team and that will help them to achieve their goals.

Prompt #3: “Suggest an innovative retrospective exercise”

Here is an innovative retrospective exercise that you can try with your team:

The Retrospective Escape Room

This exercise is a fun and engaging way to get the team thinking about what went well, what could be improved, and what they will do differently next time. It is also a great way to build teamwork and communication skills.

To do this exercise, you will need to create an escape room environment. This can be done in a variety of ways, such as by setting up different stations around the room with puzzles or challenges that the team needs to solve in order to escape.

Once you have created the escape room environment, divide the team into small groups and have them start working on the puzzles and challenges. As the team works through the escape room, they will need to communicate and work together in order to solve the puzzles and escape.

Once the team has escaped from the escape room, bring them together for a debriefing session. Ask the team to reflect on what went well, what could be improved, and what they learned from the experience. You can also use the debriefing session to discuss how the team can apply the lessons they learned to their future work.

Here are some ideas for puzzles and challenges that you can use in your retrospective escape room:

· Puzzle: Give the team a puzzle to solve that is related to their work. For example, if the team is working on a software development project, you could give them a puzzle that requires them to write a piece of code.

· Challenge: Give the team a challenge to complete that is related to their work. For example, if the team is working on a customer service project, you could give them a challenge that requires them to resolve a customer complaint.

· Communication exercise: Give the team a communication exercise to complete. For example, you could have the team play a game of charades or have them try to communicate a message to each other without using any words.

You can customize the escape room environment and the puzzles and challenges to fit your team’s specific needs and interests. The most important thing is to create an escape room experience that is challenging, fun, and educational.

I hope this innovative retrospective exercise helps you and your team to have a productive and enjoyable retrospective!

Valerio Zanini is a Certified Scrum Trainer and can be found at https://www.trulyscrum.com/

I asked AI for help with a Retrospective was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

Is Scrum incremental or iterative?

Sprints are iterations, yet in every Sprint we deliver an Increment. So, is it incremental or iterative?

Let’s look at the difference between these two approaches first.

INCREMENTAL:

In an incremental approach, the development process is broken down into small, manageable portions called Increments. Each Increment is a working slice of the system.

While an Increment may not deliver the full functionality of the end-system, it delivers some functionality that can potentially be used by end-users while the rest of the system is built. End-users don’t have to wait for the full project to be completed before they can use the system.

An incremental approach starts with a clear end-state in mind. Typically, the system is scoped out first, and then it’s delivered one increment at a time. This approach allows end-users to start using a (partially built) system without waiting for the full project to be completed.

ITERATIVE:

In an iterative approach, the development of a new system goes through repeated cycles of refinement. In an iterative approach, the work of one iteration is improved upon in subsequent iterations.

After one iteration, the end result of the work is presented to the end-users and their feedback helps to decide what to do next. The plan for the system is refined, and a new iteration starts with a new goal in mind.

In an iterative approach, the end-state of the system is not known upfront. The system is refined through multiple iterations. This approach allows for experimentation and refinement of ideas.

EXAMPLE

Let’s imagine that we want to make a delicious hamburger sandwich. We could approach this task in two different ways.

INCREMENTAL: If we know upfront what kind of hamburger sandwich we want, which toppings, cooking level, etc. we can define the end-state and use an incremental approach to build the hamburger sandwich. Each Increment is potentially usable by the users (they may eat it, although many will prefer waiting for the full sandwich :-).

The incremental approach answers the question: “How do we make a hamburger sandwich?”

ITERATIVE: Instead, if we are trying to figure out how to create a sandwich with a hamburger, we may go through repeated iterations and try out different ideas. In each iteration we build a possible solution for the sandwich, get feedback, and then decide what to build in the next iteration.

The iterative approach answers the question: “How might we make a sandwich with a hamburger?”

SCRUM

Let’s go back to Scrum and the opening question: Scrum is both an incremental and an iterative approach.

Adopting both approaches together allows a team to deliver functionality incrementally to the end-users while at the same time experimenting and refining solutions. Scrum provides the flexibility of both approaches.

What’s wrong with User Stories?

When I work with teams on writing User Stories, the question always comes up: “What are User Stories and how are they different from requirements?”

The User Story is a format to write work items in a Product Backlog and it is used to shift the dynamic between Product Owner and Developers by fostering a conversation. User Stories help a Scrum Team to become more collaborative, to foster innovation, and to deliver better solutions.

User Stories help to frame tasks and work items from a customer’s perspective. By doing so, they help everyone on the team develop a deeper understanding of the customer needs, and foster a conversation on how best to solve that need. Hence, the User Stories should be written from the customer’s point of view.

Things get weird when User Stories are written like:

AS a Product Owner, I WANT to create xyz, SO THAT my customers can do abc

What’s wrong with this story? The Product Owner is not the user! The Product Owner is not the one getting the benefit from the story. They are just requesting the work.

Or consider this:

AS a Developer, I WANT to improve xyz feature, SO THAT my customers can use it

What’s wrong with this? The Developers are those doing the work, not the end-users (unless the work is done specifically for the Developers, like installing a new development tool for them to work better).

How to improve then?
Well, first, always write the User Story from the end-user’s point of view. Not from who’s requesting the work, not from who’s doing the work. From the end-user who will use the end-result of the work once completed.

Consider also that User Stories are not the only way that you can write work items in the Product Backlog. Consider in fact the System Story and Job Story formats.

The System Story format

The System Story format is useful for any internal work, bug solving, and performance enhancement work. This includes any “Enabler” work item to improve the system or extend the architectural runway.

The focus of a system story is a particular action to be taken to achieve the desired effect.

A System Story has similar elements of a User Story, but describes a particular action to achieve the desired outcome. The basic format of a System Story is:

<ACTION VERB>

<SUBJECT>

So that <WHAT> or <GOAL> is achieved

For example, if one work item is to upgrade the database server to the latest version for increased security and performance, we could write this work item in System Story format:

Upgrade

Database to the latest version

So that we increase security and performance of our system

The Job Story format

The Job Story is another format that is useful to represent the customer’s needs and create context about a scenario. The Job Story fits nicely to represent work items using Job-To-Be-Done. This makes it clear what job the end-user expects the system to perform to solve their needs.

Jobs-To-Be-Done (JTBD) is a product development approach that states that customers don’t buy products, they buy the jobs the products help them complete. For example, someone might buy a screwdriver to help assemble furniture. The “job” is to assemble furniture. The screwdriver is doing the job for the customer.

The theory is based on the idea that people buy products and services to get a “job” done. Job-To-Be-Done is a powerful approach to describe functionalities and work items as it enforces a focus on the customers and their specific needs.

Hence, we could use the Job Story format to write work items in a backlog, instead of User Stories. The Job Story format is:

WHEN [situation]

I WANT [action or activity]

SO THAT [objective to achieve]

The situation provides context on when the story is being performed or perhaps what triggers the story. For example:

• WHEN an order is submitted…
• WHEN paying by credit card…
• WHEN I am the store and realize I forgot my wallet at home…
• WHEN looking at recent orders..

The Job Story implies there is a clearly defined customer that needs the job done. Therefore this format is useful when the user or customer is well understood — for example, when you have a clearly defined User Persona and you are developing a series of features for that Persona.

A full example of Job Story:

WHEN I submit an order,

I WANT to receive a notification in email

SO THAT I can save a record of my orders and avoid re-ordering

Instead of repeating the name of the Persona in every User Story, you can use the Job Story format. It’s clearer, and it adds more context about the situation in which the Persona finds themselves.

Stories are not requirements

Now, regardless of the specific Story format you use, remember that User Stories/System Stories/Job Stories are not requirements. Requirements specify what needs to be built and (often) how to do it.

Stories specify what the user needs to do or achieve, and why that is important to them. How specifically to do it, or how to build it, are not specified in the Story, instead they emerge as part of the conversation between the Product Owner and the Developer.

Unconvinced? Jump to the User Stories are not requirements article.

Valerio Zanini is a Certified Scrum Trainer and Agile Coach.

He manages Truly Scrum, a community for Scrum Masters and Agile Coaches. https://www.trulyscrum.com/

System Story and Job Story formats: Not everything is a User Story was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

However, while there are many reasons why Agile transformations struggle to take off, the lack of proper product thinking is often a likely culprit. In fact, even the best Agile teams cannot deliver much value if proper product visioning, prioritization, roadmapping, and validation practices are not in place or properly followed. Instead, Agile gets the blame and teams become resistant to change.

Where Agile fails

For all its benefits and — let’s be honest — hype, Agile is not the medicine that cures all illnesses. Here are four situations where I’ve seen Agile fail:

1) Just take half of the pill

Just “doing” Agile doesn’t mean necessarily “being” Agile. And this is an important distinction in terms of empowerment, culture, organization, customer focus, engineering practices, and reaction to failure. “Doing” Agile often results in teams adopting the practices but not understanding the principles behind them. For instance, they may adopt Scrum, work in 2-week sprints, do daily standups, and hold a retrospective at the end of the sprint. At face value, they are “doing” Scrum, but everything else in the product planning, validation, and delivery stays the same, the way that company has always operated.

As a result, the ”Agile” team may not see the benefits it expects, or it may feel as burdened as before. Often, these teams go through the motions of Agile without really adopting the mindset or the principles.

One example: a development team I recently worked with was given a list of work items at every sprint by their product owner, and that list was always at least twice the capacity of the team. The reasoning was, “better give them more work and getting something as a result, than have them slack”. From the developers’ perspective, they struggled with choosing what to work on and what to skip, multitasking their way through the sprint, and adjusting to a continuous change of priorities. The team members were not empowered, the culture didn’t support trust, and the work was mainly push-down execution focused. The end result? Nothing to show after several sprints of work.

I’ve written about “doing” Agile versus “being” Agile other times in the past https://www.5dvision.com/post/being-agile-versus-just-doing-agile/ Companies that adopt Agile half-heartedly try to “do” Agile but often struggle with the inevitable changes that are required for a transformation to be successful, and with the problems that inevitably Agile brings to the surface and need to be solved. Agile in itself is not the solution. A deeper change is needed to reap the benefits of agility and it often starts from changing the mindset and how the organization approaches work. This is usually where Agile coaches and effective Scrum Masters can help in driving a real transformation.

2) Management commits only to a half-hearted adoption

Sometimes a company is required to adopt Agile practices because of market forces. For example, a key customer demands that all suppliers adopt the same practices — these could be Scrum, SAFe, or others. The company then makes an effort at adopting Agile, often by training large portions of the organization and by establishing Agile teams. Yet, this is often a half-hearted adoption, as the mindset and the overall processes of managing work are not really affected.

A symptom of this brings to light a misunderstanding of what Agile is really about: I’ve heard senior leaders say, “I don’t want to adopt Agile because it gives my team the right to do what they want, whenever they want it”. And when these leaders are forced to become more Agile, they inevitably do so half-heartedly, hoping that the “wind” will shift soon in a different direction.

Instead, leaders should embrace the Agile transformation as an opportunity.

Instead of changing the whole organization at once, select a small target group and infuse a culture of agility there. Give proper direction in terms of vision, priorities, and objectives, then let the team members self-organize how best to do the work. Establish transparency throughout the process, including feedback loops with stakeholders. Inspect and adapt frequently, and provide the support needed for the team members to succeed. Once a small group reaps the benefits, sustain the momentum by expanding Agile practices to other groups.

3) Scrum is used as a slicing mechanism

This scenario is scary, not because it’s evil, but because it shows good intentions that are put into action without proper understanding of product development principles.

A couple of years ago a large US bank embarked in a modernization project to replace its 20+ year old legacy system with a modern Salesforce platform. Its teams spent more than six months documenting in excruciating details all the requirements and features of the legacy system that needed to be ported to the new platform. Then they estimated the amount of work at 12 months, set a deadline, and promised a delivery date to the senior management.

At that point they handed off the requirements to engineering. The engineering teams adopted Scrum and sliced the work in 2-week sprints. At the end of each sprint, the teams held a sprint review with the key stakeholders, demoing the work increment, and receiving feedback. Then the teams set off to work on the next slice of the requirements. They were building the whole product incrementally, one slice at a time.

The whole product had already been planned and detailed upfront, and the engineering teams were required to do what the plan specified. Scrum was considered a slicing mechanism to deliver the work. There was no concept of validation of functionality based on user needs, of adaptation of the plan based on what the team had learned throughout the process, or of prioritizing the backlog of work so that high-priority items were completed early and higher value could be provided to the users faster.

Everything had the same importance because, well, everything had to be built. In reality, this was a big waterfall project masqueraded as “Agile”. Unfortunately, it failed miserably when the 12-month deadline arrived and the system was only half built. The plan did not account for a partial delivery and validation, and the teams had to complete the entire product before releasing it to the users.

4) Forget the big picture

When an Agile team works repeatedly on the same product sprint after sprint, its main focus becomes execution, getting the next set of features done and out in production. While this focus is great, the danger is that the team becomes shortsighted and loses context of the big picture: Why is the team building the product? Why is the next set of features important for the customers? Why should the team continue building this product instead of something else?

In order to answer these questions and elevate the views of the Agile team, it’s important for the Product Owner to understand and uphold its role within the team. The Product Owner should continually provide the context the team needs to understand where the product fits within the larger vision and strategy; should invite the team members to do “gemba walks”, meet customers, and learn directly from them about needs and pain-points; should manage the backlog with a critical eye, not focusing on just execution, but also in discerning if the team’s energy would be best spent on working on something completely different.

A Product Owner I know makes the point of reviewing the product’s vision with the team every sprint, to keep it fresh in everybody’s memory and align their work to the bigger objective.

Shortcutting Agile is not the solution

If you do an online search today, you may find articles that state that companies have reached agile maturity or that they don’t need Agile anymore. Some of these companies refer to the speed at which they can deliver new products as a testament to their maturity.

No-code platforms like Unqork, Airtable, Salesforce, Wordpress, and many others, speed up the development process and make it easier for business people (rather than technical people) to build business applications. Salesforce invented the cloud and pioneered the concept of a pre-made platform that was easy to customize with just business logic and no coding. Wordpress allows anyone to build a website by using drag-and-drop modules rather than hard-coding HTML, CSS, etc. Unqork and Airtable let business users create applications and digitize business processes in a simple and fast way. All this is great.

But even if we can build a product faster, how do we know if what we are building is the right product?

Building the right product is not the same thing as building the product right. Whatever minimum investment we are making, we are still spending time, money, and resources into building something.

By bundling Agile and Product Thinking, we get the practices and mindset to maximize the value of our investment and deliver a product that customers want.

Even the most powerful platforms require some technical work for customization and support of specific use cases. Also, I would argue that faster development cycles don’t allow abdicating the need for proper understanding of what needs to be done and what needs to be prioritized. You can build things faster, but if you don’t deliver what users need, your product is destined for the trash bin anyway.

Agile principle #7 states that “Working software is the primary measure of progress”. So, if a team can deliver working software in a faster and easier way, that’s all additional value delivered. You may be working at complex custom system integration or at a simpler no-code implementation of a new business application. By using no-code or low-code platforms whenever suitable, development teams can speed up the process and provide value to their customers faster. These benefits are important regardless of the technology stack you are employing.

By using Product Thinking practices throughout the development process the team can create transparency, shorten the feedback loop, and improve the quality of its deliverables. These practices span technology and platform boundaries, supporting the team in building the right product and delivering value to the customers. Without these objectives in mind we risk building the wrong thing or limiting the value we deliver.

It’s all about Product Thinking

As stated above, a blind application of Agile won’t cure all illnesses. Even the most faithful agilist who diligently executes the practices, will have a hard time reaping the benefits and delivering value to its customers, if the right Product Thinking mindset and culture is not in place. A development team cannot do it alone. The organization must provide the culture, the vision, the empowerment needed for success.

I recently was asked to help a large team who was building a strategic digital platform the company direly needed. The team was hard working, putting long hours and solving big problems. But the leadership kept changing the overall vision for this product, and with it the priorities of what to build. For the team is was difficult to focus and getting anything completed before the next change happened. After months of development, they had nothing to show in production.

The problem was not with poorly adopted Agile practices. The problem was with poor product practices that didn’t support the application of important principles needed for Agile to flourish.

You may get away with poorly implemented Agile practices, but if you don’t have the right product practices you may be wasting your investment or be doomed from the start.

Infusing an effective Product Thinking mindset is key to the success of a product initiative and to an Agile transformation. Therefore, I always spend as much time working with teams and their leadership in adopting the right product practices as I spend on Agile practices. I make sure that organizations understand the importance and value of having a customer-centric approach, that they understand the customer needs and what benefits the new product would deliver to the end-users.

The product team should spend the majority of time in discovery mode, talking with stakeholders and end-users, testing prototypes, refining ideas. This is true not only at the beginning of the project, but also throughout its development.

The market always knows about the job-to-be-done by your product more than you do. Ultimately, the market is the one that decides if it needs the product or not, so it makes sense to learn from it as quickly as possible.

Understand what job the market needs your product to do. What problem the customers have that they cannot find a good solution for. Validate your hypotheses with real users, get feedback from them, and measure the outcomes.

Once you identify a solution, use ruthless prioritization to maximize the value delivered and to give your teams the focus needed to complete the work. Instead of making a big upfront plan and using Scrum to build one slice at a time, map out the most critical features your customers need, and build an MVP (Minimum Viable Product) to validate the solution as quickly as possible. Learn what works and what doesn’t, and then iterate on the plan with the next set of features.

Like a tree, to grow healthy and bear fruit, it needs the proper roots. Adopt and support effective product practices and your Agile transformation will flourish.

Valerio Zanini is the co-founder of Spark Engine https://www.sparkengine.co an organization that helps product teams adopt Product Thinking and product innovation practices.
He is a Certified Product Innovation Trainer, a Certified Scrum Trainer, and Product Thinking Coach.
He’s also the author of “Deliver great products that customers love”.
Valerio lives in Washington, DC and travels worldwide.

There is no Agility without Product Thinking was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Besides the lack of clarity on what Velocity is, what surprised me was that 50% of people chose an answer that has nothing to do with Velocity. Let’s clarify right away that Velocity has nothing to do with value delivered. In fact, it’s totally possible that a team has a high Velocity, is able to complete a ton of work each sprint, and yet is delivering little value to the stakeholders. Value is measured by the Product Owner, whereas Velocity is measured by the Developers on a Scrum team (maybe with help from the Scrum Master).

So, let’s clarify a few points in hopes of removing the confusion about how teams can use Velocity, and do proper planning for their sprints. To talk about Velocity we need to talk also about Capacity, because the two measures are interrelated.

Velocity and Capacity are two measures that Scrum teams can use for proper planning. They are used to estimate the amount of work in an upcoming sprint and make a reliable plan. Velocity is a historical measure of the amount of work completed in prior Sprints. Capacity is the measure of how much work the team can reasonably commit to completing in the upcoming Sprint, taking in consideration work estimates, average velocity, availability of team members, a buffer for unplanned work, and vacation days.

Here is real-life example of how using Velocity to estimate Capacity in a given Sprint can actually help the team improve performance: We were half-way in Sprint Planning and suddenly it hit me. Like a light bulb turning on. I had been listening to the discussion between the Developers and the Product Owner and all seemed normal… until this very moment. I just realized that the team was planning their sprint with absolute no idea of velocity or capacity.

How did I figured it out? The Product Owner asked the team do do “60 points” of work and the team said “OK”. Not “let’s see”, “we’ll do our best”, or “let’s check our capacity and confirm what we can do”. Just “OK”.

I invited the team to open their burndown chart for previous sprints, and there it was. The team’s velocity was hovering around 27 points per sprint, and yet they were “OK” with taking on 60 points…. something was amiss.

This team was no different from many others with whom I’ve worked in the past. Work is given to them top-down by the power-to-be: product owner, CEO, customer… And the team just takes it on, struggles to do everything, works overtime, and maybe cuts corner on quality to complete the work on time by the end of the sprint.

In the process, the team members grow discontent, frustration, and lack of connection with the work they are doing. The more it goes on, the more this seems the normal way of doing. But there is a better way.

When we planned the next sprint using historical velocity as a measure of capacity, the team was able to increase their performance by 6 points (a 20% increase) going up to 33 points the next sprint. And two sprints later they were able to gain another 20% in performance going up to 40 points. Why?

Because they were able to focus on the work, minimize multitasking, and own the work they selected. These all drove performance increases. Teams that use velocity as a measure of capacity, and introduce a buffer for their work, increase performance.

So, let’s look at how you can do the same with your team.

Velocity, capacity, load

Velocity is the amount of work completed in previous sprints. It’s a measure of past performance for the team used for planning of future sprints. Typically, you look at the amount of work completed in the last three to five sprints, and take the average of their velocity. This helps to offset any spikes in a particular sprint. Teams that measure velocity can use it as their upper limit capacity to plan the next sprint. This is the Yesterday’s Weather pattern in action: we look back at past performance in previous sprints, and we use that measure to establish a baseline for capacity in the upcoming sprint.

Capacity is the maximum amount of work that the team can commit to doing in the upcoming sprint. The team can quickly establish capacity by starting from the average velocity and then adjusting it based on everyone’s availability during the next sprint. For example, if you know that a couple of team members will be in vacation during the sprint, you need to reduce your capacity by a proportional amount. Capacity should always be equal to or lower than the average velocity of the team, to avoid overcommitment.

Load is the amount of work selected by the team for the current sprint. This is the amount of work that the team is planning to complete in the sprint. It should be less or equal to capacity (otherwise the team is overcommitting). You start from your capacity, and then decide how much work you want to actually select for the sprint.

The load should be less or equal to capacity. Think of capacity as the maximum quantity of a jar of cookies, and the load as the amount of cookies actually in the jar. Since you love cookies, I bet you’d like to fill the jar to the brim. However, there is nothing wrong with leaving some empty space in the jar. You can always add more cookies later if needed.

The power of “slack” (AKA planning buffer)

Are you planning your work to fill you entire capacity? This may lead to overcommitment and missed release dates. In fact, planning work up to the entire capacity is usually a bad idea. It’s usually much better to choose a load that is less than the capacity, and leave a buffer that can be used for unexpected situations or unplanned work.

There are many reasons why you may want to choose a load that is lower than the available capacity. The difference is called a buffer and it’s a good thing to have.

When a system, a machine, or a person runs at its 100% capacity, we maximize utilization but we incur many other problems. For instance, if something unexpected shows up (there is a defect in a part that needs to be remade, or your babysitter calls because your kid is sick), you may not have spare capacity to deal with the unexpected event and complete your work. Something needs to give.

Also, if someone needs your help and you are utilized at 100% of your capacity, you won’t be able to help, therefore impacting someone else’s effectiveness. You may be able to deliver your work, but someone else on the team may fall behind. As a result, the whole team is affected.

Conversely, building a little bit of slack in the “system” creates the flexibility needed to deal with the unexpected work, help other people in need, or be able to complete all the work promised with full quality.

This is what we call a planning buffer: it is a portion of your capacity that you don’t use for the sprint backlog (the plan), but instead leave it aside for unexpected work that may show up for you during the sprint. This is called the Interrupt Buffer and it’s a good practice for a Scrum Team to always leave a portion of capacity unplanned. A good starting point for the buffer is 10% to 20% of your capacity. Some teams may need a bigger buffer if they deal with a lot of responsive work (e.g. emergency work in production).

Therefore, teams should select their load so that they leave a buffer to deal with the unexpected work. Leaving a bit of slack in your plan is a good thing and it’s the cushion that helps the team deliver on the goal — despite unexpected events.

For those of you that like math, here are the formulas:

velocity >= capacity >= load

buffer = capacity — load

The difference between capacity and load is your planning buffer.

https://www.youtube.com/watch?v=pFkBQ8ojyE4

How to be effective at planning to capacity?

1. Measure your velocity in past sprints, then calculate your average velocity — a good window is between the last 3 to 5 sprints. This is your team’s average velocity. This is also called the Yesterday’s Weather pattern.
2. Calculate capacity for the next sprint. Your starting point should be your team’s average velocity. Capacity may be lower if there are holidays or planned vacations during the sprint — decrease capacity accordingly.
3. Define your buffer. Leaving a portion of your capacity unplanned helps to prepare a more realistic plan. 10% to 20% of capacity is a good starting buffer.
4. Decide how much work you want to take in the sprint. This is going to be your load. You may decide not to fill up your entire capacity, and instead be conservative and able to adjust in light of unplanned work or unexpected events.

Example: Measure and adjust over time

Your team has already completed a number of sprints, and you are now planning sprint X. Your average velocity in previous sprints was 30 points. When planning sprint X, you use velocity to calculate capacity, and decide to save 6 points as your buffer (20% buffer):

Team’s velocity (previous sprints): 30

Max Capacity: 30 (assume no vacation/holidays)

Buffer: 6 points (for unplanned work)

Load: 24

Fast-forward to the end of the sprint and you completed all 24 points of work plus an extra 10 points: in fact, you finished the 24 points early, nothing unexpected happened, and you pulled more work from the backlog to fill the buffer (an extra 10 points of work). And so your actual velocity for sprint X was 34 points. Let’s assume that your average velocity then increases to 32 points.

Now you can use that information to plan the next sprint X+1. You could decide again to save 6 points for buffer:

Team’s velocity (previous sprints): 32

Max Capacity: 32 (assume no vacation/holidays)

Buffer: 6 points (not planned)

Load: 26

In the middle of the X+1 sprint you discover that one of the work items is bigger than expected and an unexpected event pulls you out of work for a while. If you had no buffer, you would not be able to complete the work on time.

But since you had created a buffer, it gives you the flexibility to deal with the unexpected and still complete the work. So at the end of sprint X+1, you complete everything you committed to doing (26 points), delivering on your goal thanks to the buffer you created. Your velocity for sprint X+1 was 26. You may have experienced a drop in velocity, but you were able to deliver 100% of your commitment for the sprint.

By using an interrupt buffer, your plans become more predictable. In this way, your stakeholders are happier, your release dates are more predictable, and everyone is happier.

Remember, velocity is not a measure of performance of a team. A higher velocity does not necessarily translate in a better team. In fact, velocity is just a planning mechanism to help predict the future sprint’s capacity more reliably. In the end, a team that is delivering 100% of its commitment on time is a much better team that another team who delivers a high velocity every sprint, but it’s not reliable and keeps missing deadlines.

By calculating your team’s velocity as an average of the last 3–5 sprints, you can offset the impact of sporadic events and have a more predictable velocity. The goal is to help the team work at a sustainable pace, deliver on predictable commitments, and do work of the highest quality

Valerio Zanini is a Certified Scrum Trainer and can be found at https://www.trulyscrum.com/

Planning with Velocity and Capacity was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some techniques that product managers use to connect with their customers are empathy interviews, observations, and focus groups. But to really understand your users and the challenges they face, the best way is to spend “a day in the life” of a customer. Act, behave, and decide like one of your users. Use the tools that your users would use, perform the activities and make decisions like they would. This way, you can directly experience what it looks like from your customers’ point of view, rather than being told by them during interviews.

This means, get out of the office and pretend to be one of your customers (or User Personas). Sign up for your tools or services and use them to solve your (Persona’s) problem. Sign up for your competitor’s. Try to break (figuratively) your product and then call customer service for support.

How is the overall experience? What’s working well and what could be improved? How does your product compare to the competitor’s? Is it solving your needs or is there something missing?

A day in the life of your customers can be an exciting way to see what your company offers from a different point of view. And why stop there? To build context for everyone on your team, invite your team members to do the same. Take turns, or do it in pairs. Your developers often lack direct understanding of the customers and make decisions based on their personal intuition. Invite them to spend a day in the customer’s life together with you. It will create tremendous context for everyone and open up opportunities for new ideas.

The author of “Lost and founder”, Rand Fishkin, took this idea to the next level. At that time, he was CEO of a company that provided analytics and data tools for online marketing. He contacted the CEO at one of his client companies and suggested a “life swap”: for a couple of weeks they would live each other’s life. They exchanged email passwords, houses, and offices. And they acted as the CEO of each other’s company. This sounds crazy, and it probably was. But it offered incredible insights about what happens on the court, rather than watching it from the stalls.

By doing this, Rand shared, he was able to see with his own eyes the work that his client company was doing and how it was using the tools that Rand’s company sold them. He also noticed that the client was often using competitors’ tools and discovered what was missing in his own product. By fully immersing himself in the client’s life he was able to develop extreme empathy. And this gave him a deeper understanding of his customers’ needs, and created new opportunities for innovative solutions.

Valerio Zanini is co-founder of Spark Engine (https://www.sparkengine.co) and dedicates his time to help product organizations adopt product thinking and drive innovation.

He is also the founder of Truly Scrum (https://www.trulyscrum.com) to help professionals learn, adopt, and master Scrum.

Agile planning in a development team is strengthened by Product practices

It’s all about managing the product

As stated above, a blind application of Agile won’t cure all illnesses. Even the most faithful agilist who diligently executes the practices, will have a hard time reaping the benefits and delivering value to its customers, if the right product management mindset and culture is not in place. A development team cannot do it alone. The organization must provide the culture, the vision, the empowerment needed for success.

I recently was asked to help a large team who was building a strategic digital platform the company direly needed. The team was hard working, putting long hours and solving big problems. But the leadership kept changing the overall vision for this product, and with it the priorities of what to build. For the team is was difficult to focus and getting anything completed before the next change happened. After months of development, they had nothing to show in production. The problem was not with poorly adopted Agile practices. The problem was with poor product practices that didn’t support the application of important principles needed for Agile to flourish. You may get away with poorly implemented Agile practices, but if you don’t have the right product practices you may be wasting your investment or be doomed from the start.

Infusing an effective product mindset is key to the success of a product initiative and to an Agile transformation. Therefore, I always spend as much time working with teams and their leadership in adopting the right product practices as I spend on Agile practices. I make sure that the organization understands the importance and value of having a customer-centric approach, that it understands the customer needs and what benefits the new product would deliver to the end-users. The product team should spend the majority of time in discovery mode, talking with stakeholders and end-users, testing prototypes, refining ideas. This is true not only at the beginning of the project, but also throughout its development.

The market always knows more about your product than you do. Ultimately, the market is the one that decides if it needs the product or not, so it makes sense to learn from it as quickly as possible. Validate your hypotheses with real users, get feedback from them, and measure adoption metrics. Use ruthless prioritization and respect the priorities you set to maximize the value delivered and to give your teams the focus needed to complete the work.

Instead of making a big upfront plan and using Agile practices to deliver that plan one slice at a time, map out all the features you’d like to build, identify a subset, and build an MVP (Minimum Viable Product) that you can bring to market as quickly as possible. Learn what works and what doesn’t, and then iterate on the product plan with the next set of features.

Like a tree, to grow healthy and bear fruit, it needs the proper roots. Adopt and support effective Product practices and your Agile transformation will flourish.

Short-cutting Agile is not the solution

If you browse the world wide web you can find dozens of articles describing would be solutions in making Agile work or getting rid of it altogether. The most recent one I read was “Agile has failed” from the CEO of Unqork. Besides the not-so-subtle marketing push of his platform, he argued that with modern SaaS tools there is no need for Agile anymore because things are faster. We don’t need to inspect and adapt anymore because we are just soooo fast in building things.

But even if we can build a product faster, how do we know that we are building the right product? Whatever minimum investment we are making, we are still spending time, money, and resources into building something. Agile and Product practices give us the guidelines and the boundaries to maximize the value of our investment and deliver a product that customers want.

No-code platforms like Unqork, Salesforce, WordPress, and many others, speed up the development process and make it easier for business people (rather than technical people) to build business applications. Salesforce invented the cloud and pioneered the concept of a pre-made platform that was easy to customize with just business logic and no coding. WordPress allows anyone to build a website by using drag-and-drop modules rather than hard-coding HTML, CSS, etc. Unqork lets business users create applications and digitize forms in a simple and fast way. All this is great.

However, even the most powerful platforms require some technical work for customization and support of specific use cases. Also, I would argue that faster development cycles don’t allow abdicating the need for proper understanding of what needs to be done and what needs to be prioritized. You can build things faster, but if you don’t deliver what users need, your product is destined for the trash bin anyway.

Agile principle #7 states that “Working software is the primary measure of progress”. So, if a team can deliver working software in a faster and easier way, that’s all additional value delivered. You may be working at a complex custom system integration or at a simpler no-code implementation of a new business application. By using no-code or low-code platforms whenever suitable, development teams can speed up the process and provide value to their customers faster. These benefits are important regardless of the technology stack you are employing.

By using Agile practices throughout the development process the team can create transparency, shorten the feedback loop, and improve the quality of its deliverable. These practices span technology and platform boundaries, supporting the team in building the right product and delivering value to the customers. Without these objectives in mind we risk building the wrong thing or limiting the value we deliver.

Where Agile fails

For all its benefits and — let’s be honest — hype, Agile is not the medicine that cures all illnesses. Here are four situations where I’ve seen Agile fail:

1) Just take the pill

Just “doing” Agile doesn’t mean necessarily “being” Agile. And this is an important distinction in terms of empowerment, culture, organization, customer focus, engineering practices, and reaction to failure. “Doing” Agile often results in teams adopting the practices but not understanding the principles behind them. For instance, they may adopt Scrum, work in 2-week sprints, do daily standups, and hold a retrospective at the end of the sprint. At face value, they are “doing” Scrum, and yet they may not see the benefits they expect, or they may feel as burdened as they were before. Often, these teams go through the motions of Agile without really adopting the mindset or the principles.

One example: a development team I recently worked with was given a list of work items at every sprint by their product owner, and that list was always at least twice the capacity of the team. The reasoning was, “better give them more work and getting something as a result, than have them slack”. From the developers’ perspective, they struggled with choosing what to work on and what to skip, multitasking their way through the sprint, and adjusting to a continuous change of priorities. The team members were not empowered, the culture didn’t support trust, and the work was mainly push-down execution focused. The end result? Nothing to show after several sprints of work.

I’ve written about “doing” Agile versus “being” Agile other times in the past. Companies that adopt Agile half-heartily try to “do” Agile but often struggle with the inevitable changes that are required for a transformation to be successful, and with the problems that inevitably Agile brings to the surface and need to be solved. Agile in itself is not the solution. A deeper change is needed to reap the benefits of agility and it often starts from changing the mindset and how the organization approaches work. This is usually where Agile coaches and effective Scrum Masters can help in driving a real transformation.

2) Half-heartily adoption

Sometimes a company is required to adopt Agile practices because of market forces. For example, a key customer demands that all suppliers adopt the same practices — these could be Scrum, SAFe, or others. The company then makes an effort at adopting Agile, often by training large portions of the organization and by establishing Agile teams. Yet, this is often a half-heartily adoption, as the mindset and the overall processes of managing work are not really affected. A symptom of this brings to light a misunderstanding of what Agile is really about: I’ve heard senior leaders say, “I don’t want to adopt Agile because it gives my team the right to do what they want, whenever they want it”. And when these leaders are forced to become more Agile, they inevitably do so half-heartily, hoping that the “wind” will shift soon in a different direction.

Instead, leaders should embrace the Agile transformation as an opportunity. Instead of changing the whole organization at once, select a small target group and infuse a culture of agility there. Give proper direction in terms of vision, priorities, and objectives, then let the team members self-organize how best to do the work. Establish transparency throughout the process, including feedback loops with stakeholders. Inspect and adapt frequently, and provide the support needed for the team members to succeed. Once a small group reaps the benefits, sustain the momentum by expanding Agile practices to other groups.

3) Slicing mechanism

I like this one, not because it’s evil, but because it shows good intentions that are put into action without proper understanding of product development principles. A couple of years ago, a large US bank I worked for embarked in a modernization project to replace its 20+ year old legacy system with a modern Salesforce platform. Its teams spent more than six months documenting in excruciating details all the requirements and features of the legacy system that needed to be ported to the new platform. Then they estimated the amount of work at 12 months, set a deadline, and promised a delivery date to the senior management.

At that point they handed off the requirements to engineering. The engineering teams adopted Agile (more specifically, Scrum) and sliced the work in 2-week sprints. At the end of each sprint, they held a sprint review with the key stakeholders, demoing the work increment and receiving feedback. Then they set off to work on the next slice of the requirements.

Agile practices were just a slicing mechanism and were a way to deliver the work. The whole product had already been planned and detailed, and all engineering was required to do was building it — exactly as specified. There was no concept of discovery of new user needs, of adaptation based on what the team had learned throughout the process, or of prioritizing the backlog of work so that high-priority items were completed early and higher value was provided to the users. Everything had the same importance because, well, everything had to be built. It was a big waterfall project masqueraded as Agile and it failed miserably when the 12-month deadline arrived and the system was only half-built.

4) Forget the big picture

When an Agile team works repeatedly on the same product sprint after sprint, its main focus becomes execution, getting the next set of features done and out in production. While this focus is great, the danger is that the team becomes shortsighted and loses context of the big picture. Why is the team building the product? Why is the next set of features important for the customers? Why should the team continue building this product instead of something else?

In order to answer these questions and elevate the views of the Agile team, it’s important for the Product Owner to understand and uphold its role within the team. The Product Owner should continually provide the context the team needs to understand where the product fits within the larger vision and strategy; they should invite the team members to do “gemba walks”, meet customers, and learn directly from them about needs and pain-points; they should manage the backlog with a critical eye, not focusing on just execution, but also in discerning if the team’s energy would be best spent on working on something completely different. A Product Owner I know makes the point of reviewing the product’s vision with the team every sprint, to keep it fresh in everybody’s memory and align their work to the bigger objective.

About the author

Valerio Zanini is the CEO of 5D Vision, a company that helps organizations spearhead their Product and Agile practices through training and hands-on coaching. He’s also the author of “Deliver great products that customers love” and the co-author of “Sprint Your Way to Scrum”. Valerio lives in Washington, DC and travels worldwide.