For various reasons the organization will adopt agile methods. Some organizations want to increase productivity and shorten time to market, and some organizations want to be able to get more successful products, there are some organizations want to enhance collaboration between developers and business people, in order to improve the quality or increase the job satisfaction of team members .
Of course, there are many organizations adopt Agile is hoping to simultaneously achieve a combination of these benefits.
However, in order from Agile benefit as much as possible, the organization seems there is a lot of misunderstanding. In this article, I want to talk about six misconceptions about agile product development.
Myth 1: Agile software development is not only for you?
This misunderstanding is very interesting, because as the oldest Agile, Scrum originated in the development of physical products. The initial Scrum project copier, Honda and cameras.
Today, Agility has been widely used in various forms of product development, from physical products to the cloud-based software as a service (SaaS).
But in addition to product development (including hardware and software), the Agility has been successfully applied to:
● marketing team to carry out activities planned and executed
● attorney to manage cases and workload
● Organizational Transformation (especially the agile transformation) Transaction Management
● senior leadership team to manage their organization
● family used to improve coexistence time
● couples planning a wedding
, of course, there's more. Any matters more unique (ten times you have never done before) and complex are well suited to agile. If you are bothered due to the Agile Manifesto we use the term "software", just use "products" instead of the word can be. For example, the "Available Software" can be changed to "available product", and then re-read: [We advocate] "usable product" is better than "well documented." very suitable. why? Because agility can be used for all types of products - the software is just one of them.
Myth # 2: Really manager role does not exist in Agile do?
I think this misconception still exists, because too many managers spend a lot of time to do things they should not do, or not agile and disregard.
For example, managers often work to break down the individual task level. When he learned that this is not their work in an agile, they will feel their jobs are deprived.
Not so, not completely cancel the job.
First, assign tasks such as trivia and the like, should not have become part of the job.
Managers should focus on creating a team to flourish in the environment and culture. It should not consume their time on tasks such as who should do which chores.
• Peter Drucker (Peter Drucker) management is perhaps the leading theorists of the 20th century. He acronym SMART goal-management ideas and set goals for the first letter created (goal must be specific, measurable, achievable, relevant and time-bound) is known. Drucker said, there are five managers work:
● set objectives
● organization and the work
● motivation and communication
● measure
● train people
, of course, in some organizations, some of which liability may weaken. But some other responsibilities - such as training people to become more important.
In these years I agile and cooperation with agile organizations, no one will decide to dismiss all managers. Yes, although some managers have been converted to work more focused Scrum Master or Product Owner role, but there is still the manager role in Agile.
Myth 3: Stakeholders are not ready to initiate changes?
Not surprisingly, the most common misconception to believe that (the stakeholders can initiate change at any time) people are stakeholders themselves.
Development team members are understood to introduce changes at the wrong time is takes the price.
Imagine a meal in the restaurant scene. You tell the waiter you'd like to have chicken, followed immediately he said: "No, change to salmon."
This change is no cost.
However, if you later change your mind, you pay the price. If the start in the kitchen to cook the chicken, the waiter will tell you your meals change from chicken salmon, there will be food waste costs (restaurant might charge you).
If the former tell the waiter that you want to change salmon, you have a half-eaten chicken, and that cost will be more apparent.
Stakeholders to change into the iteration, just as those who eat the chicken into the same salmon. If changes are made at the right time, not even the cost may be small. When it is introduced at the wrong time, is a price to pay.
Agile does not eliminate the cost of all the stakeholders to introduce changes. However, regardless of when introducing change, outstanding agility team can reduce the cost of change. Commonly used methods are:
● short iterations
● product to be short term do
● minimize the number of regular work in parallel, in order to complete as quickly as possible for each product item to-do
does not mean that the team should not welcome appropriate changes. Some stakeholders may need to change is very important. However, the cost of change is not always zero, for each change should be controlled to change its assessment of the cost of benefits.
Myth 4: It is not agile team everyone should be generalists do?
For some reason, there is a misconception about agile is very popular, that is, each team member needs to do all the work.
This misconception means that if you hired the world's best Oracle database administrator, you also want the database administrator is also the name of good JavaScript developer. And, if not too much development work in JavaScript iteration, then you exceptional JavaScript developers also should be fully versed in safety testing.
This is completely wrong.
Agile teams need not everyone possesses all the skills, but pay attention to any firm with a variety of professional skills of the team members.
To understand wrong with this misunderstanding, imagine there is a well-run high-end restaurants. From the look of the TV cooking show, I learned that this restaurant may have confectioner. Confectioner good at making cakes, desserts, breads and other baked goods.
This sounds like a skilled but specialized role. Another special role of the kitchen is probably sauces division, he was responsible for preparing sauces, stews and other similar foods.
In this well-functioning kitchen, pastry chefs can help if the sauce division, for example in the case of a sudden shortage of onions help cut some onions, it has been very good. But no matter pastry or sauces division, can not expect its fully qualified for each other's work.
In today's complex world of technology, expect all team members to fully versed in the skills of the team is not realistic. Instead, the outstanding agile teams to learn to pay attention to grasp the multi-skilled team members.
Has several multi-skilled team members, will contribute to the management of the type of balance. For example, sometimes the team needs more testing jobs, if there are one or two team members can turn to do the test work, can greatly help.
However, most of the team even though there are a few team members are the real experts and only good at one discipline, but also to do it (ie has several multi-skilled team members).
Myth 5: I've heard that agile teams plan to do
most agile team will do an excellent plan. But, compared with the traditional items, such plans are usually less obvious, because Agile teams do not plan an early stage.
Instead, the outstanding agile teams are planned as a series of small, repetitive activities implemented to ensure that plans always reflect the current situation.
Thus, by continuing review and adjustment, the team will be able to develop a way to do product plan.
For any agile team, its extent should be limited to plans require major decisions, and not too far into the future. However, most organizations will have a team and a plan to some extent what is estimated to be completed next and when.
In fact, despite this misunderstanding, because the rate of its insight into the development of software as soon as possible, agile teams can more easily develop a credible plan.
Imagine a traditional team analysis, design, coding and testing phases. If you are lucky enough, the team may be able to submit a plan postponed until the end of the design phase. But even then, the team still do not know them on the coding and testing how fast - they have not carried out any such activities.
In contrast, Agile teams each iteration of operation of the entire development process. Each iteration will include some of the analysis, design, coding and testing activities. This allows insight into Agile teams can as soon as possible, which is capable of how fast the ideas into new features.
Myth 6: Agile product development team planning framework does not it?
Finally time to get rid of the last of a misunderstanding - about Agile teams do not do architecture and product design misunderstanding.
Agile teams will certainly design their products. Agile teams the same way, incrementally planning, architecture and design. This enables them to continue to review and adjust its architecture and design, making it the best solution.
This means there is no pre-decision stage all architectures. Instead, the product architecture will emerge over time.
Technical team members will focus first on any aspect of the product that they think there's risk. For example, if the product to be delivered on the required throughput challenges, the team and the product owner will choose to study how to achieve the goal in the early days, in order to reduce the risk.
Similarly, emerging architecture design agile product also deliberate. Architecture is not a day to appear. It is under the deliberate guidance of the technical team gradually emerging.
This means that the product does have agile infrastructure. However, decisions about the architecture is needed during the project made, rather than at the beginning of the project is completely made.
(Source: Scrum Chinese net Author: Mike Cohn Translator: Li Jie)
