The book "Brilliant Agile. Flexible project management with Agile, Scrum and Kanban

What is flexible project management?

Does your project need it?

Will this benefit?
')
Want to understand how flexible project management works and take advantage of this powerful approach? Then you picked the right book.

“Brilliant Agile” is not just another story about methods and processes, focusing on real-world examples of using Agile in business environments.

Here you will find practical tips and specific techniques for implementing Agile to make your project a success and implement flexible management in your organization.

ABOUT THE AUTHORS

Rob Cole (Rob Cole) is a project management consultant with over 20 years of experience. He specializes in troubleshooting projects and mentoring. Rob has been involved in the Agile community from the earliest days and is a practicing Scrum Master.

Edward Scotcher - Lead Product Manager, Project Manager, Coach and Agile Coach. He specializes in helping organizations, teams, and individuals to adapt Agile for practical and long-term use.

PREFACE OF THE SCIENTIFIC EDITOR

When I was offered to review this book, I was very happy, because I am always glad to any opportunity to support the development of Agile beyond the limits of IT application. And this is exactly what this book does.

She is:

• about the same Agile that everyone is talking about;
• needed by those who do not know anything about Agile and really want to get acquainted with these approaches;
• written by absolute advocates of flexible approaches;
• written in the style of Agile (the authors use very interesting images, examples and illustrations, which are rarely found in academic literature);
• suitable for universal reading and application;
• does not contain the language and terminology that scare us in the technical IT-literature, and is easy to read.

You will get answers to a series of questions:

• What is flexible project management and will it benefit you?
• How to benefit from using Agile?
• What methods and processes do Agile perform?
• Is your organization or project suitable for using Agile?
• How to solve the most common problems associated with Agile?

And how, in the end, to implement it in any project?
I sincerely recommend the book "Brilliant Agile" for reading and application. It’s a pity that I didn’t have such a book in my hands about five years ago, when I started to apply all this in my work ...

Funtov Valery Nikolaevich
ee n., PMP, Agile Coach and Trainer

PASSAGE FORMING PROJECT TEAM

Many people diligently put together the best people they can find — specialists with relevant experience, experts in their field — and then spoil everything without providing an adequate understanding of business and leadership. Do not put the cart before the horse! It is important to achieve the right level of business involvement in the project - to include one person who understands the vision of the business. This is not just practical and pragmatic, but also logical from a common sense point of view.

In Agile, this person is usually called the "owner of the product" (Product Owner), but there are options for the name. Of course, in this brilliant book, it would be worthwhile to call him a “product manager,” but first we’ll stop on a simple definition. The product owner represents the interests of the business and the end user. The product owner lives, breathes and dreams of the product and how it should be. Such people know exactly what they want, even if they don’t know how to achieve it. They are leaders who can quickly make decisions and defend them.

Agile-team is a diverse, multifunctional group of individuals who are able to embody the vision on behalf of the business. Simply put, they have everything they need to do the job properly. The owner of the product points the way only in terms of business vision, but it is also a great contribution to the work of the team. The team consists of people with flexible thinking, not afraid of change and do not consider that bureaucracy is the solution to all problems. Confident decision makers, proactive initiative, active people will be best suited.

The entire team should be involved in defining the vision and all aspects related to product release. If you do not, there will be difficulties.

CREATING A MAGAZINE OF REQUIREMENTS

When a vision is defined and the benefits the project should bring, the next step for the project team is to write the requirements in as much detail as possible. At the center of each project is a list of requirements, which in Agile is called the product requirements log, or backlog (Product Backlog). It replaces the traditional, detailed terms of reference and is a list of important business ideas. Elements of the magazine are always focused on the end user of the product, even when it comes to the technical part of the project. They should be clear to anyone.

It is important that from the very beginning the project team develops a collective vision, to be sure that everyone understands the goals, the content of the project and the ways of their conceptualization. Make sure that everything is on the same wave from the very beginning - it’s easier than trying to fix a two-thirds finished product later. The diversity of the team is also important, because it is important to be able to look at the problem from different angles. If necessary, specialists will help each other.

How to make things go awry right from the start

• Declare that Agile is a universal remedy, even for areas not intended for it.
• To say that everything is obvious and any fool can cope, so no training is needed.
• Assuming that Agile is infallible, and failures are due to personal flaws.
• Set unrealistic goals and deadlines, justifying it by the fact that anything is possible in the wondrous new world of Agile.

Define basic functionality

The goal is to compile a summary list of what is needed to embody the vision of the project. There are several ways to do this, and our favorite approach is to think about each step of the client to plan the workflow .


Create functional groups

Once the workflow is defined or compiled, gather together all the ideas about what needs to be done at each step of this path. Such a grouping of these elements provides a description of the functionality of the step and can be called functional groups. Some details will be absolutely necessary, while others can be categorized as pleasant additions. They should be streamlined from the start.


Priority characteristics

Based on the project’s vision and common sense, determine the priority of each element in descending order, from the most important in each list.


Definition of first release

As soon as the above is done, consider every important step in moving towards the customer from the first day to the realization and what is the most valuable part of the idea within these steps. Such a choice can be difficult and ultimately depend on the opinion, but the opinion of the customer — or the one who represents his business — has a decisive role. The end result of the steps is the acceptable minimum for the customer that the project should achieve in this step. This is usually called the minimum viable product (minimum viable product, MVP) or the minimum viable release (minimum viable release, MVR).


One of the big advantages is the quick receipt of important feedback from end users, however, in order to form an opinion, they need something rather substantial. It is impossible to get meaningful feedback on the technical process, but on the new order form VegBox - completely. Naturally, this will be part of a minimally viable product.

It is worth remembering that the more there will be in a minimally viable product, the more time it will take to get feedback, whereas if the product is too small, there will not be enough information to get feedback. You will have to find a balance between profit and risk - there is no universal rule here. Try to find a point at which you will receive helpful feedback on something that will help you make informed decisions. It will be useful for market analysis.

Also pay attention to the terms. For some, the word “release” will mean an available product for use, for others, a product intended for testing by a closed group. Remember that there is always the opportunity to first present the product to a small group, and only then release the product accordingly. Most importantly, do not make assumptions that everyone understands the terms in the same way! There are no absolutely correct approaches - choose the one that suits you best.

Adding features

As soon as it is determined that there will be a minimum viable product (MVP) or minimum viable release (MVR), real fun begins. Additional functionality or new product features can be added in parts or be part of a large release. This is called incremental delivery, and businessmen love it very much. No more long years of waiting for one big release with all the “whistles”. Product release in agile development occurs quickly and frequently. And, again, it is the customer who determines what and when to release. At a minimum, a single release should contain one characteristic tested by practice.

RECEIVING THE INFORMATION

The results of our first release - our MVP - are quite ephemeral, and we need more details to turn them into a full-fledged product. The advantage of these results is that at this stage we formulate ideas, so it would be aimless to develop a full-fledged product profile that will not necessarily be used. It is more than enough to develop a common vision and formulate an MVP, while not implementing the product itself. At the next stage, we have to find out the positive and negative sides of the product. The classic tool for solving this problem is the user story.

tell me the story

User stories (user story) - short simple descriptions of the characteristics of the product from the point of view of the person who is going to use it. Usually this is a user or buyer. User stories usually follow a simple format.
Being a <user type>, I need a <target> for <reason>.


A user story is an abstract concept that provides enough information so that the team can realistically assess the resources needed for the project. User stories are often written on stickers or cards, which are then hung on the walls or laid out on tables to facilitate the planning process.

The user story allows you to focus on discussing the characteristics of the product, which is an important step after developing a basic understanding of these characteristics.

No one forces you to use user stories. However, these stories remind us of the importance of group discussions, and the results of these group discussions are often more important than a detailed work plan.


During these discussions, key aspects of the product’s main characteristics are identified. Remember, the recordings themselves do not mean anything, but lively collective communication allows us not only to work out the fundamental details, but also to keep a fresh look at the project. Winning in every way.

»More information about the book can be found on the publisher's website.
» Table of Contents
» Excerpt

For Habrozhiteley 20% discount on the coupon - Agile