Change is hard for anyone, and even harder for a team. In the same way, the big changes that come with the Agile transition can be tough. Sometimes, even, agile transitions can lead to short-term productivity declines.
In order to help more R&D teams make the transition to Agile, we have compiled this list based on more than 10 years of management practice: The 6 Mistakes of Agile Transition
01 Start with training
Involving the entire team in agile training is an intuitive choice before the transition begins. However, going to class before the team is really ready can cause some problems.
Lack of psychological identity or incompetence in the work situation may leave the team with only a small amount of Agile knowledge to assimilate after training; A small number of team members may even challenge the concept because they don’t share it, which can affect the motivation of the whole team.
The most critical step to the success of any transition is to understand why it needs to change. Everyone needs to understand the benefits of Agile. When used properly, Agile enables teams to deliver faster, deliver some value to customers right away, and get customer feedback earlier. In a traditional waterfall project, the team also communicates regularly with the customer. However, due to the lack of real-time feedback from customers, the team is difficult to adapt to the change of demand quickly, and the final product delivered naturally cannot meet the needs of customers.
Formal training becomes important when team members understand why Agile transformation is needed and what it means to everyone’s work, and they identify with it. The team will be aligned in their understanding and communication of Agile, which is the foundation for a successful transition.
It is important to emphasize that a successful agile transition team must be a self-driven team, not a heavily regulated one.
02 Agile is Scrum?
No! Agile is a methodology and Scrum is one of the most mainstream Agile frameworks.
Agile was officially born in 2001 when 17 developers came together to publish the “Agile Software Development Manifesto”. Before that, many of the frameworks we know today like Scrum, XP, FDD and so on existed. These frameworks and later, Kanban, took a lot of advanced ideas from manufacturing and applied them to software development. Understanding and choosing the right framework for you is critical in the agile transition.
Photo source:https://www.systemsvalley.com…
Agile projects don’t need planning…
For a traditional waterfall project, a task breakdown Gantt chart is planned in detail before the project begins. However, in the real process of the project, the requirements are always changing, and even some requirements or potential problems are unpredictable at the beginning of the project, so the detailed plan made at the beginning of the project will appear to be weak.
However, this does not mean that agile projects do not have a plan. The process of planning is an ongoing and changing process.
Before an agile project begins, the team should establish the overall goals of the project; Then, before each iteration, develop an iteration plan (detailing the requirements for this iteration and the corresponding work tasks). With continuous delivery through iterations and customer feedback, Agile project plans are constantly being adjusted to maximize the value delivered to the customer.
Helping the team adapt to the uncertainty of the project and planning based on change enables the team to transform more quickly.
04 Go back easily
Few people enjoy change, and in times of stress, people tend to revert to their accustomed ways of working. In every Agile transition, the team’s commitment to the Agile transition is tested. When a transformational project runs into trouble, don’t simply give up and take back control of a self-organizing team.
When programs and projects run into difficulties, trust the process and use the continuous improvement mechanisms of the agile framework to reflect on what needs to be adjusted and improve in the next iteration. This may reduce the productivity of the team in the short term, but it will lead to long-term success in the Agile transformation.
McKinsey has done research on the agile transformation of many Fortune 500 companies. One example is Asia’s telecoms giant. The company’s performance is measured by time to market and achievement of performance targets. In the three months after the company’s top management decided to adopt an agile approach, performance fell. But after three months, the company’s performance began to grow rapidly, eventually surpassing its pre-Agile level.
Agile works for any project, any team
The larger the team, the less flexible it is. Conway’s Law concludes that “the organization of design systems is limited to production designs, which are copies of the organization’s communication structure”. Agile best practice is to divide the larger team into different Agile teams by product or project, taking advantage of the low cost of communication.
For projects with long cycles, clearly defined requirements that will not change, and clearly defined scope and work tasks before the project begins, waterfall may be a better choice because the team is highly focused at each stage of the project. But in the long run, agile teams are more value-driven and better able to deliver.
06 Agile Is Faster to Write Code?
If a team makes accelerating development the goal of an agile transformation, they are likely to be disappointed. Re-reading the 12 principles of Agile, it is not hard to see that Agile focuses on delivering some value to customers earlier, adapting quickly based on feedback and delivering value continuously.
For product development of the same amount of work, because agile projects spread development effort over multiple iterations, assuming no change in requirements, development can be even slower than waterfall. Perhaps the choice of Agile is not necessarily the same as the choice of high speed. In its essence, Agile does not necessarily guarantee the speed of product delivery, but it allows the team to adjust in real time to create a product that is more responsive to the customer’s needs.
Focusing on value, not speed, is the essence of agile transformation.
Agile has been around for 20 years and the traditional project management model has been around for more than 50 years. There is no absolute right or wrong between the two, for different types of work, different teams, how to find the most suitable way of working in the era of rapid change is the most important.
Finally, I enclose the 12 principles of Agile, which I hope will be enlightening to you:
1. Our highest priority is to deliver valuable software early and continuously to satisfy our customers.
2. Embrace changing requirements, even late in development. Agile uses change to create a competitive advantage for customers.
3. Deliver working software on a continuous basis in weeks to months, the shorter the better.
4. Business people and developers must work together on a daily basis throughout the project life.
5. Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done.
The most effective way of information transfer is face-to-face communication.
7. Working software is the first measure of progress.
8. Agile advocates sustainable development. Sponsors, developers, and users should be able to maintain a constant pace at all times.
9. A sustained focus on technical excellence and good design promotes agility.
10. Simplicity, the minimization of unnecessary work, is fundamental to Agile.
11. The best architecture, requirements, and designs come from self-organizing teams.
12. The team regularly reflects on how to become more effective and adjust its behavior accordingly.
We look forward to your finding value in the process of Agile practice, and welcome to discuss with us. We’ll be sharing more Agile and R&D management practices in the future, so don’t forget to follow us ~ for directions LigaAI@sf or Ligaai – a new generation of intelligent R&D management platform