Agile for All Book

Agile provides real and effective answers to a question that keeps executives awake: “How to stay successful in a rapidly changing and unpredictable world?” This methodology has already conquered the market, proving that it is one of the best approaches for creating and delivering software. Agile for All is addressed to practitioners, from this book you will learn how entire organizations - from product managers and developers to marketers and executives - can use a “flexible” approach.

Matt LeMay simply and without slang explains what Agile is and offers concrete and effective steps that allow any team to realize their tasks as efficiently as possible. You will find many examples that are suitable for any type and size of organization - from start-ups to large enterprises - that allow you to implement the Agile-approach in various fields of activity.

Dive into Agile practice: “whoopee!”

When I worked as a product manager, I had many ready-made Agile practices and frameworks on hand that I could use as a team. These frameworks relate solely to the needs of software development teams and have been tested in practice by thousands of experts, many of whom have kindly shared their experiences in the form of accessible literature and blog posts.

However, when I started working as a consultant, I could not immediately understand how to use these methods with respect to completely different goals of the new teams. The results of our work - analytical reports obtained after months of long consultations, seminars on the formation of the image of the client - significantly differed from software products, because we no longer had a clear and objective way to verify the performance of these results. Moreover, in our roles, all boundaries have been erased compared to roles in the development team, since now we all did a common thing, not hiding under the titles of “visual designer” or “front-end developer”.

Caught in this procedural mess, we tried to cope with a standard set of problems that arise for teams that produce non-technical results. The subject of these results imperceptibly and inevitably expands as we work, especially when we switched from intermediate states (sketches) to full-fledged documents and presentations. The customer-oriented purpose of each result sometimes remained unclear for us, therefore, in such cases, we expanded the subject of research so as not to “miss” anything. Despite the fact that we liked working together, we did not always understand who, for what, when and why was responsible.

It is worth noting that the “statutory” Agile methods did not always fit perfectly into the structure of our team or the results, however, we understood that the fundamental Agile principles could keep us in the right direction. Therefore, we began to ask ourselves questions that formed the basis of this book: how clearly do we understand the needs of our client? Can we eliminate all working misunderstandings through timely cooperation? Do we make sure that the introduction of new information into the workflow does not turn into a complete processing of the material?

We began to ask these questions regularly at planning and retrospective meetings, changing the workflow to reflect our ideas and answers. After experimenting for about a year, we turned our approach into a WHPI practice (read as “woooops!” Or “Why, How, Prototype, Iteration”). WHPI consists of four steps, which are given in table. 6.3. To begin with, you collectively decide why you put the result in first place, what impact you expect and what value your client will receive. Then you decide how you will provide this value, how the final result will look. Finally, you instruct one of the team members to create a prototype for a limited amount of time, reflecting the experience that you want to create for the client, then iterate this prototype and check if it was able to achieve the goals,


We found that WHPI is a powerful Agile tool that can be embedded in any team, regardless of their tasks and goals. Below is a brief description of each WHPI step, and some tips for implementing and using these methods as part of your team.

STEP 1: Why

For this step, we gather several key project participants (2–4) and quickly discuss a set of project goals or results. If possible, we gather in a single physical (or virtual) space and work out all the ideas recorded on stickers during the work process. Usually these meetings last from 15 to 30 minutes. Although such time frames may seem tough and inconvenient for such important meetings, they reflect one significant truth: if you are not able to determine the main goals in 15-30 minutes, you need to get more information before moving forward. Several times at this stage, we realized that it was necessary to conduct basic research to confirm our assumptions or to ask our clients some clarifying questions. By creating a single initial set of “why” goals,

For example, when we develop an analytical report after a meeting, we often write three main “why” on stickers:

• ???? To convey an understanding of the driving force of the project to senior management.
• Remind attendees of key insights at the meeting.
• Arouse interest among employees who did not attend the meeting.

Please note that none of these points directly indicates how we are going to achieve our goals - more on that later!

STEP 2: How

Having set the goals of the project, we move on to the difficult task of determining how to achieve them. We often call this step “definition of tools” - that is, when we know what we will do, we need to think about tools and approaches. I recommend moving from “why” to “how” with the same meeting participants. Often, defining a “how”, you understand why at least one main goal of the team of “why” is actually a “how” step at the executive level.

In the previous section, we identified the following “why”: “Arouse interest among employees who did not attend the meeting.” Before using this method, we define a similar goal as follows: "Explain to participants the language and frameworks so that they can share information with their colleagues." But after we began to separate the “why” from the “how”, we realized that we had missed two key questions: why is it important for people to share these tasks with colleagues and how can we simplify the process of achieving goals? Is language and frameworks what people really need? As we managed to discuss in this book, priority attention to customers and their needs often helps to reduce the amount of work that we expected, or to understand that the desired result is significantly different from what we planned to achieve.

Given the “why” from the last section, we can identify the following “how” to direct the workflow:

????

• Create a short two-page analysis report that can be easily understood and disseminated.
• Use memorable quotes from participants to convey understanding of the driving force to senior management.
• Use meeting photos to remind participants of insightful moments.
• Promote positive outcomes and limit the amount of detail to keep the result focused and generate widespread interest.

As you can see, “how” provides an action plan or plan to create all the necessary conditions to achieve the intended goals. This step determines the form of our result, directly addresses our “why” and provides clear and moving boundaries to prevent loss of control over the desired results. Such a clear plan allows you to delegate tasks to achieve results much faster, regardless of the approach that you use in the next steps.

STEP 3: Prototype

By defining “why” and “how,” we are ready to create a time-limited prototype. The word "prototype" can mean many things in different contexts. In the context of this method, we define a prototype as follows:

????????

• A prototype is not a model or a planning document; it is created in the same format as the desired result or outcome. For example, the “prototype” of a presentation with slides is a presentation with slides. The “prototype” of a printed brochure is a printed brochure.
• A prototype is created in a limited and predetermined period of time. (Created as part of time-boxing.)

In other words, we “create the conditions for achieving the maximum number of project goals (“ why ”) using approved approaches and tools (“ how ”), in the same format and with the same time frame as the desired result. In the case of small projects, such as posters, the initial prototype may look like a finished result. In the case of large projects, such as a forty-page report, the initial prototype can be 20 full pages folded in half, stapled together and filled in by hand (with numbered pages, headings, brief results and places for images).

As we discussed in Chapter 3, our goal here is to get as close as possible to the client’s experience by creating our own version of “working software”. Things that look great in models and planning documents do not work in presentations, reports, and at meetings. Verification of the initial results using the prototype method helped us to penetrate the client’s experience, reduce the number of improvements and analyze the initial assumptions in more detail.

As a rule, we designate one team member to be responsible for creating the primary prototype. Often this becomes a matter of free time: who can set aside several hours over the next days to make the first attempt? We found that two hours of work is the standard limitation for creating a prototype, which allows you to create a basis for comparison with the goals of the project and leaves room for development and iteration.

STEP 4: Iteration

After creating the first time-limited prototype, the original team of participants (or part of the team) is assembled to analyze the prototype and discuss the next iteration. Our first discussions were held in the plus / suggest format, in which each member of the team talks about successful aspects and about elements that need improvement. (We used the exact same format in our retrospectives, so we quickly returned to it.) We gradually remade this format into the so-called “protect, exclude, improve” discussion. After the prototype is presented, participants share three types of reviews:

?????????????

• What should be left for the next iterations, since it corresponds to all the “why” as much as possible.
• What can be excluded from the following iterations, since it does not correspond to all the “why”.
• What should be improved for the next iterations, since it can still help achieve the necessary “why”.

The key difference between this approach and the traditional plus / offer format is an open discussion of what needs to be excluded from the following iterations. We began to use this approach after we found that the most successful changes for iterations occur after exclusion, not addition, even in the largest projects. An open “exception” during discussions allows participants to track aspects that can be removed, which provides more accurate and focused results. Bringing all three types of reviews into line with the previously agreed “why”, we resolve all potential conflicts, avoid awkward moments and keep the project in the right direction.

After collecting feedback, one of the team members transforms these reviews into another prototype time-limited iteration. In some cases, this leads to a complete revision of the last prototype (for example, a revision of the presentation). In other cases, this leads to the creation of a new prototype based on old prototypes (for example, a report on the results in Word based on handwritten prototypes). These consecutive iteration rounds can be controlled by one person who created the initial prototype, or by any other team member. By the second or third iteration, the prototype is often in the hands of the person who bears the main responsibility for presenting the modified product. Moreover, by the second or third iteration, the prototype looks almost complete and ready for final revision.

»More information about the book can be found on the publisher’s website
» Contents
» Excerpt

For Khabrozhiteley 25% discount on coupon - Agile

Upon the payment of the paper version of the book, an electronic book is sent by e-mail.