Agile Methodology is one of the most used methodologies in the tech world. This methodology started in the 1990’s but didn’t become what we currently know it as until 2001 when the “Agile Manifesto” was published. The manifesto was created by a group of software developers that laid the foundation of the core values and principles of Agile development.

There are 12 principles in the Agile method:

1. Customer satisfaction through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, with a preference for shorter timescales.
4. Collaboration between business people and developers throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These 12 principles were developed in response to traditional product/project implementations, particularly the waterfall model.

Embracing Agile Methodology

Because Waterfall is a linear approach and an all-or-nothing style of development. Users were not able to judge the product until the original vision of requirements was implemented. Some projects can go years before a customer gets to use or see the product. By that time customers may lose interest or the product could become obsolete even before it is even finished. Millions of dollars lost to something that never even got the chance to exist.

Using an agile method at its root is to quickly deliver products and quickly change to make a better product for the customer. So instead of years before getting to a customer it should be months, maybe even as little as a week to see what was asked. In doing so you can succeed and grow fast or fail fast and quickly pivot to a successful plan.

I’m not going to break down this full methodology for you here; there are thousands of resources out there that already do this for you. What I will do is go over the importance of teamwork, collaboration, and communication and how the Agile method can help you do so.

Constant communication is a key point for all 12 principals. Who do you communicate with, dev team members have to communicate with each other, with the Quality Assurance team members, with the product owner, with the project manager or scrum master, with all the stakeholders, and most importantly with the impacted customers. Because the dev team is in contact with the customer they will be able to more clearly interpret the ask and will be able to have more ownership in what is released vs expecting the requirements document to cover every single detail so the dev team member has no ownership or need to think about what should be completed. By having this ownership the team will be able to recognize if it is ready for the customer or not. This will improve the quality of the product and it reduces the overhead of over-documenting every little detail. This doesn’t mean don’t document, you still need to know what the ask is and everyone on the team should be clear on what that is before starting the feature but you don’t need a 20-page document detailed that takes months to write and rewrite before you start. You release in small chunks with the needed details to do so.

How is communication done? There are ceremonies held by key team members to help keep everyone up to date on the daily goals, the overall product/project, and on process improvement.

1. Sprint Planning: A meeting at the beginning of the sprint where the team plans the work to be completed during the sprint. Doing sprint planning allows team members to gain clarity on the asked work from stakeholders or the product owner depending on your business structure. The dev team is given the opportunity to ask questions on each user story or feature. Once they understand the ask they can define all the tasks needed and design how they will deliver that original ask. Remember stakeholders describe what it is they want or need. The dev team describes how they will deliver it. Again this will drive ownership.
2. Daily Stand-up (Daily Scrum): A brief, daily meeting where team members share updates on their work, discuss any challenges and plan for the day. Knowing what everyone is working on or not working on helps with planning or shifting tasks to complete the overall ask on time. Try to keep this meeting short and to the point. What did you complete and what are you picking up today is a great goal to get to.
3. Sprint Review: A meeting at the end of the sprint where the team demonstrates the completed work to stakeholders and receives feedback. The team gets to show off their work to their product owner and or stakeholders and get approval before launching to production or handing it off to the customer. An absolute need is not to just finish development and send it to the customers without showing off your great work and getting approval. Catch issues before they become an issue. Stakeholders and product owners always will have a different view of things and can help make sure things are ready for their customers to drive the best experience for them.
4. Sprint Retrospective: A reflection meeting held after the sprint review to discuss what went well, what could be improved, and how to implement those improvements in the next sprint. The objective of always improving is a great goal to have by having a retrospective. It gives team members a voice to identify struggles in the process or identify what is really working. The same with development: quickly adjust what isn’t working and do something better. In doing this the teams will be able to optimize their delivery and be able to deliver more features in a shorter period with fewer defects or changes.

Agile Methodology may not be a perfect solution for your company and in most cases from my experience, I’ve seen most companies adopt more of a Wagile methodology which is a waterfall / agile approach. This is typically the first step in a company’s change management. A big reason for this is that waterfall is a more clean-cut view of time and budget and it is difficult to lose that control. Change is always difficult but you should always be open to it if you are interested in Agile please check out some of these studies. It is always good to do your research.

How Agile Projects Measure Up, and What This Means to You” by QSM Associates
Business Agility throughout the Enterprise,” by CA Technologies
“Agile Project Management – A Mandate for the 21st Century” (PMI, 2017)