How to Explain Agile to Grandparents in Simple Words

If you’re new to project management and the big Agile world, there are many aspects you have to consider to successfully apply Agile to your business. This might seem overwhelming for the first sight.

That’s why we’d like to propose 15-minutes text for beginners that covers the Agile basics every PM freshman needs to know.

We are not going to discover continents (since dozens of fundamental articles about Agile have already been written), we are just glad to share brief extracts from one amazing post by Henrik Kniberg who published it on Crisp blog. Here’re the most interesting moments in our interpretation:

*all pictures are taken from the video published in the original article

Imagine that we describe the Agile development concept from the perspective of a Product Owner.

Agile roles

This is Pat. She is the Product Owner. She is not aware of the tech details of the product, but she has a vision of the overall picture. She knows why the team is making the product and what problems it will solve. She talks about it all the time.

These are stakeholders. They use the product, support it, or somehow involved in the development process.

These are user stories. They expressed the needs and wishes of stakeholders. Stories typically correspond to a feature or a use case. There are many ideas that stakeholders propose and Pat friendly helps them to divide these ideas into distinct user stories.

Example: if consider a flight booking system, its users need to search for a flight. That would be a user story.

These are developers. They will build the system.

Capacity

Since the team uses a flexible development methodology, they do not save all these stories until a large release, they release them immediately and as often as possible. Usually, they release 4-6 user stories per week. This is about their capacity and it is easy to measure. Just count the number of stories released per week.

Some stories are big, so they can be counted as two, some of them are small – they can be counted as a half.

In order to maintain this rhythm and not to get bogged down in manual regression testing, the team is working hard on automatic testing and constant integration. Therefore, it is necessary to write automated tests for every feature, and most of the code has built-in autotests.

However, there are many stakeholders and their requests cannot be satisfied with 4-6 stories per week. And this a problem.

Every time we implement a user story, they have a few more ideas, from which even more queries flow.

Overflow

Overflow is what happens if we do everything they ask of us.

Let’s suppose the team takes 10 new stories per week. If the input is 10, and the output is about 4-6, then they will get overloaded with work. They will be in a hurry, will switch between tasks, lose motivation, and decrease their productivity as a result. This is a losing strategy.

In this case, Scrum and XP (Extreme Programming) methodologies use the “yesterday weather” approach. The team states: “We’ve finished 4-6 features per week in the past few weeks, so which 4-6 features will we build this week?” The responsibility of the Product Owner is to correctly select which user stories will be implemented this week.

Kanban recommends limiting it to several tasks – use WIP limits. Suppose the team decides that 5 user stories on which they can work simultaneously without overloading are enough.

Both approaches perform well and both of them create a queue of tasks, which in Scrum is called Backlog, or a prioritized list of tasks.

This queue also needs to be managed. If stakeholders request 10 stories per week, and the team implements 4-6 stories, then this queue will become longer and longer. Your backlog will be scheduled six months in advance soon. It means that one story will wait 6 months for the release.

Saying “NO”

Saying “NO” is the only way to stop the queue from going out of the control. “No” is the most important word for the Product Owner. Pat should train it every day in front of the mirror.

Saying “Yes” is pretty easy. But the more important task is to decide what not to do and be responsible for it. The Product Owner also determines the sequence of what we are doing now and what later. This is a difficult job and should be done with the development team and at least one stakeholder.

In order to prioritize properly, Pet must understand the value of each story.

Decision making

Some stories are really essential, and some seem like just bonuses. It will take a couple of hours to develop some stories, and months to develop others.

What is the correlation between story value and its size? None is the answer. Bigger does not mean better. The value and complexity of a task are what helps Pat to understand how to prioritize professionally.

How does Pet determine the value and the size of the story? She does not it at all, as it’s just a guessing game.

And it is better when everyone participates. Pat constantly communicates with stakeholders to know the value of each story, she communicates with the development team to know the amount of work, but all this is an approximate guess without exact figures.

There will always be fails in the beginning and that’s ok. Communication is much more valuable rather than the actual numbers. Every time developers release something new, we will learn more info.

Prioritization is not enough. To release stories quickly and often, you need to break them into pieces that can be done in a couple of days. We want small and clear stories at the beginning of the funnel and large and indefinite at the end. By doing this break-down, we can use our latest discoveries regarding the product and user needs. This is all called Backlog refinement or grooming.

Pat holds a meeting to groom the Backlog every Wednesday from 11 to 12. Usually, the whole team (and sometimes stakeholders) attend it. The content of the meetings can be different with the focus on evaluation, breakdown of stories, or acceptance criteria.

The IT product owner must constantly communicate with everyone. Successful Product Owners distinguish 2 components of success: passion and communication.

Risks

There are different kinds of risks:

• Business risk: “Are we doing the right thing?”
• Social risk: “Can we do what we need?”
• Technical risk: “Will the project work on this platform?”
• Risks with the cost and timing of implementation: “Will we have time and will there be enough money?”

Knowledge can be considered as the opposite of risk. When uncertainty is big, we focus on acquiring knowledge — interface prototypes or technical experiments.

The tradeoff between knowledge values and customer values

From the point of view of the customer, the curve looks like this:

As uncertainties are reduced, we can concentrate on values for the customer. We know what to do and how. It remains only to do. After the main stories have been implemented, we will make bonus features or launch a new project.

The tradeoff between short-term and long-term thinking

What to implement first? Should we urgently fix bugs or start developing a stunning feature that will amaze users? Alternatively, should we do a complex platform upgrade that will speed up work in the future? It is necessary to constantly maintain a balance between reactive and proactive work.

The tradeoff between “doing the right thing”, “building the thing right” and “doing them fast”

Ideally – doing all three at the same time, but in reality, you have to choose.

Suppose we are here. We are trying to create the perfect product using the perfect architecture. If we spend a lot of time, we can not get into the “marketing window” and we will have cash-flow problems.

or

We make a quick product prototype. For the short term, this is not bad. In the long term – we get a technical risk. And the speed of development will decrease to zero.

or

We are here, creating a beautiful cathedral in record time. But the user did not need a temple, he needed a camper van.

There is a healthy confrontation between roles in Scrum

• The Product Owner focuses on building the right things.
• The team focuses on building things right.
• The Scrum Master or Agile coach focuses on shortening the feedback loop.

It is also worth emphasizing the importance of speed, as a short feedback loop speeds up learning. This allows us to quickly find out what things are right and how to build them correctly.

The tradeoff between the development of a new product and the improvement of the old one

A product can never be fully completed because it constantly needs changes. When the team starts working on a new product, what happens to the old one? Transferring a product from one team to another is very expensive and risky. Usually, the team supports the old product by developing a new one.

Therefore, the concept of “Backlog” refers not to the product but to the team. The backlog is a list of things that the Product Owner wants from the team. And a set of stories for different products. The PO must constantly choose the relevant for implementation.

Destruction of stories

From time to time, stakeholders will ask the Product Owner: “When will they release my feature?” Or “How many features will be released by Christmas?”. Pet must be able to manage user expectations. And manage them realistic.

There are two trends: optimistic and pessimistic. The distance between trends shows how unstable the speed of the team. Over time, these trends will stabilize and the cone of uncertainty will decrease.

Suppose, one of the stakeholders asks about when this feature will be done. This is a fixed-scope, variable time question.

Pat uses two trend lines to answer. The answer is – in April or May.

The stakeholder asks Pat: “How much will be done by Christmas?”

That’s a fixed time, variable scope question. The trend lines tell us “We’ll most likely finish all these, some of these, and none of these.”

Next, the stakeholder asks: “Can we do these features by Christmas?” This is a fixed time and fixed scope question.

Pat says “No, it ain’t gonna happen”, and continues as “here’s how much more time we need”.

It’s better to reduce scope than to extend time. Pat makes the choice easy by saying “we could deliver something here, and the rest later. Or we could deliver nothing here and the rest later. What do you prefer?

Multiple teams

Ok, but what if we have a larger project with multiple teams? The model will be the same – capacity management, communication with stakeholders, making decisions about the rejection of user stories. The speed is equal to the sum of the speeds of all teams.

Prediction can be general or per team. Product Owners have an additional challenge – communicating with other Product Owners. It is necessary to organize the work on Backlogs to minimize dependencies and ensure synchronization. In fact, large projects require the CPO (Chief Product Owner) to sync all others.

OK, that’s it!

What do you think about such Agile product ownership quick explanation? Was it useful for you?

In order to consolidate this information, you can once again get this it from this video: