The term "agility" has been unbearably used in various business talks as a crystal solution for companies, team members and individuals. Yet I often meet people don't understand clearly what it means and how it works.
As the widest explanation, agility is equal to meaning "to be flexible enough and change": make changes in competitive business fields and with an influence of customer needs, and also embrace changes in workplace training style and results delivery.
From the view of organizational possibilities, agile development looks like an amazing methodology. It brings an organization and its employees to be creative, to think logically, and to be trained on an ongoing basis. All of these details in return restructure an enterprise to be agile. In the studying and customizing part, agility shows itself through the usage of an agile development style.
The basics of agility and agile development are easy to comprehend, but rarely easy to implement. Successfully using these approaches in the company on the daily basis demands a systematical way of change. But to dig further and appreciate the company transformation of such a global change, it is great to know the basic philosophies of Agile.
The History of Agile
Agile development approach appeared in the IT industry. It is based on the supposition that IT requirements and project solutions should be completed through collaborative, self-managing and cross-functional teams.
These concepts were written in February 2001 "Agile Manifesto", at a meeting of 17 software developers and IT practitioners. The rules below shows the primary principles of Agile Manifesto and the key differences between traditional and agile approach.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
Agile-Disappointing Statements
As many businesses can assure, there's often an "action gap" between the rules and theory of any new approach and the effort the entire organization has to make to adopt it. One can face same experiences with agile IT development company culture.
Agile methodology requires cardinal changes in personal, management and team activities. The statements below show the real differences that mainly happen when a company decides to adopt an agile methodology without investing in and sustain systematical transition from traditional to the agile approach.
Disappointment # 1:
An agile methodology CAN'T be useful
without a high level of organizational trust.
When a cross-functional team starts the collaboration based on agile principles, they inevitably work through the Team Formation process. Team members learn more about each other, how they cope with problems and see the capabilities of professionalism, risk taking and collaboration. So, their personal experiences focuses on trust formation, and that's what leads to productivity.
Trust at the managerial level is just as essential as trust between the team members. Without the understanding influence and trust of major stakeholders, the fragile sprouts of agile initiatives will most likely die. Companies, determined to implement an agile approach with lack of trust, for example companies with tight vertical structures and restricted collaborative initiatives most probably will not be successful in agile methodology adoption.
The agile set of actions itself can seem strange to those who never faced it before. From the view of business profitability, the constantly improving core of an agile process may seem too changeable and imperfect, sometimes even like a huge mess. The decisions made may seem not appropriate, as the result of fast deliverables and minor mistakes made during the process.
What should wise management do?
- Appreciate trust-building initiaties in your teams.
- Push project management to follow and enhance the base of trust.
- Enrich your collaborative problem-solving skill with business trainings.
- Tend to take a consultative side, not an interfering partnership.
- Push the reasonable risk-taking as a positive habit.
- Create a team-based evaluation, awards and appreciation techniques.
- Define clear team and individual KPIs as an company internal priority.
- Allow and appreciate your team members to learn more.
- Rewrite job descriptions with personal competencies to focus on teamwork.
Disappointment # 2:
Agile working style CAN'T be
streamlined through a business process.
The major benefit of the agile methodology is in its flexibility, but not in its speed. In comparison with the traditional approach it's not any faster; just it is more responsive to the design and development requirements at every level of the project. The agile way of work can be achieved through a deep, mutual process, important for every team member and stakeholder.
That's where an inevitable seduction comes: to push an agile process faster by arranging less cross-functional teams, lessen the amount of touch points in the team, or decrease the collaboration between project clients and team members.
As a result, it only can destroy the communication and increase the risk that milestones wouldn't be delivered on time. It might look great for business to ease their processes for a more agile, responsive approach. But there are no miracles in the business world, and the more the company pressure is, the bigger the stress for the agile leader. who has to fight for a fully trustable and collaborative process. It leads to team frustration and deliverables reduction.
What can talented management do?
- Emphasize the importance of cross-functional actions inside teams.
- Remind the team leader and other members about the importance of the customers opinion in fast prototyping solutions.
- Make agile IT contracts clear for team members, clients and other stakeholders, describing the involvement and decision-making influence of them during the project.
- Let team members get more skills and competencies
Disappointment # 3:
Management way of making final
decisions DOESN'T bring good influence for agile development teams.
Agile methodology in IT field will be hard to maintain in a company that is not accustomed to provide and get feedback at all levels of enterprise structure. An absence of transparency from managerial level can be also a big stop on the way to agile team implementation.
Agile process demands ownership and involvement of key stakeholders from the beginning to the end, through all the iterations of IT project development.
What can smart management do?
- Provide transparency in decision-making process.
- Give an opportunity for agile teams to make decisions.
- Participate in problem-solving.
- Eliminate main stakeholder behavior by setting proper expectations for the responsibilities and involvement of the stakeholders.
- Talk more and often remind about the importance of participation and team responsibilities.
Disappointment # 4:
Budgeting procedures DO HAVE an
influence on agile development process.
Because of this lucid and flexible nature of the agile method, it also needs flexibility in giving a certain price of the IT project. While working, agile team need to feel assured that the project budget can adjust to changeable project needs. Instead of giving to a customer a fixed price, a company could stick to to step-by-step payments, according to milestones. Another way is to connect estimated cost to the hourly wage of agile teams, based on the previous experience.
What can great management do?
- Engage the finance stakeholders with the agile project early.
- Inform the clients that an agile process needs flexibility in key business actions, such as planning timelines, pricing and KPIs.
- Emphasize a bigger focus on value than on cost of the project.
- Explain stakeholders and team leaders on the value of prioritizing requiremen
Disappointment # 5:
Agile approach DOESN'T work for every
business.
While being aware of all this fuss about the easiness and productivity of agile processes, some companies might feel obliged into switching to an agile approach. As a matter of fact, an IT company can win from both traditional and agile approaches. In multiplying amount of projects, some are even requiring a mixed approach.
To say it easier, an agile way for IT projects is suitable when one or more of the following three conditions exists:
- A high percentage of uncertainty:
- A high level of complexity:
- Uniqueness or innovation:
: The project is changeable, or not documented. The performance actions are not well-defined. The project milestones, budget and estimated time are changing. Stakeholders are not very aware of, or can't agree on the requirements of the final result.
The final product and its performance context is structured and hard to learn. There are various levels of specialists and other stakeholders, demanding on a proper feedback process.
The IT project is unique and the solution needs new way of learning, suitable content, or new performance information.
What can understanding management do?
- Define certain characteristics for agile training and development projects.
- Accept a mixed approach for IT solutions.
- Involve a skilled agile specialist in the decision-making process.
Agile Team Competences
There are certain skills that members of an agile team can improve:
- Stable process management to create a vision and describe an optimal solution.
- Ability to assign the real stakeholders and their KPIs they work with.
- Problem-solving way of thinking to run the various dimensions of a required project.
- Ability to work well with uncertainty.
- Step-by-step build assurance and eliminate doubt or personal prejudges, which needs great commitment.
- Pay attention to the customer relationship, the actions during the iterations and agile project deliverables.
- Successively clarify expectations for primary needs.
- Express team needs in good time, and know how to deal with resistance.
- Personally ask for and give feedback.
- Ability to work effectively and efficiently as a part of the team.
- Define certain characteristics for agile training and development projects.
- Accept a mixed approach for IT solutions.
- Involve a skilled agile specialist in the decision-making process.
Moreover, an agile approach needs attention on company HR and management side, to switch certain norms and teams of people with particular skills who are ready to take ownership of a project from start to finish. Using an agile approach should also be considered on a project-to-project basis, rather than a total refusal of traditional approach at once: sometimes it might be best for an IT project to have aspects of both agile and traditional approaches.
Have you become disappointed about Agile techniques? Which approaches do you use? Are your developers happy?