David Anderson - Kanban. Kanban

David J Anderson

Successful Evolutionary Change for Your Technology Business

Published with permission from Lean Kanban Inc.

We thank the Lean Kanban Community Russia represented by Alexey Pimenov, Vyacheslav Tsyrulnik, Anton Manin, Sergey Baranov and Igor Filipyev for their help in preparing the publication.

No part of this book may be reproduced in any form without the written permission of the copyright holders.

* * *

Dedicated to Nikola and Natalie

Foreword

I always pay attention to the work of David Anderson. I met him in October 2003 when he sent me a copy of his book Agile Management for Software Engineering: Applying Theory of Constraints for Business Results. As the title suggests, the book was heavily influenced by Eliyahu Goldratt's Theory of Constraints (TOC). 1
Theory of Constraints is a popular production management methodology developed in the 1980s by Eliyahu Goldratt, which is based on finding and managing the key system constraint that determines the success and efficiency of the entire system as a whole. Note. ed.

Later, in March 2005, I visited David at Microsoft, by which time he was working closely with cumulative flowcharts. Even later, in April 2007, I had the opportunity to observe how the breakthrough kanban system that he implemented in Corbis works.

I give this entire chronology so that you get a feel for the unstoppable pace at which David's managerial thinking is advancing. He does not hold on to a single idea, trying to fit the whole world into it. On the contrary, he tries to consider the problem as a whole, is open to various solutions, tries them in practice and evaluates the principles of work. You will see the results of this approach in this book.

Of course, speed is good as long as it's in the right direction, and I'm sure David is moving in the right direction. I especially admire the latest work with kanban systems. I have always believed that the principles of lean can be directly applied to product development, as opposed to the ideas of TOC. Moreover, back in October 2003, I wrote to David the following: “One of the main weaknesses of CBT is the underestimation of the importance of party size.

If your top priority is to find and fix the constraint, then that often means you're just solving the wrong problem." I still believe this statement is true.

At our meeting in 2005, I again suggested to David to look beyond just focusing on bottlenecks in TOC. I explained to him that the hype of the Toyota Production System (TPS) had nothing to do with finding and eliminating bottlenecks. Toyota achieves productivity gains by reducing lot sizes and variability, which reduces the amount of inventory required. It was the reduction of such inventories that led to the achievement of economic benefits, and this was made possible by such work-in-process reduction systems as kanban.

In 2007 I visited Corbis. The result of the introduction of the kanban system looked impressive. I pointed out to David that he had greatly improved the kanban approach used at Toyota. Why did I think so? The Toyota Production System is optimized to handle repetitive and predictable tasks with uniform duration and uniform delay costs. Under these conditions, it is quite correct to use approaches such as FIFO-prioritization (“first in, first out”). It is also quite correct to block the receipt of work if the limit of incomplete tasks is reached. However, if we are dealing with non-repetitive, unpredictable activities with different durations and different delay costs, these approaches cannot be considered optimal - and this is exactly the case with software development. We need more advanced systems, and this is the first book that describes them in practical detail.

I would like to warn readers about a few things. First, if you think you know how kanban systems work, then you probably mean the ones used in lean manufacturing. The ideas in this book are much more advanced than the simple systems that use static WIP limits. 2
WIP - work in progress, the number of tasks in progress. Note. ed.

FIFO scheduling and single class of service. Please pay attention to these differences.

Second, don't think that this approach is a visual control system. The visualization of work in progress that is achieved with kanban boards is very useful, but it is only a small aspect of this approach. If you read this book carefully, you will find a lot of interesting things in it. The most valuable information is hidden, for example, in such aspects as the structure of the processes for receiving and submitting tasks, managing irreplaceable resources, and using service classes. Do not get distracted by the visual part, otherwise you will miss the most exciting moments.

Third, don't discount these methods just because they seem too easy to use. Ease of use is the result of David's ideas on how to get maximum benefit with minimum results. He knows the needs of practitioners well and has paid serious attention to what really works. Simple methods show high stability and almost always lead to the best long-term results.

This is a fascinating and necessary book and deserves careful study. The level of benefit you derive from it depends on how seriously you take reading. No other book will introduce you to these advanced ideas better. I hope you enjoy it as much as I do.

Don Reinertsen,

Part I
Basics

Chapter 1
Solving the Agile Manager's Dilemma

In 2002, I was a development manager at Motorola's remote office in Seattle of Motorola's mobile phone division (it was called PCS) and found myself in a difficult situation. My department was part of a startup that Motorola had acquired a year earlier. We have developed network software for wireless data transmission, such as wireless download and instrument control. These back-end applications were part of integrated systems that were tightly coupled to mobile phone client code, as well as other elements in telecommunications networks and operational infrastructure, such as billing. Deadlines were set by managers who did not pay attention to the engineering complexity of the project, its risks, or its scale. The core code evolved from a startup, with many originally planned features being delayed until later. One senior developer insisted that our products be called "prototypes." We desperately needed to increase productivity and product quality to keep up with the demands of the business.

In my daily activities in 2002 and in the process of working on the previous book 1
Anderson, David J. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Upper Saddle River, NJ: Prentice Hall, 2003.

I was concerned mainly with two issues. First, how to protect the team from the ever-increasing demands of the business and achieve what is now called the “optimal pace” in the agile community. And second, how can I successfully implement an agile approach throughout the organization, overcoming the inevitable resistance to change?

Finding the right pace

In 2002, the agile community thought that optimal pace was simply a “40-hour workweek.” 2
Beck, Kent. Extreme Programming Explained: Embrace Change. Boston: Addison Wesley, 2000. Russian Edition: Beck K. Extreme Programming. St. Petersburg: Peter, 2002.

Principles of the Agile Manifesto 3
Beck, Kent et al., “The Principles Behind the Agile Manifesto.” http://www.agilemanifesto.org/principles.html. Russian translation: http://agilemanifesto.org/iso/ru/principles.html .

They said that “agile processes contribute to optimal development. Sponsors, developers and users must be prepared to maintain a constant pace indefinitely.” Two years earlier, my team at Sprint PCS kept hearing from me that "software development at scale is a marathon, not a sprint." If the team members had to maintain a constant pace in the process of working on a year and a half project, then they could not be allowed to burn out in a month or two. The project needed to be planned, budgeted, timed, and evaluated to ensure that team members spent a reasonable amount of time working each day and weren't too tired. As a manager, my task was to achieve this goal and meet all business requirements.

When I was in my first managerial position (it was in 1991, at a start-up that made video capture boards for personal and smaller computers), the CEO 3
Chief Executive Officer - Chief Executive Officer (CEO). Note. ed.

He said that the management had an “extremely negative opinion” about me. I always answered "no" when our opportunities as developers were already exhausted, and more and more products or features were required from us. By 2002, I had become a habit: I spent another ten years refusing to comply with the whims of business owners.

Development teams and IT departments of companies are heavily dependent on other groups who are constantly bargaining, begging, threatening and reworking even the most obvious and objectively designed plans. Vulnerable also include plans based on careful analysis and historical experience. Most teams, lacking thorough analysis and historical experience, were unable to cope with those who pushed them to take on obscure and often unrealistic commitments.

In the meantime, employees have come to terms with the insane workload, and exorbitant workloads have become the norm. No one seems to have thought about the fact that software engineers can also have a social or family life. Sounds harsh, but it's true! I know too many examples where excessive workload has forever destroyed family relationships. It's hard to sympathize with the typical developer geek. In my home state of Washington, a software engineer's income is second only to that of a dentist. As in the days of Ford, that is, in the 1920s, when people in his factories earned five times more than the national average, it never occurs to anyone to think about the monotony of work or the well-being of specialists: they are paid so much! It's hard to imagine labor unions in knowledge-based industries like software development, because no one will seriously examine the causes of the physical and psychological ailments experienced by developers. More responsible employers offer, for example, measures such as massage or psychotherapy. Or they spend mental health days - and this is instead of paying attention to studying the root causes of the problem. A technical writer at a well-known software firm once told me, "It's okay if I take antidepressants, because everyone does!" Programmers usually go along with all the demands, get paid well, and suffer the consequences. I wanted to change that, to find a mutually beneficial approach that would allow me to say yes and still protect my team, ensuring that optimal pace was achieved. I wanted to bring my team members back into the community and family, and improve the conditions that were causing stress and health problems for under-thirty developers. So I decided to start dealing with these problems.

In Search of Successful Change Management

The second issue that has been on my mind is change management in large organizations. I was a development manager at Sprint PCS and then at Motorola. In both companies, there was a strong need to move to more flexible working methods. But in both cases, I had trouble implementing agile methods on more than one or two teams.

Both times, I didn't have enough authority to simply order changes to be made to multiple teams. I tried to implement changes at the request of senior management, but did not have the necessary authority. I was asked to influence colleagues to implement the same changes in their teams as I did in mine. But they were in no hurry to adopt methods that seemed to work best in my team. This resistance probably had several reasons. More often than not, I heard that each team has its own situation and my methods will need to be tailored to the specific needs of others. By the middle of 2002, I realized that it was useless to rigidly prescribe any software development process - it simply would not work.

The process had to be adapted to each specific situation, so active leadership of each team was required. And this was often not enough. Even with proper leadership, there is no certainty that significant changes can occur without an established structure and advice on how to tailor processes to different situations. If the manager, coach, or responsible engineer does not have a clear idea of what to do, then any adaptation is likely to be subjective. At the same time, there is a high probability of errors - for example, the introduction of an inappropriate process template.

I tried to cover this issue in the Agile Management for Software Engineering book I was writing at the time. I wondered, "Why does agile development produce better economic results than traditional approaches?" I wanted to apply the structure of the theory of constraints for this purpose. 4
Goldratt, Eliyahu M. What is this thing called The Theory of Constraints and How should it be implemented? Great Barrington, MA: North River Press, 1999.

In the process of researching and writing this book, I realized that every situation is unique. And how can a constraint or bottleneck be the same for any team and project at any time? Each team is unique: different skills, opportunities, experience. Each project differs from others in terms of budget, schedule, scope and risks. Organizations are also different: they have different value chains and operate in different markets (Figure 1.1). It seemed to me that this could provide a clue to understanding resistance to change. If the proposed changes in work methods and behaviors do not give, in the opinion of the employee, an obvious advantage, then he will not accept them. If these changes do not affect what the team perceives as a limiter or deterrent, then the team will resist. In other words, changes proposed without regard to the context will be rejected by employees who know the context of the work perfectly.

Rice. 1.1. Why Generic Development Methodologies Are Wrong

It would seem that it would be better if the new process began to develop, eliminating one limitation after another. This is the main point of Goldratt's theory of constraints. Realizing that I still had a lot to learn, I realized the value of the material and rushed forward in working on the manuscript. It was clear to me that the book did not give advice on how to implement ideas on a larger scale, nor did it provide much help in finding ways to manage change.

Goldratt's approach, outlined in , aims to find limitations, and then ways to eliminate them so that they no longer hinder performance. After that, a new constraint arises, and the cycle repeats. It is an iterative approach that systematically improves performance by identifying and removing obstacles.

I realized that you can combine this approach with some techniques from the field of lean manufacturing. By modeling the software development lifecycle workflow as a value stream and creating a tracking and visualization system to capture state changes of the emerging work “flowing” through the system, I was able to identify the constraints. The ability to identify the constraint is the first step towards the underlying model of TOC. Goldratt has already developed an application of this theory to workflow problems that bears the clumsy name of "drum-buffer-rope". However, I realized that a simplified version of this system can be implemented in the field of software development.

In terms of origin, drum-buffer-rope is an example of a class of solutions known as pull systems. As we will see in , kanban is also one example of this kind of system. A side effect of pull systems is that they limit WIP to a predetermined amount, preventing employees from being overwhelmed. In addition, only workers who directly face the restriction remain fully loaded; everyone else should have free time. I realized that pull systems could solve both problems that worried me. The pull system will allow me to introduce incremental changes, which (I hoped) would significantly reduce resistance to them, as well as make it easier to achieve the optimal pace. I made the decision to switch to the drum-buffer-rope system as soon as possible. I wanted to experiment with incremental process evolution and see if it provided optimal pace and reduced resistance to change.

Such an opportunity appeared in the fall of 2004 at Microsoft, which is described in detail in this book in the analysis of the example.

From drum-buffer-rope to kanban

The drum-buffer-rope solution at Microsoft has paid off. Resistance was weak, performance more than tripled, lead time was reduced by 90%, and predictability improved by 98%. In the fall of 2005, I reported on the results achieved at a conference in Barcelona 5
Anderson, David J., and Dragos Dumitriu, “From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department,” Proceedings of the TOCICO World Conference, Barcelona, November 2005.

And in the winter of 2006 he made another report. My work caught the attention of Donald Reinertsen, who made a special visit to my office in Redmond. He wanted to reassure me that everything was ready for a full transition to kanban.

Kan-ban - a Japanese word that literally translates to "signal board". In production, such a board is used to visualize the increasing pace of production, which allows more products to be produced. Employees at each stage of the process cannot move on to the next phase of work until the appropriate signal is given through the kanban board. Although I knew about the existence of this mechanism, I was not convinced that it was useful or even viable in relation to intellectual work, especially software development. I understood that kanban provided the optimal pace, but did not know about its good reputation as a method of incentivizing incremental process improvement. I didn't know that Taiichi Ohno, one of the creators of the Toyota Production System, said, “The two main principles of the Toyota Production System are just-in-time and human-assisted automation, or autonomy. A tool is used to manage the system - this is kanban. In other words, Kanban is vital to the process. kaizen(“continuous improvement”) used by Toyota. It is the mechanism that makes the system work. Now, with five years of experience behind me, I accept this as an absolute truth.

Luckily, Don made a compelling case for switching from drum-buffer-rope to kanban. It sounded rather esoteric: the kanban system provides a smoother transition from downtime to a bottleneck than drum-buffer-rope. However, understanding this distinction is not essential to reading and understanding this book.

Re-examining the solution implemented by Microsoft, I realized that if we immediately perceived it as the result of a kanban system, then the result would be the same. I found it interesting that two different approaches lead to the same result. So, since it was the same process, I didn't feel obligated to see it solely as the result of implementing the drum-buffer-rope system.

I began to prefer the term "kanban" to this complex phrase. It is used in lean manufacturing (same as the Toyota Production System). This body of knowledge has received much more distribution and recognition than the theory of constraints. Kanban, despite its Japanese origin, is less metaphorical than drum, buffer, and rope combined. This word is easier to pronounce, explain and, as it turned out later, to teach and implement. This is where it stuck.

The emergence of the kanban method

In September 2006, I left Microsoft to lead software development at Corbis, a privately owned photo storage and intellectual property company located in downtown Seattle. Inspired by what Microsoft had achieved, I decided to implement a kanban pull system in Corbis. Here, too, the results have been very successful, leading to the development of most of the concepts presented in this book. It is an extended set of those concepts—workflow visualization, workflow item types, cadences, classes of service, special management reporting, and activity analysis—that define the Kanban method.

In this book, I describe Kanban (capitalized) as a method of evolutionary change using the kanban (lowercase) pull system, visualization, and other tools to catalyze the introduction of lean ideas into technology development and IT operations. It is an evolutionary and step by step process. Kanban allows you to achieve context-specific process optimization with minimal resistance to change while maintaining the optimal pace for all involved people.

David Anderson's book Kanban takes over from the first page.

With pictures, graphs and conclusions David's condensed biography reveals the Kanban methodology for the savvy project management freak. Project management is interesting when told in the first person by the direct developer of the method.

about the author

Listed on David J Anderson's official blog as p Chairman of Lean Kanban Inc. Also he t management manager and consultant since the 2000s, speaker and conference host since 2005. For the first time in a leadership position, he was in 1991, so his experience allows you to honestly compare kanban and waterfall, agile, scrum, and other project management methodologies.

He created kanban to raise the level of intellectual and creative work. David's goal was to deliver on time, meet targets and adequately manage today's companies in general.

Using real examples from the life of Microsoft, Motorola and Corbis, he told and showed the principles, methods and instructions for implementing kanban in a company.

Semantic load and essence of the book

Book . Alternative route toAgile is written by the person who invented kanban in the first place. The book is very interesting and informative. Here, the line between the philosophy of Kaizen is very interestingly revealed ( continuous improvement), methodology ( Lean) and Kanban (a method of conserving human and material resources).

Kaizen is the philosophy and ethics of the relationship between factory workers and management.

Lean manufacturing is a project management system created at Toyota to remove all waste of time and resources from the company's processes.

Kanbanis a project management method that provides a way limit simultaneously running tasks. If there is a limit on people, tools, or time, kanban helps distribute tasks and projects.

Anderson was greatly influenced by the theory of constraints in writing this book. The book is full of WIP limits, bottlenecks, and the ability tohonestly determine the maximum load per unit of time, which maintains the quality at an optimal level.

Dr. Eliyahu Goldratt's Theory of Constraints (TOC) is a manufacturing business management methodology. An Israeli physicist developed a theory and a practical method for managing organizations, algorithms for the operation of production, logistics and marketing of goods. A systematic approach to identifying constraints in companies helps set everything up. According to Goldratt's experience, More often than not, company policy becomes a constraint.

WIP limit (work in progress) — the number of tasks that can be open at the same time.

Bottleneck - a moment in the workflow when there is a serious limitation of resources or opportunities. On the diagrams, it really looks like a narrow neck of a bottle: both before and after such a situation, the lines expand on the diagrams.

Stereotypes about kanban

When we hear about kanban, we often imagine a board with stickers - this stereotype is imposed on us by the media. Figuratively, there is a list of open, running and completed sticker tasks on the wall. . You can use virtual walls and programs to manage projects, where lists of tasks, priorities and other nuances will be entered.

The kanban methodology here will not be a board, and not stickers, but the process of monitoring and transferring tasks on the wall. By what rules, who and why moves the stickers, how many stickers can be kept in the “performed” column, why limit the number in this column - this is what David tells on the pages " Kanban. An Alternative Path to Agile.

Kanban is not a sticky board, stickers are only an indicator of workload.

Anderson designed the kanban so that we don't start a new project until the previous ones are completed. Therefore, for one developer, the number of stickers is selected - 3-5, for example, and exactly so many tasks per unit of time can be opened for him. Only after completing any of the tasks, he can take on a new one.

We talk a lot about man-hours and their price, but often do not realize that there is an hour of productive work and an hour taken from life. And there is a week of productive work, the field of which you have to take sick leave. David talks about this pace of work when every hour is productive and this is a constant healthy state of the team.

Agile, Scrum and Kanban

Anderson is sure that Agile and Scrum methodologies are formulaic and rigid. In his opinion, project management should be individual in each company. Therefore, Agile and Scrum with their standardized action algorithms are outdated, like the classic Waterfall step-by-step methodology. A kan ban - the method is so company-specific, which scares the adherents of flexible methodologies!

Agile is an agile methodology with which programming historically began in the format of rolling out updates to programs every couple of months. Programming iterations of a couple of weeks to add each feature speed up the development process and reduce risk.

Scrum is another agile methodology with short iterations but more control over the programming process. There are sprints - periods of time with certain tasks to complete. They are strictly limited. There are backlogs - lists of tasks in general, which are distributed by the product owner. It does not belong to the development team, but prioritizes tasks.

David Anderson

Kanban. An Alternative Path to Agile

David J Anderson

Successful Evolutionary Change for Your Technology Business

Published with permission from Lean Kanban Inc.

We thank the Lean Kanban Community Russia represented by Alexey Pimenov, Vyacheslav Tsyrulnik, Anton Manin, Sergey Baranov and Igor Filipyev for their help in preparing the publication.

No part of this book may be reproduced in any form without the written permission of the copyright holders.

* * *

Dedicated to Nikola and Natalie

Foreword

I always pay attention to the work of David Anderson. I met him in October 2003 when he sent me a copy of his book Agile Management for Software Engineering: Applying Theory of Constraints for Business Results. As the title suggests, the book was heavily influenced by Eliyahu Goldratt's Theory of Constraints (TOC). Later, in March 2005, I visited David at Microsoft, by which time he was working closely with cumulative flowcharts. Even later, in April 2007, I had the opportunity to observe how the breakthrough kanban system that he implemented in Corbis works.

I would like to warn readers about a few things. First, if you think you know how kanban systems work, then you probably mean the ones used in lean manufacturing. The ideas in this book are much more advanced than the simple systems that use static WIP limits, FIFO scheduling, and a single class of service. Please pay attention to these differences.

Solving the Agile Manager's Dilemma

In my day-to-day activities in 2002 and in my previous book(1), I was mainly concerned with two issues. First, how to protect the team from the ever-increasing demands of the business and achieve what is now called the “optimal pace” in the agile community. And second, how can I successfully implement an agile approach throughout the organization, overcoming the inevitable resistance to change?

Finding the right pace

In 2002, the agile community thought of optimal pace as simply "a 40-hour workweek"(2). The principles of the Agile Manifesto(3) stated that “agile processes promote optimal development. Sponsors, developers and users must be prepared to maintain a constant pace indefinitely.” Two years earlier, my team at Sprint PCS kept hearing from me that "software development at scale is a marathon, not a sprint." If the team members had to maintain a constant pace in the process of working on a year and a half project, then they could not be allowed to burn out in a month or two. The project needed to be planned, budgeted, timed, and evaluated to ensure that team members spent a reasonable amount of time working each day and weren't too tired. As a manager, my task was to achieve this goal and meet all business requirements.

When I was in my first managerial position (it was in 1991, at a startup that made video capture boards for personal and smaller computers), the CEO said that management had a "very negative opinion" of me. I always answered "no" when our opportunities as developers were already exhausted, and more and more products or features were required from us. By 2002, I had become a habit: I spent another ten years refusing to comply with the whims of business owners.

About the book
An in-depth guide to kanban from a 30-year-old first-time kanban pioneer in software development.

David Anderson, who has implemented the kanban method in several companies and constantly improved it, shows how to effectively introduce lean ideas into technology development and IT operations - with minimal resistance to change, while maintaining the optimal pace for all the employees involved in the work.

Kanban quickly identifies issues that impact performance and forces the team to focus on resolving them to keep work flowing. By making quality and process issues visible, kanban provides an opportunity to evaluate the impact of defects, constraints, variability, and economic costs on workflow and employee throughput.

Simply limiting unfinished jobs through kanban results in improved work quality and productivity. The combination of streamlined workflow and improved quality helps reduce lead times and improves predictability and the likelihood of delivering work on time. By establishing regular release cadences and consistent adherence to schedules, kanban helps build trust with customers and other members of the value stream—other departments, vendors, and dependent partners.

Kanban has been proven to increase user satisfaction through regular, reliable, high-quality releases of valuable software. It has also been proven to improve productivity, quality and reduce production time. There is evidence that kanban can be a catalyst for the emergence of a more agile organization through evolutionary cultural change.

This book answers the questions:

- What is kanban?
Why does your company need it?
- How to implement it?
- How to recognize opportunities for improvement in business - and what to do with them?

Who is this book for?
For managers and heads of IT companies.

about the author
David Anderson is the founder of Lean Kanban University and the David J Anderson School of Management, dedicated to helping leaders and managers achieve better results through best practices.

Anderson has 30 years of experience in technology companies. He has introduced agile management practices to companies such as Motorola and Microsoft.

David was the first to use kanban in software development in 2005.

Kanban means "signal board" in Japanese. In manufacturing, such a board is used to visualize increasing rates, which allows you to produce more products at a lower cost. A striking example is the approach of Toyota, thanks to which for many years the principle of "just in time" has been effectively implemented with minimal costs.

David Anderson provides an extended set of ideas (visualization of the process and rules of work, typing of work items, classes of service, cadences, metrics and graphs for management accounting and analysis) that define the kanban method.

The book describes tools that allow you to effectively introduce lean ideas into technological development and IT operations with minimal resistance to change, while maintaining an optimal pace for all employees involved in the work.

Published in Russian for the first time.

Copyright holders! The presented fragment of the book is placed in agreement with the distributor of legal content LLC "LitRes" (no more than 20% of the original text). If you believe that the posting of material violates your or someone else's rights, please let us know.

The Freshest! Book receipts today

Testament of Yvette Blanche
Demange Patricia
Periodicals

Suzanne got up from the rock and was about to walk back to the car when she heard a voice:

- Come! Come to me! Come to me! Come!

And, like the first time, these distinct words were followed by an unintelligible sob. The girl froze. The voice was so plaintive that she couldn't move.

And then she heard these words again:

“Come, come…come to me!” Come!

It suddenly seemed to Susanna that her brain would explode from this one phrase. For several minutes she stood motionless, but then gathered her strength and rushed to the car parked under the trees. She quickly inserted the ignition key and started the engine. She wanted to get out of here as quickly as possible. As long as you don't know or hear anything. It can not be! She's just Susanna Lambert, Susanna Lambert, Susanna Lambert...
Werewolf
Grinder Alexandra
Periodicals

He followed Julia to the very swamp ... The girl felt his gaze on her and was numb with horror. Legs immediately began to sink deeper and deeper into the cold quagmire. We must get out of here before it's too late! She tried to turn towards the path: here it is, solid ground, literally a meter away ... But there something much more dangerous than a fetid swamp was waiting for her: a werewolf covered with gray wool! His hunched figure suddenly emerged from the darkness. The massive head slowly swayed in time with the wind, and in the depths of the eye sockets, the coals of the eyes ominously gleamed red. Julia made one last attempt to cope with her own fear, but the horror paralyzed her: she could not take a step. An eerie creature that looked like a wolf, meanwhile, was approaching. There were only a few steps between them. Now you can already see the gray wool on the monster's paws, here sharp claws flashed in the moonlight ...
Mage-decided. Formation
Nazimov Konstantin
Fallouts

A student, he is a student everywhere. Entertainment and attempts to earn. One of the usual things led to a tragedy, and I ended up ... in the world of magic. Good luck with it, I liked it. They even helped and turned out to be ... a student, but already at the magic academy and set to work.

But life turns people and magicians as it wants. This world did not know the great schemer, with his ability to make money out of thin air. Nobody built financial pyramids. Therefore, I can turn around to the fullest. But, serious problems and scams have gone. One of the ideas turned out to be such that my friends and I couldn't digest the result. I had to go out of my way and take things to a completely different level. And it is difficult to pull it: here is the gold of moneybags and the guild of thieves, ordinary people and bureaucrats. And also problems with artifacts and girls, card debts and beautiful cars. You have to decide quickly, react instantly. Eh, but I want to live beautifully and I hope it will work out, although not a fact ...
lady in white
Gray Lara
Detectives and Thrillers, Thriller

Every day after midnight something happens in the castle...

Katerina understood that her life was hanging by a thread. She grabbed her skirt with one hand so that the hem would not interfere with her run, the other hand was extended forward so as not to crash her head into the wall. Finally a door! The girl abruptly opened it and ran out of the corridor. The pursuer did not lag behind: his steps were heard more and more clearly. He could catch up with Katerina at any moment!

- For help! For help! the girl screamed. – Someone! Help!

She tripped on a rock and hit hard, falling to the floor. Katerina crawled aside and hid. Fortunately, it was dark, and the pursuer ran past without noticing her. Katerina looked around: she was lying in a dark room with no windows, no light, nothing could be seen...
Racing Joker. Survival game
Nazimov Konstantin
Fiction, Heroic fiction

The game is not how I envisioned it. Lies and betrayal, bribery and even slavery go hand in hand here. There are normal players, of which there are many, who try to live by the rules and honor. And it also happens that black is presented as white, a lie for the truth.

By the will of the mind of the network, complex tasks and missions are set before me, which I did not even suspect. Races for elimination or survival are replaced by the flight from the bounty hunters. We have to get into a showdown with injustice and meanness. To improve the lives of ordinary players who, in their gullibility and naivety, chased after promises and found themselves in a hopeless situation. Dangle into the neighboring world-game, where monsters meet at every turn, and consider you nothing but their prey. Without all this, you cannot reach the finish line.

Throughout the game, friends and enemies side by side with me, some help in difficult times, others are ready to drive a knife into my back, but I have to rely on myself and good luck. A goal is set, gasoline is poured into the tank, an amulet is around the neck, and the foot presses the gas pedal to the floor. Victory will come and I will achieve my goal! Hope so…
Ghosts from the mist
Grinder Alexandra
Periodicals

Until now, Elena did not attach importance to the fact that the owner of the guest house where she stayed was alone all the time. She assumed that his wife was either busy in the kitchen, or busy with some other business and therefore did not appear in front of the guests ...

Set "Week" - top new products - leaders for the week!

2. Cursed Rector
Summer Lena
Romance novels , Love-fiction novels , Fiction , Detective fiction ,

I had a year to finish. One year - and I could get the freedom and independence that I had dreamed of since childhood. However, the sudden and very suspicious death of my mother turned my world upside down. She left behind many questions, and the only chance to find answers is to go to the most elite university of the Republic. I thought that the snobbery of new classmates would be my main problem, but I was wrong. The answers I'm looking for may cost me my life, and for some reason I'm now more concerned about the life of the local rector, who is under a curse.
Arcturus Academy. wolf bride
Lime Sylvia
Fiction, Humorous fiction

Sometimes betrayal is not the end, but the beginning.

Occasionally - this is the door to another world, where war is on the threshold. Where werewolves fight to the death for their women and men load guns with silver bullets. Where a mysterious killer roams, gnawing the throats of everyone who looks so much like you. Where good-natured smiles are a sure chance to fall into a trap, and a wolf growl behind your back is a chance to escape.

Get ready, the werewolf academy is waiting for you here, a maniac outside the door and a mysterious man who, for some reason, decided that he can come to you at night.

And all because betrayal is not the end, but only the beginning.
Arcturus Academy 2. The wolf's wife
Lime Sylvia
Fantasy, Cyberpunk

They say that life and trust are lost only once. Once I was lucky, but it is unlikely that luck is destined to repeat itself. The maniac who kills the girls is found, but the puppeteer is still pulling the strings of his puppets. Death follows relentlessly, and I must be one step ahead. This time, to save not only herself, but also the werewolf, with whom she is connected by unbreakable bonds. He is stronger than the rest, and this is his weakness. To keep him alive, I'll have to betray him. Or is there another way out?

Portal for the student. Self-training

* * *

Foreword

Part I Basics

Chapter 1 Solving the Agile Manager's Dilemma

Finding the right pace

In Search of Successful Change Management

From drum-buffer-rope to kanban

The emergence of the kanban method

about the author

Using real examples from the life of Microsoft, Motorola and Corbis, he told and showed the principles, methods and instructions for implementing kanban in a company.

Semantic load and essence of the book

Kaizen is the philosophy and ethics of the relationship between factory workers and management.

Lean manufacturing is a project management system created at Toyota to remove all waste of time and resources from the company's processes.

WIP limit (work in progress) — the number of tasks that can be open at the same time.

Bottleneck - a moment in the workflow when there is a serious limitation of resources or opportunities. On the diagrams, it really looks like a narrow neck of a bottle: both before and after such a situation, the lines expand on the diagrams.

Stereotypes about kanban

Kanban is not a sticky board, stickers are only an indicator of workload.

Agile, Scrum and Kanban

Agile is an agile methodology with which programming historically began in the format of rolling out updates to programs every couple of months. Programming iterations of a couple of weeks to add each feature speed up the development process and reduce risk.

This book answers the questions:

The Freshest! Book receipts today

Set "Week" - top new products - leaders for the week!

RELATED ARTICLES

Part I
Basics

Chapter 1
Solving the Agile Manager's Dilemma