https://facebook.com/298276320198577_2948395061853343
Почему внедрение Agile заканчивается провалом
Стремясь к большей гибкости, организации повсеместно принялись внедрять метод Agile, который используется в разработке программного обеспечения. Но многие стали от этого только менее гибкими, так как внедренные ими процессы часто отрицательно сказываются на мотивации и продуктивности разработки продуктов. В чем причина?
Разработка ПО с помощью Agile
Такие структуры гибкой разработки программного обеспечения, как Agile, применяются давно и в различных формах. Но в основе большинства этих моделей лежат две вещи: формирование гипотез (например, чего можно добиться с помощью определенной функции) и совместное участие специалистов различных профилей в экспериментах, в которых они отсекают неверные варианты.
В появившейся в 2001 году методологии Agile были сформулированы четыре важных принципа, позволившие облегчить труд разработчиков программного обеспечения и повысить их мотивацию и мотивацию менеджеров по продуктам:
Люди и взаимодействие важнее процессов и инструментов,
Работающее ПО важнее исчерпывающей документации,
Сотрудничество с клиентами важнее согласования условий контракта,
Готовность к изменениям важнее следования плану.
За последние три года в своих исследованиях мотивации мы проанализировали методы работы в 500 организациях с помощью опросов и экспериментов и обнаружили, что происходящее в этих компаниях на практике значительно расходится с вышеупомянутыми принципами.
Например, движущей силой в работе стали процессы и инструменты, а не люди и взаимодействие. Директор по цифровым продуктам одной крупной компании, входящей в список Fortune 100, объяснил это так: «Мы не должны сомневаться в Agile». В другой организации из списка Fortune 500 менеджеры по продуктам и разработчики общаются исключительно с помощью инструментов, в которых менеджеры преимущественно отдают команды подчиненным.
Точно так же документация часто оказывается важнее работающего ПО. В одной крупной технологической компании команда разработки продуктов тратила значительное время на работу с мелкими пользовательскими запросами (которые называли «пользовательскими историями»). Эти запросы накапливались, ставились в очередь задач и попадали первому освободившемуся разработчику. В результате задач становилось много, и в конце концов этот процесс превратился в классический waterfall, то есть модель, при которой работа передается из отдела продуктов разработчикам. Но именно такое взаимодействие была призвана устранить методология Agile! Неудивительно, что технический директор этой компании прокомментировал ситуацию так: «Мои сотрудники чувствуют себя как повара, которые получают заказы в заведении быстрого питания».
Принцип «готовность к изменениям важнее следования плану» часто ошибочно интерпретируют как «план не нужен». Например, в одной быстрорастущей технологической компании команды гибкой разработки даже не пытались понять общую стратегию организации. В результате они фокусировались на не особенно важных для организации задачах. Без плана команды не смогут определить приоритеты и ответственно инвестировать в них ресурсы. Неверное понимание этого принципа заходит так далеко, что разработчики порой начинают считать, будто им не нужно думать о временных ограничениях и ключевых точках развития проектов.
Если бы неправильное применение принципов повышало мотивацию и производительность сотрудников, с этим можно было бы смириться, но на практике мы обнаружили совершенно противоположное. Когда методология Agile применяется подобным образом, общая мотивация сотрудников падает. Они не могут экспериментировать, управлять собственной работой и общаться с клиентами. По этой причине они не чувствуют интереса, не видят потенциала и цели, а испытывают эмоциональное и финансовое давление или действуют по инерции. Разработчики перестают адаптироваться, учиться и прикладывать усилия к тому, что они делают.
Например, партнер одного венчурного фонда рассказал, как компания по разработке видеоигр в течение года занималась игрой, хотя все сотрудники считали ее неудачной. В конце концов, они поняли, что напрасно потратили время и деньги.
Адаптивные процессы перестают работать, потому что компании, стремясь к высоким показателям, начинают или слишком много внимания уделять тактике (концентрируются на процедурах и микроменеджменте), или становятся слишком гибкими (избегают долгосрочных целей, планирования и кросс-функционального сотрудничества).
Для того чтобы этого избежать, необходимо в первую очередь сбалансировать тактику и адаптивность. Вот несколько советов разработчикам и менеджерам по продукту, которые позволят найти баланс и улучшить мотивацию и производительность команд.
1. Разработка программного обеспечения должна быть процессом сотрудничества →https://hbr-russia.ru/management/korporativnyy-opyt/788835
(Илья Рабченок)
Как достичь настоящей гибкости в организации
Почему внедрение Agile заканчивается провалом
Стремясь к большей гибкости, организации повсеместно принялись внедрять метод Agile, который используется в разработке программного обеспечения. Но многие стали от этого только менее гибкими, так как внедренные ими процессы часто отрицательно сказываются на мотивации и продуктивности разработки продуктов. В чем причина?
Разработка ПО с помощью Agile
Такие структуры гибкой разработки программного обеспечения, как Agile, применяются давно и в различных формах. Но в основе большинства этих моделей лежат две вещи: формирование гипотез (например, чего можно добиться с помощью определенной функции) и совместное участие специалистов различных профилей в экспериментах, в которых они отсекают неверные варианты.
В появившейся в 2001 году методологии Agile были сформулированы четыре важных принципа, позволившие облегчить труд разработчиков программного обеспечения и повысить их мотивацию и мотивацию менеджеров по продуктам:
Люди и взаимодействие важнее процессов и инструментов,
Работающее ПО важнее исчерпывающей документации,
Сотрудничество с клиентами важнее согласования условий контракта,
Готовность к изменениям важнее следования плану.
За последние три года в своих исследованиях мотивации мы проанализировали методы работы в 500 организациях с помощью опросов и экспериментов и обнаружили, что происходящее в этих компаниях на практике значительно расходится с вышеупомянутыми принципами.
Например, движущей силой в работе стали процессы и инструменты, а не люди и взаимодействие. Директор по цифровым продуктам одной крупной компании, входящей в список Fortune 100, объяснил это так: «Мы не должны сомневаться в Agile». В другой организации из списка Fortune 500 менеджеры по продуктам и разработчики общаются исключительно с помощью инструментов, в которых менеджеры преимущественно отдают команды подчиненным.
Точно так же документация часто оказывается важнее работающего ПО. В одной крупной технологической компании команда разработки продуктов тратила значительное время на работу с мелкими пользовательскими запросами (которые называли «пользовательскими историями»). Эти запросы накапливались, ставились в очередь задач и попадали первому освободившемуся разработчику. В результате задач становилось много, и в конце концов этот процесс превратился в классический waterfall, то есть модель, при которой работа передается из отдела продуктов разработчикам. Но именно такое взаимодействие была призвана устранить методология Agile! Неудивительно, что технический директор этой компании прокомментировал ситуацию так: «Мои сотрудники чувствуют себя как повара, которые получают заказы в заведении быстрого питания».
Принцип «готовность к изменениям важнее следования плану» часто ошибочно интерпретируют как «план не нужен». Например, в одной быстрорастущей технологической компании команды гибкой разработки даже не пытались понять общую стратегию организации. В результате они фокусировались на не особенно важных для организации задачах. Без плана команды не смогут определить приоритеты и ответственно инвестировать в них ресурсы. Неверное понимание этого принципа заходит так далеко, что разработчики порой начинают считать, будто им не нужно думать о временных ограничениях и ключевых точках развития проектов.
Если бы неправильное применение принципов повышало мотивацию и производительность сотрудников, с этим можно было бы смириться, но на практике мы обнаружили совершенно противоположное. Когда методология Agile применяется подобным образом, общая мотивация сотрудников падает. Они не могут экспериментировать, управлять собственной работой и общаться с клиентами. По этой причине они не чувствуют интереса, не видят потенциала и цели, а испытывают эмоциональное и финансовое давление или действуют по инерции. Разработчики перестают адаптироваться, учиться и прикладывать усилия к тому, что они делают.
Например, партнер одного венчурного фонда рассказал, как компания по разработке видеоигр в течение года занималась игрой, хотя все сотрудники считали ее неудачной. В конце концов, они поняли, что напрасно потратили время и деньги.
Адаптивные процессы перестают работать, потому что компании, стремясь к высоким показателям, начинают или слишком много внимания уделять тактике (концентрируются на процедурах и микроменеджменте), или становятся слишком гибкими (избегают долгосрочных целей, планирования и кросс-функционального сотрудничества).
Для того чтобы этого избежать, необходимо в первую очередь сбалансировать тактику и адаптивность. Вот несколько советов разработчикам и менеджерам по продукту, которые позволят найти баланс и улучшить мотивацию и производительность команд.
1. Разработка программного обеспечения должна быть процессом сотрудничества →https://hbr-russia.ru/management/korporativnyy-opyt/788835
(Илья Рабченок)
Как достичь настоящей гибкости в организации
https://facebook.com/298276320198577_2948395061853343
Why Agile Deployment Fails
Striving for greater flexibility, organizations everywhere began to implement the Agile method, which is used in software development. But many have only become less flexible from this, since the processes they have implemented often negatively affect the motivation and productivity of product development. What is the reason?
Software Development with Agile
Agile software development frameworks such as Agile have long been used in many forms. But the majority of these models are based on two things: the formation of hypotheses (for example, what can be achieved using a certain function) and the joint participation of specialists of various profiles in experiments in which they cut off incorrect options.
The Agile methodology, which appeared in 2001, formulated four important principles that made it easier for software developers to work and increase their motivation and the motivation of product managers:
People and interaction are more important than processes and tools,
Running software is more important than comprehensive documentation,
Collaboration with customers is more important than negotiating contract terms,
Willingness to change is more important than following a plan.
Over the past three years, in our research on motivation, we analyzed the methods of work in 500 organizations through surveys and experiments and found that what is happening in these companies in practice diverges significantly from the above principles.
For example, processes and tools, rather than people and interaction, have become the driving force in work. The digital product director of a major Fortune 100 company explained it this way: “We must not doubt Agile.” In another Fortune 500 organization, product managers and developers communicate exclusively using tools in which managers primarily issue commands to subordinates.
In the same way, documentation is often more important than working software. At one large technology company, the product development team spent considerable time working with small user queries (called "user stories"). These requests accumulated, were put in the task queue and fell into the first freed developer. As a result, there were many tasks, and in the end, this process turned into a classic waterfall, that is, a model in which work is transferred from the product department to developers. But precisely this interaction was designed to eliminate the Agile methodology! It is not surprising that the technical director of this company commented on the situation as follows: “My employees feel like cooks who receive orders at a fast food establishment.”
The principle of “readiness for change is more important than following a plan” is often mistakenly interpreted as “a plan is not needed.” For example, in one fast-growing technology company, agile teams did not even try to understand the organization’s overall strategy. As a result, they focused on tasks that were not particularly important for the organization. Without a plan, teams will not be able to prioritize and invest resources responsibly in them. A misunderstanding of this principle goes so far that developers sometimes start to think that they do not need to think about time constraints and key points in the development of projects.
If the incorrect application of the principles increased the motivation and productivity of employees, we could come to terms with this, but in practice we found the exact opposite. When the Agile methodology is applied in this way, the overall motivation of employees falls. They cannot experiment, manage their own work and communicate with customers. For this reason, they do not feel interest, do not see potential and goals, but experience emotional and financial pressure or act by inertia. Developers stop adapting, learning, and putting effort into what they do.
For example, a partner in a venture capital fund described how a video game development company worked on a game for a year, although all employees considered it a failure. In the end, they realized that they had wasted time and money.
Adaptive processes stop working because companies, striving for high performance, start either paying too much attention to tactics (concentrating on procedures and micromanagement), or becoming too flexible (avoiding long-term goals, planning and cross-functional cooperation).
In order to avoid this, it is necessary first of all to balance tactics and adaptability. Here are some tips for developers and product managers to find balance and improve team motivation and performance.
1. Software development should be a collaborative process → https: //hbr-russia.ru/management/korporativnyy-opyt/788835
(Ilya Rabchenok)
How to achieve real flexibility in the organization
Why Agile Deployment Fails
Striving for greater flexibility, organizations everywhere began to implement the Agile method, which is used in software development. But many have only become less flexible from this, since the processes they have implemented often negatively affect the motivation and productivity of product development. What is the reason?
Software Development with Agile
Agile software development frameworks such as Agile have long been used in many forms. But the majority of these models are based on two things: the formation of hypotheses (for example, what can be achieved using a certain function) and the joint participation of specialists of various profiles in experiments in which they cut off incorrect options.
The Agile methodology, which appeared in 2001, formulated four important principles that made it easier for software developers to work and increase their motivation and the motivation of product managers:
People and interaction are more important than processes and tools,
Running software is more important than comprehensive documentation,
Collaboration with customers is more important than negotiating contract terms,
Willingness to change is more important than following a plan.
Over the past three years, in our research on motivation, we analyzed the methods of work in 500 organizations through surveys and experiments and found that what is happening in these companies in practice diverges significantly from the above principles.
For example, processes and tools, rather than people and interaction, have become the driving force in work. The digital product director of a major Fortune 100 company explained it this way: “We must not doubt Agile.” In another Fortune 500 organization, product managers and developers communicate exclusively using tools in which managers primarily issue commands to subordinates.
In the same way, documentation is often more important than working software. At one large technology company, the product development team spent considerable time working with small user queries (called "user stories"). These requests accumulated, were put in the task queue and fell into the first freed developer. As a result, there were many tasks, and in the end, this process turned into a classic waterfall, that is, a model in which work is transferred from the product department to developers. But precisely this interaction was designed to eliminate the Agile methodology! It is not surprising that the technical director of this company commented on the situation as follows: “My employees feel like cooks who receive orders at a fast food establishment.”
The principle of “readiness for change is more important than following a plan” is often mistakenly interpreted as “a plan is not needed.” For example, in one fast-growing technology company, agile teams did not even try to understand the organization’s overall strategy. As a result, they focused on tasks that were not particularly important for the organization. Without a plan, teams will not be able to prioritize and invest resources responsibly in them. A misunderstanding of this principle goes so far that developers sometimes start to think that they do not need to think about time constraints and key points in the development of projects.
If the incorrect application of the principles increased the motivation and productivity of employees, we could come to terms with this, but in practice we found the exact opposite. When the Agile methodology is applied in this way, the overall motivation of employees falls. They cannot experiment, manage their own work and communicate with customers. For this reason, they do not feel interest, do not see potential and goals, but experience emotional and financial pressure or act by inertia. Developers stop adapting, learning, and putting effort into what they do.
For example, a partner in a venture capital fund described how a video game development company worked on a game for a year, although all employees considered it a failure. In the end, they realized that they had wasted time and money.
Adaptive processes stop working because companies, striving for high performance, start either paying too much attention to tactics (concentrating on procedures and micromanagement), or becoming too flexible (avoiding long-term goals, planning and cross-functional cooperation).
In order to avoid this, it is necessary first of all to balance tactics and adaptability. Here are some tips for developers and product managers to find balance and improve team motivation and performance.
1. Software development should be a collaborative process → https: //hbr-russia.ru/management/korporativnyy-opyt/788835
(Ilya Rabchenok)
How to achieve real flexibility in the organization
У записи 2 лайков,
0 репостов,
126 просмотров.
0 репостов,
126 просмотров.
Эту запись оставил(а) на своей стене Илья Рабченок
