Applying Agile Team Principles: Theory to Practice Insights

IT is filled with new exciting terminology, and sometimes it might even be overwhelming. Like “Couldn’t you do without naming every little thing with a fancy-schmancy word?” Yet, “agile” doesn’t fit into this category. The term Agile team principle coined in 2001 to replace outdated and wasteful traditional waterfall methodology. 

In short, the waterfall methodology required a lot of documentation before any coding would begin. Furthermore, the client would see the product at the end of the development cycle which might be in a year or two. The changes, especially late in the development cycle, were not welcomed. After all, they would require rewriting the documentation. Consequently, that would lead to a project exceeding time and budget estimates significantly.

Agile came to change things for the better. 

• Documentation is minimized, 
• delivery times are broken into small cycles, 
• client’s feedback is asked at every step of the way, 
• changes are welcomed, and more.

But it doesn’t happen as if by magic. The team must follow the formulated 12 principles by the founding fathers of Agile. The principles will be discussed here. But it won’t be like reading philosophical teachings. We’ll illustrate every bit with a practical example so you know what your agile team is doing. It also gives you a better understanding of when you can jump in with new insights or propose changes to your product. 

1. Early and continuous delivery – Customer Satisfaction

The principle in the manifesto of Agile methodology is formulated as follows:

Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software

Agile Manifesto

This principle resonates with the essence of MVP app development. An agile team principle is to strive to release the basic product as soon as possible. Then, the team would continually release more features. 

How does it ensure customer satisfaction? First off, let’s clarify. The customer is the software owner, the person who hired the agile team. Satisfaction in this case is Return on Investment – ROI. The sooner the product is operational, the faster the client can see it generating revenues. Moreover, an early release gives a head start in getting feedback from the early adopters. It also gives a ground for product improvements. This, in turn, reflects on the revenues. 

In contrast, the Waterfall Methodology would offer the release of the completed product at the end of the development cycle. So, the product would get to the market much later. A year or even more later. And time is money. In this case, it is also time lost without users’ feedback. Plus, it is very likely that some features will end up being redundant, that users will simply be ignoring. 

Yet, it should be set straight: the Agile methodology also has some documentation but to a much lesser extent than the Waterfall. For example, every delivery is made against the acceptance criteria developed at the start. You can read more about it in the article about acceptance criteria examples. 

Case in point: e-commerce app

Let’s compare developing an e-commerce app under Agile VS waterfall methodology. In Agile, you will start off with the following functionality:

– catalog,

– shopping cart, and 

– plugged-in third-party payment service. 

This is a product operational enough to start receiving early feedback. This basic version with all the preceding research, ideation, and mock-ups may take around 2-3 months. Then, as soon as new features are completed and tested, they will be added continually. 6 more months later, you might well have a fully functioning app with tested and smoothed-out UI/UX. 

Under Waterfall, your product would be released at least in a year. And it would be the first release. Bugs, fixes, and updates would be required. It might be so that the first revenues would be received even three more months later.  

2: Welcome the Change Regardless of the Project Stage – Changing Requirements

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Agile Manifesto

Here, under the Waterfall Methodology, changes late in the project would be met with resistance. After all, this methodology requires careful requirements gathering and thorough documentation of everything. So the change would mean corrections to the carefully laid out plan. It was organized this way because it was believed that the team could foresee and forecast all the requirements upfront. Plus, it was believed that the competitive environment would not significantly change after the end of the development cycle which might last a year or two.

In today’s dynamic environment, requirements evolve. It is either due to changes in the market, competition, or simply a change based on the received feedback. It is safe to say that any project cannot survive if it is not responding to the evolving requirements. This requires constant updates and tweaks. Competitive advantage is rooted in the ability to change. This is why Agile team principles prioritize the development process that can handle change at any point of the development cycle. 

Case in point: a mobile fitness app

Imagine a scenario: a fitness center decided to launch its mobile app. The initial requirements from the customer are:

• On-demand workouts,
• Goal setting,
• Calorie counter.

Of course, at the research stage, any professional development team would suggest adding a social sharing function. It makes it more engaging and contributes to marketing.

Now, in this scenario, somewhere close to the project closing, the customer decides to add a workout streaming feature. For example, the early release brought the feedback that a solid portion of early adopters would like to have online workouts one-on-one. 

The agile team principle is to welcome the change. Under the Agile team principle, it might be implemented already in the next sprint. However, under the Waterfall methodology, this feedback would not have been received, first and foremost. Secondly, even if the fitness center decided to make this change, it would cost them. It would require the revision of the initial documentation to include new functionality. Clearly, the Agile is much more efficient in this case. It would also be more in line with users’ preferences. This will bring more revenues and, consequently, reflect on the customer’s balance sheets.

Principle 3: Delivery of the Value Happening Often – Frequent Delivery

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Agile Manifesto

Under Waterfall methodology, the development process is seen as one indivisible whole. The Agile team principle breaks down the project into smaller parts each of which represents a functioning and tested working software. So, instead of one single delivery, the customer gets a delivery every 2 weeks or a month depending on the project. It allows the customer to see the working bit and give their feedback. It gives a customer an opportunity to make sure everything goes in alignment with the expectations and vision. 

Waterfall methodology in comparison feels a bit like a black box – you have an idea what it should look like but you will see it only when it is ready. Sometimes, it is exactly like you wanted, sometimes it is not. In the Agile team principle, you see the product at the end of every meaningful step. A meaningful step means when the functionality meets the acceptance criteria mentioned in principle 1.

Case in point: a project management app

The waterfall development team will go through the following stages:

• Planning,
• Design,
• Development,
• Testing.

All in all, it may take several months or even a couple of years. Only at the end of this development cycle, the customer would be able to see a working product. Naturally, some changes would be requested. But at this stage, it would be difficult for a team to accommodate. The meeting where the product is presented will look like a battle justifying the way it is made and combating any change.

In Agile development, after the first two-week sprint, the team will deliver a working prototype, for example. It might be a low-fidelity basic prototype. The customer often will have the opportunity to click it, take it to their team, and suggest improvements. And then, at the end of the next sprint, the customer will get a prototype/product with more and more features.

The Agile team principle clearly creates the opportunity for the project’s stakeholders to interact with the product and improve on it along the way. It is a much more collaborative and creative process that allows for coming up with unique software.

Principle 4: Daily Collaboration of Business and Development – Regular Communication

Business people and developers must work together daily throughout the project.

Agile Manifesto

This principle was created to lay the foundation of open communication and a shared sense of ownership. In addition, if communication happens daily, any issues can be solved promptly and decisions can be made faster. Before, under the Waterfall methodology, the project would go through the stages one by one. It meant that business analyst would do their part, present to stakeholders, and then it is done. Then developers take over. However, the communication between the business function and the development process was very limited under rigid Waterfall methodology. 

Case in point: travel planning app

Under the Waterfall methodology, the business aspect of the project would be handled at requirement gathering. The next time the business stakeholders might get involved would be at the presentation of the finished product. Sure, the initial business meetings would be thorough and detailed. Yet, the travel planning app might be fully finished in 6 to 8 months. After that time, market conditions might change, new ideas might come up, and more. 

In Agile methodology, business stakeholders might take part in daily stand-up meetings. If a new trend in traveling has been spotted, it would be easy to discuss it the next day in the stand-up meeting. Or if any other queries might come up that often need business input to be solved. 

For example, if the competitors introduced an augmented reality (AR) feature. In this case, a business might want to discuss with developers how much time it will take to introduce the same thing in their project. Along with that, they might discuss how it will impact business metrics, KPIs, and other crucial elements. Or they might think of a temporary ‘placeholder’ feature until more resources are available for the implementation of a full-scale AR feature. Business people would get direct input from the developers to come up collectively with the best business solution. 

As an added bonus, with such daily meetings of business people and developers, it is much more convenient to discuss additional monetization strategies. It can be in-app purchases or new partnerships. Overall, regular communication allows them to discuss new ideas and trends. If deemed successful, implement them in the next sprint. You will not need to wait an eternity. 

Principle 5: Reduce micromanagement in favor of empowering employees – Motivated Individuals

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile Manifesto

A lot of businesses have recognized the value of trusting their employees and empowering them to make decisions and work autonomously. Unfortunately, there is now a wave of ‘getting back to the office’, installing tracking apps on employees’ laptops, and mandatory calendar sharing with the company – all for the purpose of micromanagement. 

It is also time to say that these Agile team principles should be perceived as recommendations. And some principles can be implemented more thoroughly than others. After all, these principles were developed when employees worked from the office. They didn’t factor in the huge level of autonomy that workers get now with working from home. 

Anyways, this Agile team principle invites creating an environment where the team members can feel free to:

– offer ideas, 

– be open to collaboration, 

– trust each other. 

When individuals feel that their management trusts them, they feel a sense of ownership. Somehow, it translates into more motivation to work on the project’s goals. 

Case in point: traveling app with AR feature

But why might it be beneficial to empower the individual team member? First of all, in Agile there is much more emphasis on delivering frequent working and functional parts of software. If you need to make a working product in a year, it is not so important which functionality you do first. But when there is a need to deliver meaningful functionality every week or two, the order of things becomes vital. And it would be redundant and wasteful to micromanage every team member that closely. 

Furthermore, some features like AR are quite technologically challenging and new. In the earlier work environments, developers were not open enough to discuss challenging bits. They would put together something and then await feedback from the tech lead. However, if it is a trusting open environment, the developer might raise an issue among the agile team members. It would create an opportunity to ask for suggestions and even discuss a couple of ways to achieve better performance. Somebody might pitch in a library or API they might have come across, and your project would benefit tremendously. A lot of the time developers sit on interesting discoveries without sharing because they simply do not feel it is necessary, encouraged, appreciated, or welcomed. In Waterfall, they just work to tick off the assigned features on their task list. In Agile, they work together to deliver valuable efficient software. 

Principle 6: Efficient communication – Face-to-Face Meetings

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Agile Manifesto

Again, this principle was clearly designed in the days of office work. Since that, sourcing talent across the globe and working in distributed teams really took off. So, this principle can be implemented partially. Or it can be adapted depending on the way the development agency is organized.

So the global idea is that face-to-face meetings should be encouraged instead of written communication. Now, with all this Covid-induced shift to online, communication tools really took a leap forward. And the reverse trend is overtaking now – “that meeting could have been an email”. But this trend is somewhat harmful and is rooted in the indifference and even kind of apathy of working remotely. Digital meeting is often preferred out of time and convenience so that each person doesn’t spend any extra moment on communication. Even though it might be convenient, it is killing the creative spark and does not allow for sharing the atmosphere of enthusiasm and creativity. There are companies that churn out templated apps. For them, there is no need for creativity or discussions. Everything could be an email in this kind of work. 

But every bit of custom software is like a work of art. The product must be interesting, unique, and have an edge over the competitors. In offline face-to-face meetings, the atmosphere would be much more conducive to discussions.  This is why so many businesses strive to at least get people back to the office for a couple of hours a day or days per week. Remote work does lack in the aspect of enthusiastic engaging communication. 

Principle 7: It’s not about the hours – it’s about working features – Measure Outputs

Working software is the primary measure of progress.

Agile Manifesto

Under the Waterfall methodology, the reports about the progress would include things like:

– adhering to scheduled milestones, 

– checking each milestone against the documentation, 

– following Ghantt charts and visualizing the progress on the timeline project trajectory,

– hours of development time,

– tests passed and bug fixes, etc.

After all these reports, you see the working project at the end of the development cycle which can last for years. Under the Agile team principles, the customer doesn’t need to bother with these reports. The customer can see and click through the working app at short regular intervals. 

Principle 8: Maintain a consistent balanced work pace – Sustainable Development Process

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Agile Manifesto

This principle was again developed out of problems created by the Waterfall methodology. Before, the development cycles were really long. It often led to teams not working hard enough at the start and middle of the cycle. Then, they would be pressed hard to complete the features when approaching the end of the cycle. It led to mistakes, burnout, and overburdening. 

In Agile, there are no long development cycles. Instead, the agile team principle is to work in sprints of 1 or 2 weeks. Even if the team is pressed to complete some meaningful part of the work, it is only for a short time and can be balanced out during the next sprint. It helps to maintain sustainable development at a constant pace for the entirety of the project.

Case in point: social media mobile app

Under Waterfall methodology, the development cycle for this kind of app might amount to a couple of years. The approach towards the end is often called the ‘crunch time’. It is when the team members finish up coding, do the testing, bug fixes, solve merge conflicts, and such. This is very intense in terms of workload, and this period would last for months without any breaks. Burnout would be a common issue, and the results of the burned-out team would reflect on the customer’s financial results. 

The agile team principle is delivering working features at shorter time spans. It might be 2 weeks, sometimes a month. Sure, nobody is protected from unexpected problems or bugs even in Agile methodology. And it might lead to overworking. But then, during the next sprint, the team would plan to have a lighter load to compensate for overtime. In addition, the team gets retrospectives which allows them to reflect on the sprint. They improve already in the next sprint. Not like looking retrospectively at a couple of years of development under the Waterfall methodology.

Principle 9: Striving for skillful technical implementation and well-crafted design  – Technical Excellence & Good Design

Continuous attention to technical excellence and good design enhances agility.

Agile Manifesto

This agile team principle became possible due to the previous ones. The Agile team principles encourage refactoring, the use of design patterns, and test-driven development (TDD). These techniques are applied to make the code easily scalable, readable, testable, and maintainable. In turn, it allows implementing changes as the need for them arises. In Waterfall methodology, there is no prohibition in applying proven design patterns, TDD, or refactoring. It is just that the rigidity of the Waterfall methodology doesn’t give much space. At the outset, the features are heavily documented, strict deadlines are set, and the testing is scheduled as the last stage of the development cycle. Deviations from this setup would be difficult to organize.

Case in point: display feature changes for budgeting app

Imagine an app that is primarily designed for the purpose of tracking personal finances. Users input their spending and set savings goals or other limit values. Then they can make reports by categories, goals, or different time frames. The Waterfall methodology implies that everything is documented at the start, and then implemented following strict deadlines. However, imagine that somebody on the customer’s side gets an idea to not only display these reports on screen but make PDFs from this data or even print with some Bluetooth printer. And also maybe do visualization maps for the goals with some icons and images but based on the user data. 

In Waterfall methodology, that would require making changes to documentation and previously designed classes. But in Agile methodology, in one of the sprints, the agile team principle is to refactor the codebase – to break down one class into several for singular roles. Then, when the proposed change arrives, the team can extend the existing classes rather than alter the already working tested code. Therefore, the team only adds the new bits of code that are in need of testing. And there is no need to re-test the entire system as the previously done working functionality remained untouched. 

And a little bit of a history of development: it is during the reign of the Waterfall methodology that the ‘god-object’ anti-pattern emerged. That means one big chunk of code which essentially communicates with all other functional parts of the program and performs too many functions. And if you change this code – you need to go through thousands of lines of code to make sure new edits don’t break what’s already been working. This is why when such change is looming – it would require so much more work to be done and redone. It is even not to mention, that such a file is often so large that it would be impossible for a developer to read it and understand it. Things like what the code is doing, where the change must occur, and what it is linked with. And this is why the documentation is so important for the Waterfall methodology. Imagine a 2-year-long project and a new developer joining: this person will need weeks to just try to understand the codebase before contributing anything if there is no documentation.

Principle 10: Avoid complication and reduce work – Simplicity

Simplicity–the art of maximizing the amount of work not done–is essential.

Agile Manifesto

IT world is where everything is possible, so to speak. If one wonders whether it is possible to implement something – it usually is. The question is: do you really need it? You can make every page of your app open with an incredible animation, but would it contribute to UX and site performance? You can incorporate a complex suggestion system, but would it pay off eventually? 

Waterfall Methodology is somewhat bad at this. At the outset of the project, the team comes up with the best and fullest implementation of the initial requirements. And then the team follows a straightforward unwavering path. 

In Agile methodology, some features or designs might be discarded along the development process, and that will be praised. The agile team principle is to have a backlog of features with different priorities, but they can be reassessed. Agile teams especially prioritize redesign if this simplifies things. Simplified architecture often leads to lower load times. This leads to better search engine rankings and higher user satisfaction rates. Simplicity creates positive outcomes across a cascade of other metrics and KPIs. 

Case in Point: project management app

The features of the app include task creation, assigning them, and tracking their progress. Also, this app might have functionalities such as commenting on tasks, file sharing, creating reports, and notifications. In Waterfall methodology, those tasks will be developed according to schedule without prioritization as the goal is to develop the final product with specified features. In Agile methodology, the features will be prioritized and MVP will be released. Then, upon the feedback, some features might well be discarded, for example, a file-sharing feature. After all, the majority of companies use some kind of cloud storage solution and share files via links.

Moreover, it should be mentioned that the Agile methodology prioritizes not solely based on what the client wants. The Agile methodology works with user stories and prioritizes features based on this. 

Principle 11: Top-down VS Collaboration and Shared Expertise – Self-sufficient teams

The best architectures, requirements, and designs emerge from self-organizing teams.

Agile Manifesto

When the entire architecture, requirements, and design were determined by one person on the project, and then tasks were assigned based on that, it was the Waterfall approach. However, when every team member has decision-making power and collaborates, there is an opportunity to leverage collective expertise. 

This principle really rests on the ability of the development agency owner, project managers, and tech leads to lead. It must be said that it is not always easy to implement. Any team has a diversity of personalities and cultural backgrounds these days with online work opportunities. Some people would not respect the ‘boss’ if they were not told what to do. Some developers would not contribute their opinions and expertise unless asked directly. And then this might feel confronting. So this principle really rests on the leadership qualities to create an environment for collaboration and sharing. However, when done correctly, this Agile team principle leads to amazing ideas flying around the project going through step-by-step iterations and refinement. In addition, when people contribute parts of themselves, they really start to care. They manage to better connect with the user feedback, and go the extra mile for the project goals.  

Principle 12: Reflection is a key – Continuous Improvement

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Manifesto

Any team can work better and be more efficient upon reflection. In Waterfall, this happens at the end of the development cycle which might last a couple of years. In Agile, it is scheduled either at the end of each sprint or a meaningful iteration. So, in both methodologies, the teams improve. Yet, in Waterfall, they improve based on the previous project and might do better in the next one. In Agile, the team improves as the project progresses. 

In addition, these improvement opportunities are really different under those methodologies. In Agile,  these retrospectives are often very particular and result in actionable recommendations. In Waterfall, they are more generalistic and the knowledge can be less transferable as the next project might be completely different. After all, team members are not required to make decisions as they follow a predetermined development plan.

Case in point: project management app with real-time collaboration feature

In Agile, however, adding this feature would be an exciting and welcome change. Imagine, that team implemented the initial version of this feature. Upon the end of the sprint, the agile team principle is to gather for a retrospective. They might discover an opportunity to decrease latency during collaborative work on a document. They might get an idea to select some non-essential features and re-do them in an asynchronous manner offloading the app’s syncronous task stack. This can certainly improve the user experience and the app’s responsiveness.

Frequently Asked Questions (FAQ):

Final Thoughts

Grab the visual of all 12 principles of the Agile Methodology. In addition, remember that those principles can be implemented to various degrees. The next image is a cheat sheet for the most established Agile methodologies. And they vary mainly on how closely a particular principle is embedded into the working practices at a particular development agency. After all, the Agile methodology is done for flexibility and adaptability. It would be strange if the methodology itself was set in stone.