The book "Agile for all"

Agile provides real and effective answers to a question that prevents managers from sleeping: “How to remain successful in a rapidly changing and unpredictable world?” This methodology has already won the market, proving itself to be one of the best approaches for software development and delivery. “Agile for All” is addressed to practitioners, from this book you will learn how entire organizations — from product managers and developers to marketing specialists 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 accomplish 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 - which allow implementing the Agile-approach in different areas of activity.

Agile practice immersion: “whoopee!”

When I worked as a product manager, I had a lot of ready-made Agile practices and frameworks on hand that I could use in my team. These frameworks dealt exclusively with the needs of software development teams, and were tested in practice by thousands of specialists, many of whom kindly shared their experience 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 in relation to the completely different goals of the new teams. The results of our work - analytical reports received after months of long consultations, seminars on the formation of the image of the client - were significantly different from software products, since we no longer had a clear and objective way to test the performance of these results. Moreover, in our roles, all borders have been erased compared to the roles in the development team, since now we all did a common thing, not hiding under the titles “visual designer” or “frontend developer”.
')
Caught in this procedural confusion, we tried to cope with a standard set of problems that arise in front of teams that produce non-technical results. The subject of these results imperceptibly and inevitably expands as we work, especially when we moved from intermediate states (sketches) to full-fledged documents and presentations. The client-oriented purpose of each result sometimes remained unclear to us, so in such cases we expanded the subject of the study so that we would not “miss” anything. Despite the fact that we liked working together, we did not always understand who was responsible for what, when and why.

It is worth noting that the “statutory” Agile-methods did not always fit perfectly into the structure of our team or the results, but we understood that the underlying Agile-principles are capable of keeping 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? Will we be able to eliminate all working misunderstandings thanks to timely cooperation? Are we ensuring that the introduction of new information into the work process does not turn into a complete processing of the material?

We started asking these questions regularly at planning and retrospective meetings, changing the work process according to our ideas and answers. After experimenting for about a year, we turned our approach into the WHPI practice (read as “woo!”, Or “Why, How, Prototype, Iteration”). WHPI consists of four steps, which are listed in Table. 6.3. To begin, you collectively decide why you put the result in the first place, what impact you expect and what value your client will receive. Then 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 you want to create for the client, and then iterate this prototype and check if he was able to achieve the goals you set in the first step.


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

STEP 1: Why

For this step, we collect several key project participants (2–4) and quickly discuss a set of objectives or project results. Whenever possible we gather in a single physical (or virtual) space and work through all the ideas recorded on the 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 essential truth: if you are not able to define the main goals in 15–30 minutes, you need to get more information before moving forward. Several times at this stage we understood that it was necessary to conduct basic research to confirm our assumptions or to ask our clients a few clarifying questions. Having created a single initial set of “why” goals, we put them at the very center of attention so that they could direct the rest of the workflow.

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

• Deliver an understanding of the driving force behind the project to top management.
• Remind participants of the key points of insight at the meeting.
• Awaken the interest of employees who did not attend the meeting.

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

STEP 2: How to

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

In the previous section, we established the following “why”: “To arouse the interest of employees who did not attend the meeting”. Before using this method, we define a similar goal as follows: “Explain the language and frameworks to the participants so that they can share information with their colleagues.” But after we began to separate “why” from “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 the process of achieving goals be simplified? Is language and frameworks something that 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 we expected, or to understand that the desired result is significantly different from what we planned to achieve.

Given the "why" of the last section, we can distinguish the following "how" to direct the workflow:

• Create a short two-page analysis report that can be easily understood and distributed.
• Use memorable quotes from participants to convey insight into the driving force to top management.
• Use photos from meetings to remind participants about moments of insight.
• Promote positive outcomes and limit the amount of detail to keep the outcome focused and generate widespread interest.

As you can see, “how” provides a plan of action or a plan for creating all the necessary conditions for achieving the goals set. 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 a result much faster, regardless of the approach you use in the next steps.

STEP 3: Prototype

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

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

In other words, we “create conditions for achieving the maximum number of project goals (“ why ”), using approved approaches and tools (“ how ”), in the same format and with the same timeframe 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, fastened together and filled in by hand (with numbered pages, headings, short summaries 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 the “working software”. Things that look great in planning models and documents do not work in presentations, reports, or 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 assign one team member to be responsible for creating the primary prototype. Often it becomes a matter of free time: who can set aside a few hours over the following days to make the first attempt? We found that two hours of work is a standard constraint for prototyping, which allows you to create a basis for comparison with project goals and leaves room for development and iterations.

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 pluses / suggestions format, in which each team member tells about successful aspects and about elements that need to be improved. (We used the same format in our retrospectives, so we quickly returned to it.) We gradually transformed this format into a so-called “protect, exclude, improve” discussion. After the presentation of the prototype, participants share three types of feedback:

• What should be left for the next iterations, since it most closely matches all “why”.
• 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 contribute to achieving the necessary “why”.

The key difference between this approach and the traditional pluses / proposal format is in an open discussion of what needs to be excluded from the following iterations. We began to use this approach after we discovered that the most successful changes for iterations occur after the elimination, not the addition, even in the largest projects. An open “exception” during discussions allows participants to keep track of aspects that can be removed, which provides more accurate and focused results. Summing up all three types of reviews according to the pre-agreed “why”, we solve 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 time-limited iteration of the prototype. In some cases, this leads to a complete reworking 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 successive rounds of iteration can be controlled by one person who created the original prototype, or by any other team member. By the second or third iteration, the prototype is often in the hands of the person who is primarily responsible for the presentation of the finalized product. Moreover, by the second or third iteration, the prototype looks almost complete and ready for final refinement.

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

For Habrozhiteley 25% discount on the coupon - Agile

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