Agile

Agile in English is the ability to move and respond quickly. In software development, Agile constitutes various ways of developing software through the collaboration of team members and end-users. The goal of Agile software development is to deliver value faster, improve quality, allow for change, and focus on end-users.

The Agile manifesto, which is a published declaration of the views of seventeen leading software developers in the software industry composes of shared experiences in regards to what works and does not work in software development. The developers were looking for solutions to the current software development problems like unresponsiveness, too much documentation, and cumbersomeness. Therefore, they came up with twelve Agile software development principles and four values.

The Agile manifesto was not a declaration of facts but a comparison of different approaches, which is why many people embraced it. Under the manifesto, people received the titles of valuable resources other than just members of the workforce. Previous methods relied more on resources than on people. They also made it possible for people to go back and forth on their projects, get feedback from end-users, make changes, and continuously test their work. With the traditional methods, developers had to come up with a plan upfront and complete every stage before proceeding.

The manifesto also allowed for more flexibility where developers could ship software in time as opposed to shipping when the work was already obsolete. Unlike the previous methods that encouraged developers to build software to completion, the Agile development emphasized developing software in various stages.

Development Of The Agile Manifesto
The Agile manifesto leads to the creation of software, which offered its users new versions or releases after short periods of work called sprints. This approach was different from the traditional methods where the developers had to compile all their work first and then building the software all at once. When using the traditional method, it was only after completion that the people involved released the project.

Traditional methods expected developers to come up with the software layout and design upfront. Then actual implementation followed the direction of the design. People considered a project successful when development went according to plan. With Agile, they still make plans, which they revise constantly. Here the value delivered by the software is the basis on which the project is successful.

Sharing the project in sprints also has its advantages. If the people concerned detect a problem in the early stages, it is cheaper and easier to fix it than if one has to wait and fix it after completion.

History of Agile

We can trace the foundations of software development back to the 1950s up until the present day. Herbert Benington did the first presentation on software engineering, which involved the development of software for SAGE, in 1956. Winston W. Royce later followed his work in 1970 to come up with the waterfall model. This model clearly defined the various phases of the software development cycle, requirements, design, implementation, testing, and maintenance. However, despite its many advantages, it also had its limitations. For example, it was not ideal for large-sized projects, and it was very difficult to track down defects.

The other software development methods used then only worked for the projects when one knew exactly what you wanted to do. However, it became very restrictive for other projects. As people realized a lot of software development work required moving back and forth, so coming up with a set in stone plan upfront was not working. There was also the issue of waiting until the end to test the project. Identifying bugs and trying to fix them when the project was already complete was often a nightmare, and people had no option but to abandon some projects.

Foundation theories and practices on software development began to be formulated between 1970 and 1990. However, with the rapid increase in software development use, a crisis started emerging in the 1990s when everything was changing too fast. Within a few years, requirements, businesses, and systems were likely to change. This caused the cancellation of many projects before people could even put them to use.

People became frustrated with the lead times and the set-in-stone decisions that were made earlier in the projects. A few methodologies and frameworks were developed and used to improve software quality while responding to changing customer requirements. These included rapid application development (RAD), Scrum, DSDM, Crystal methods, and extreme programming (XP) among others. However, critics found some of these methods to be over-regulated, document-driven, and micro-managed and decided to come up with lightweight software development methods. They needed something more timely and responsive.

In 2001 a group of seventeen software developers who named themselves “The Agile Alliance” met at the Snowbird ski resort in Utah for a three-day retreat to discuss these lightweight development methods. They needed to come up with ways of developing software in a fast and straightforward way that delivered it in the hands of the users on time while reducing documentation overload among other things. Based on their ideas and experience in developing software, they came up with commonalities and differences.

These software developers came up with different ideas and documented what worked and did not work in a given situation. They did not agree on everything right away. However, among what they did all agree on were four Agile software development values. In 2005, two developers named Alistair Cockburn and Jim Highsmith, who were among the seventeen wrote 12 project management principles that people would use as a guide to The Manifesto for Agile Software Development. The manifesto now comprised of a set of frameworks and practices based on the expressed values and principles.

Coming up with a word for their work was also not an easy task; they wanted to use “lightweight”, but the majority of the Alliance did not like it. Finally, they settled on “Agile.” Nevertheless, one British developer aired a concern that most Americans did not know how to pronounce the word “Agile”. The other close contender was “Adaptive”, however, they finally settled on “Agile”.

After sharing the manifesto online via their website, people received an invitation to sign it, to declare their public support. People all over the world then started using Agile approaches in their organizations. In 2011, 16 of the Agile Alliance authors met again to recollect and review the Agile manifesto.

The Four Values Of Agile

The manifesto was about uncovering better ways of developing software, which leads to following these four core values. The main roles of these values are to put people before processes, deliver value faster, collaborate more with end-users, and to make changes when needed. This shows that as much as the following things on the right are significant, we should value more those on the left.

1. Individuals And Interactions Over Processes And Tools
   Even with well-researched processes and high-tech tools, what makes a project successful is the team and team effort. The ability of the team to communicate and interact well is more important than the tools and processes used. A team that works together and communicates effectively is likely to be successful with or without the necessary tools and processes. Therefore, developers should put people over process.
2. Customer Collaboration Over Contract Negotiation
   With the earlier traditional methods, end-users or customers negotiated their requirements for the project in detail before the project started. Agile encourages customers to collaborate throughout the development process or at various intervals. This ensures that the project meets the customer’s needs.
3. Working Software Over Comprehensive Documentation
   The heavyweight methods required a lot of extensive documentation before any code work began. Documenting a whole project caused many delays. Under the manifesto, the developers wanted to do away with the heavy documentation, not eliminating it entirely but instead streamlining it to deliver the software faster to their clients. Under the manifesto, developers should focus on making software that works practically as opposed to one that only works on paper.
4. Responding To Change Over Following A Plan
   Traditional methods preferred a more set-in-stone plan where any changes on various projects were not considered much. This all changed with Agile. Developers can now respond to changes and move back and forth on their work. A project plan is important but it should be able to accommodate changes. Agile development encourages developers to be open to change. After all, the change adds value and improves quality.

Agile Software Development Methodologies and its Applications

Although all the following methodologies existed before the creation of the Agile manifesto, they are now referred to the Agile software development methods.

1. Scrum
   Scrum is the most popular lightweight process framework for Agile methodology. Lightweight means that any overhead is cut down to ensure the full maximization of available time. As a process framework, scrum works with a team of fewer than ten people who divide their work into cycles called sprints, which should be completed between two weeks and a month. The team will hold daily scrum meetings to keep track of progress.
   Scrum uses three main users:
   • The development team who plays the role of supporting and developing the system
   • The scrum master, the person who acts as a buffer between the team and the outside world
   • The product owner who represents the stakeholders

   Scrum follows the following interlocking steps:

   • The product owner shares a prioritized wish list known as a product backlog
   • The development team takes the information at the top of the wish list called the sprint backlog and starts implementation
   • The development team completes their sprint backlog tasks and assesses them in a meeting called daily scrum
   • The scrum master ensures the team focuses on the goal
   • The scrum master then delivers the work, reviews it and sets goals for the new set of sprints
   • The cycle repeats

   Every task at Scrum has a timeframe called Time Box, which helps managers know what is happening at every given time.

2. Adaptive Software Development (ASD)
   ASD is a methodology for quickly building complex systems and applications. It is a shorter-interval version of an earlier Agile framework known as the rapid application development (RAD). ASD replaces the waterfall model with three phases; speculate, collaborate and learn cycles. These cycles ensure learning is done throughout the project and that the project is iterative, risk-driven and change tolerant.

   ASD focuses on end-users and timely delivery. It also encourages transparency between developers and users. Its weaknesses include the high demand of user involvement and an increase in costs due to tests done at each stage.

3. Dynamic Systems Development Method (DSDM)
   Initially created to develop and promote the RAD frameworks, DSDM was revised to an Agile framework that promoted project management and delivered a solution. DSDM is not only used for software development and developing codes, but it is also used for non-IT projects. DSDM uses the Moscow prioritization to ensure the project time constraints are met. DSDM focuses on eight principles:
   • The business needs
   • Timely delivery
   • Does not compromise on quality
   • Collaboration with clients
   • Strong foundations
   • Iterative development
   • Constant and clear communication throughout the project
   • Demonstrate project control
4. Crystal Methods
   This family of lightweight methodologies developed by Alistair Cockburn came about because of various teams that did not follow the formal methodologies but still had successful projects. Crystal methods, therefore, combine all those methods. The biggest focus is on people, interactions, community, skills, talent, and communication.

   The crystal family of methodologies is divided into different colors. This is because projects are based on size and criticality. They use various colors to represent project size and criticality to know which methodology to use. For example, if a project is small, they use crystal clear or crystal yellow. If a project is in a critical condition, they use crystal sapphire or crystal diamond methods.

   Even though crystal methods use various methodologies, their projects have many common properties. These include the following:

   • Have regular releases of the iterations of the software program
   • Developers work on continually improving their processes
   • Teams maintain osmotic communication where they all have to gather in a room and communicate with each other
   • Allow everyone to share their views and opinions
   • Focus on the goals of the project and individual tasks
   • Work with a person of expertise who answers questions and helps solve problems
   • Ensure continuous integration and testing to spot for any errors made
5. Feature Driven Development (FDD)
   FFD combines some of the best practices in software development into a cohesive whole. This lightweight methodology uses repetitive processes and incremental software development process that consists of five basic activities:
   • Develop the overall model – Document the context and scope of the system then create detailed domains for each modeling area
   • Build a list of features – Identify a list of features by functionality. The feature list is made up of small pieces of client-valued functions, which should not take more than two weeks to complete
   • Plan by feature – Develop the plan and assign ownership of features
   • Design by feature – Develop a design package within two weeks. Refine it and inspected it
   • Build by feature – Class owners develop the code as per the client request, which is tested and inspected
6. Lean Software Development (LSD)
   This methodology focuses on delivering what is need by optimizing time and resources while reducing cost. LSD developers usually release a minimum version of the product in the market, get feedback from users, and then incorporate the changes. LSD follows a set of seven principles:
   • Elimination of any wastes as a result of reworks, defects, and mismanagement
   • Emphasize learning to enable developers to write and test codes easily
   • Delay decision making to avoid using assumptions
   • Timely delivery
   • Empower the teams to ensure the best are hired
   • Ensure integrity is maintained
   • Create an accurate and deep understanding of the product as a whole
7. Extreme Programming (XP)
   This software development methodology is designed to improve software quality and its ability to adapt to the changing need for endusers properly. XP aimed at taking the best practices of software development to extreme levels. This included things like further shortening the development time of projects. XP programming follows the following concepts:
   1. Goals
      XP focuses on productively producing higher-quality software. It aims at reducing costs by delivering several short cycles of projects as opposed to delivering one big one.
   2. Activities
      XP follows four basic activities in its software development process.
      • Coding- this is the most important part of software development. Coding is used to develop a working product, figure out solutions, and communicates complex programming problems.
      • Testing- XP follows the notion that if a little testing can get rid of a few defects then a lot of testing can eliminate more defects.
      • Listening- XP developers have to listen to the feedback given by the customers. They then have to provide them with feedback on whether they can solve their problems or not.
      • Designing- a good design eliminates dependencies within a system; therefore, developers have to create a design structure that shows the system logically.
   3. Values
      XP follows five key values:
      • Communication – Make sure the system requirements are communicated to the developers. XP collaborates with endusers through the maintenance of frequent feedback.
      • Simplicity – XP favors simplicity when it comes to software development. They do so by focusing on the needs of today rather than those of tomorrow. Simplicity also ensures everyone on the team understands the code.
      • Feedback – XP values all feedback from the system, customers and the team.
      • Courage – Having courage enables developers to be comfortable making changes to their codes, be persistent, and know when it is time to throw away obsolete codes.
      • Respect – XP values respect for others as well as self-respect. Programmers should respect their work and that of their fellow team members.
   4. Rules
      XP follows two categories of rules:
      • Rules of engagement – Those in charge of the environment where software development occurs.
      • Rules of play – These are the activities and rules within the rules of engagement. For example, under testing, all codes must have unit tests.
   5. Principles
      The principles of XP are based on the above values, whose purpose is to foster decision-making.

Application for Agile Methodologies

Agile methodologies are not limited to IT companies. They are being used in non-IT domains. Here are five industries that have adopted Agile methods:

1. Finance industry
   Financial companies have used Agile methodologies to curb risk management, payment procession, and increase services. For example, Principal Financial Group, an insurance provider, uses Agile to bring IT and business together. This ensures that when a problem occurs, it can be identified without taking the entire app back.
2. Construction industry
   The construction industry usually requires high capital, tight schedules, and risk regulation; with the Agile methodology, they can solve all these problems. A company called Noble Energy is using Agile project management to streamline workflow and ensure communication between contractors and teams is done on time.
3. Marketing and advertising industry
   Agile methods have proven to be successful in enhancing productivity and decision-making. That is why marketing and advertising companies are adopting it. For example, Carsurfing is a company that finds rides for its users. It is now using Agile technology to get feedback from clients during development, input the changes, and test the user interface as opposed to launching the final product at the end.
4. Product Development industries
   Product driven companies are now using Agile methodologies to ensure timely delivery. A company called LEGO Digital Solutions, which focuses on communication between parents and kids, uses Agile for cross-team alignment and client collaboration.
5. Event planning industry
   Event planning companies have been able to use Agile methodologies to make real-time changes due to feedback given by customers. They also use the iterative framework to ensure continuous improvement.

Other industries that have adopted Agile methods include engineering, medical, automobiles, pharmaceuticals, food, and many others. Companies are adopting Agile methods to get benefits like:

• Fast turnaround times
• Transparency
• Reduce wastage
• Optimizing time and resources while reducing cost
• Faster detection of flaws
• A lightweight framework
• Focus on end-users
• Ensure flexibility
• Adopt changes
• Have project control
• Improve quality

The 12 principles of Agile

Principle 1: The top priority in Agile is customer satisfaction, which is achieved by prompt and continuous delivery of valuable software
As always, the customer is king and is at the center of any business. Agile developers must collect feedback on a continuous basis, if possible, from the beginning of the project and deliver the changes as soon as they can. Delaying delivery, even with a super product, can be bad for business. It is important to remember that a customer can move to the next shop if they do not get their delivery in a reasonable amount of time. Therefore, developers must not wait too long between releases. They should always have the time factor at the back of their minds if they are to achieve complete customer satisfaction.

Principle 2: Factor in changing requirements at any point in the development process
Agile processes accommodate changes as they occur throughout development. Such changes can include customer needs, a different market, and threats from competitors. Rather than wait for the next project, it is advisable for people to accommodate the changes as they occur; otherwise, the product may prove to be irrelevant in comparison to customers’ needs or a competitor’s product. Despite the disruption they bring, developers should always be on the lookout for any changes. They should make the necessary adjustments as soon as is possible and move on to the next phase. Fighting necessary changes can be costly and time-consuming.

Principle 3: Deliver working software on a frequent basis either every couple of weeks or on a monthly basis but the shorter the period, the better
Agile developers do not waste time thinking and planning; they just decide and do. The faster they deliver working software, the sooner they can collect feedback from the customer and correct any changes that are required thereby satisfying their customers’ needs. The mini releases can keep customers at the edge anticipating more. Clearly, Agile methodologies focus more time and money on project development rather than the initial stages of planning, like is seen with other techniques of project management.

Principle 4: Cohesion of efforts between business people and developers is required throughout the project
The business team usually deals directly with the customers and can, therefore, give a report of what exactly the customers want or market needs. Having intermediaries such as analysts between business people and developers can be disadvantageous for a company. Those who have ever played broken telephone can relate to this. By the time a message passes through a number of people, it arrives typically distorted.

By putting more and more people between the aforementioned two groups, the lines of communication become weak, and the people who suffer are the customers. To avoid this, the business side and the technical side should work closely together. They should be encouraged to have regular meets to discuss and clarify issues so that everyone remains on the same page.

Principle 5: Motivate those involved by giving them support, a conducive working environment, and trust
Agile does not believe in micromanaging and handholding of staff. Once the development strategy is clear to all staff, each person is assigned his or her responsibility, which the team leaves and trusts that he or she will carry out his or her duties. When the right people come in and receive the tools they need, then they are able to push themselves to complete the project in good time and within the budget. The top-down approach does not work for Agile developers, and if they are not given the right environment, they will move to other better organizations.

Principle 6: The best way to exchange information with one another in a development team is through face-to-face interactions
Technology has developed more and easier ways of communication, but they still do not surpass face-to-face interactions. Video conferences might show facial expressions and body language, but they still need to factor in people’s schedules, time difference, and technology failures. They may work when a team is scattered all over, but there is just something about face-to-face interactions that foster unity and collaboration. Complex issues can be discussed more clearly while information is shared faster and more easily. This principle is also the reason why people travel thousands of miles just to have a face-to-face meeting that will finally seal the deal.

Principle 7: The progress of the development is seen primarily through working software
As much as developers move at a steady pace and check off minor tasks, the primary goal of the project is the final success of the software. If the effort of the team in completing subtasks does not result in the completion of the software, then customers have no product. As long as the software has not been shipped or released, then it is considered still unfinished and is still viewed as a cost to the company instead of an income-generating stream. This principle seeks to caution those who hold onto a product because it has not been perfected and those who focus so much on preparing documentation.

Principle 8: The sponsors, developers, and users should all maintain consistency
Some projects can take a long time to complete. When this is the case, there is a high chance of burnout, reduced motivation, and compromised quality of the final product. The best way to develop and maintain a certain pace is by doing work in short bursts of activity. The team should never overextend themselves with long nights and work on weekends as this will affect the quality of the project. Since everyone is a hard worker and is focused as well as self-motivated, they do what is required of them and always right on schedule. Work-life balance is advocated by the Agile methodology.

Principle 9: Continuous attention to technical and design details enhances agility
In most cases, the final product produced through Agile methodologies has an excellent design because of the expertise of the team. There is no need for constantly refining code because of the aforementioned and the frequency of iterations. The final solution that the team arrives at is also updateable to keep it fresh and current. Any new information collected and lessons from previous projects are normally considered in the next project.

Principle 10: Keeping it simple is essential
Agile methods define simplicity as the art of maximizing the amount of work not being done. Agile developers like to keep things simple because they realize that unnecessary complexities interfere with the pace of the project. They always do away with irrelevant procedures and data, which leaves them more time to focus on adding value to the project. They also save the organization they work with a good amount of money by using simple methodologies. In addition to this kind of thinking mentality, developers use the Pareto principle, which stipulates that 80% of the results should be achieved with just 20% of the work.

Principle 11: Self-organizing teams produce the best architectures, requirements, and designs
Agile developers own their work, which means that they take full responsibility for organizing themselves to achieve stipulated results. Management does not interfere with how they carry their duties, and rarely do they give any input. The developers do everything for themselves, from designing to choosing their methodologies to delivering results. They make decisions as a group rather than getting instructions from a manager. Having chosen the right people from the onset, an organization can count on an Agile developer to deliver.

Principle 12: Regular reflections and adjustments are important to achieve effectiveness
The benefits of having a self-motivated and self-organized team include the team’s ability to stop, reflect, and make adjustments as they progress. An Agile team cares for self-improvement as well as improvement of processes.

The Benefits Of Agile In Software Development

1. Workflow
   Overall, Agile project management ensures that workflow goes on smoothly. The model assists in breaking down long projects into smaller units. This means that the units can be worked on one by one thus moving the team closer to the finish line. By anticipating changes, the development team is also able to find quick solutions, integrate them and move on to the next phase of the project.
2. Team Morale
   Agile developers are, in most cases self-motivated and self-organized. Management normally leaves them to come up with their own strategies of completing a task and with minimal interference. This means that the team can exercise their knowledge, creativity, and expertise, which boosts their work ethics and morale. The team members are also able to teach and learn from one another and work cohesively together, which fosters even more teamwork and team spirit. The lack of micromanagement gives the team the confidence to make important decisions.
3. Early Detection Of Problems By testing and releasing continuous bits of the final product, Agile developers are able to document any fault with their work and rectify it. Since customer feedback is also collected as early as the first release, any concerns can be looked at and rectified or added to the next release.
4. High-Quality Products
   Agile development produces high-quality products because of a number of reasons. For starters, bigger projects can be broken into manageable units, which means that the team is able to develop, test, and release smaller incremental software. The regular releases of products with add-ins and corrections contribute to the quality of the final product. Feedback from customers is collected on a continuous basis, and the changes are implemented as soon as is possible. This not only makes sure that the software is up to date with the market needs but that it is also able to compete with other upcoming software in the market. The continuous testing of the product using automated testing tools and usage by customers ensures a quality product.
5. Transparency
   There is transparency in Agile methodologies. Developers are very keen on getting feedback from the clients about their software. This means that they are aware that their software does not always meet all the customers’ requirements. Every customer request or need not met is considered during the next release. Customers on the other hand, also use the software, which they know is a work in progress. They are keen to give feedback using the proper channels and are able to trust that developers will adhere to their requests. This transparency is crucial between the two parties as it brings about understanding among the two.
6. Predictable Delivery
   Since projects can be split into smaller projects, the delivery of the smaller and final product is predictable. The short outburst of activities and utilization of the Pareto rule ensures that a particular task is achieved within the shortest time possible and with minimal efforts. Choosing simplicity also ensures that a project is delivered within the agreed timelines. Moving at a consistent pace also guarantees that people involved meet the project deadlines.
7. Predictable Budget
   An Agile work set up does not encourage working overtime or working on weekends, which would require the organization to pay for the extra hours. Small projects are confined and delivered within the set time box; therefore, no extra amount of money is utilized to extend the work on the project. Since work also moves at a consistent pace, an organization is also able to approximate the budget of each face and the final cost of the project.
8. Customer Satisfaction
   By regularly interacting with the customers and business people, developers are able to make sure that they deliver a product that is suited and tailor-made to the customers’ requirements and needs. Customers are also pleased with developers who listen to their needs and adjust accordingly. The periodic releases of iterations also give the customers early access to the final product and give them the chance to give their opinion, so in a way, they are also part of the success of the final product. Iterations also demonstrate the development of the project to the customers and stakeholders. Customers are also happy when products get to them on time.
9. Flexibility
   Agile processes promote flexibility, which is very crucial in software development. The development of software requires frequent adjustments, which Agile developers constantly look out for. They are able to attend to any changes without requiring more time and stepping out of the agreed budget.
10. Increase business value
    When Agile developers are able to work collaboratively with one another and the business team, they are able to deliver a product that satisfies the customers’ needs. This makes the stakeholders of the organization they work for happy. They develop trust in the team’s ability to deliver on tasks assigned and are motivated to provide whatever necessary, including a good working environment for the staff to carry out their work. This positive environment also fosters more engagement among stakeholders and the team and this encourages the progression of projects. An Agile team also makes good profits for the organization when they release continuous iterations for its customers that are of good quality.

How To Experience Success In The Adoption Of Agile Modeling

1. Train people
   A person cannot adopt a practice that he or she is not conversant with. Any individual, group of people, managers, or company owners who wish to adopt an Agile model must carry out extensive reading on what Agile modeling is. They must then make a conscious effort to educate the rest of the team on what Agile modeling is and how it can be beneficial to project management, the organization, or a company. People should also be allowed to discuss the adoption of the model and their views on the model as well as what they like and do not like about the new model that is about to be introduced, and concerns should be addressed as soon as possible.

   Agile requires the participation of every team member, so unless everyone is on the same page, the likelihood of the model succeeding is slim. If a team is struggling with understanding or adopting the new changes, an Agile coach can offer more insight. They can also advise on the best practices as well as give examples of other people or organizations that have benefited from adopting Agile. The team can also do its own independent research and gather more information on the methodology.

2. Action
   Agile modeling does not believe in waiting for perfection or spending too much time holding onto a workable product instead of releasing it. This principle also applies to the implementation and success of Agile. Rather than waiting for all the issues to be ironed out, the model should be implemented then any issues or concerns can be addressed while on the move. The more time people spend talking about the model, the more anxiety builds up about the workability of the model. Adopting it will also give people an idea of what they will be dealing with and even encourage deeper discussions about the usage of the model.
3. Communicate
   Effective communication is necessary for the success of any project, including the implementation of new working models like Agile to an organization or business. People must have a platform to air the views, expectations, and concerns as well as the problems they have encountered. There are different modes of communication including emails, phones and video conferencing.

   However, Agile prefers face-to-face conversations because they are the most effective. It is difficult to see people’s reactions through email or telephone conversation. Exchanges are also fast, and solutions can be communicated in real-time rather than waiting for a question to be drafted to and responded to on email. Regular meetings are also important to check on the status of progress.

4. Commitment
   Every single person whose involvement is required in Agile must be committed to using the model and benefiting from it. Everyone, the team, the stakeholders and the business team must be willing to adopt and use the model for it to work. Customers should also be let in on the collaboration because after they are the end-users of the product developed by a company or organization. The highest priority for any business and especially those that use Agile models or intend to use them is customer satisfaction; therefore, involving a few customers in the development process can ensure that most customer needs are met.
5. Encourage teamwork
   Agile believes in cohesive collaboration between people in an organization and especially business people and product developers. The fewer intermediaries there are, the better. Top managers should sit in on meetings and interact directly with the staff to understand their challenges. These face-to-face interactions as earlier discussed are more beneficial rather than email communication. Every person’s contribution is required and important to ensure the successful adoption of Agile. Top-down management is also discouraged in Agile, letting a team come up with their own solution and strategies will motivate them to deliver even more than is expected. More importantly, the management should try to win people through pulling rather than pushing.
6. Provide tools
   As an organization embarks on its journey to adopt Agile modeling, it should ensure that it has all the right resources to ensure a smooth transition. All the people who make up the organization other than staff must be present, including managers, stakeholders, and decision-makers. Any important issue, no matter how trivial it seems, should be dealt with. Coaches and facilitators should also be included if need be.
7. Document statistics
   It goes without saying that the collection and documentation of different statistics are important to track the development of the implementation of a project. The same data can also be presented to stakeholders to give them an idea of what is happening. Documenting statistics is also a way of indirectly obtaining feedback from the staff as they try to adjust to the new changes. These statistics can be used to provide insights on some of the challenges in the system. Solutions can then be designed to handle these challenges.