A walkthrough in Agile

In this blog post, we are going to have a walkthrough in Agile, from how it all started, the definition and the principles of this methodology.

How did it all start?

Before 2001, Waterfall Model appeared in the Software Development Life Cycle approach for software development. As of today, this is still the most popular classic model. 

It was created to be used in the system development life cycle to create a system with a Linear-Sequential Life Cycle approach. It is called a waterfall because the model develops systematically in a top-down approach. 

The Waterfall Model is divided into different phases that are interconnected, the output of one stage is used as the input of the next step. It is essential that every phase has to be completed before the next phase starts and there is no overlapping of the phases.

As it’s laid out, the waterfall model has its downsides, including taking a high risk in delivering a product at the end of the development phase and low adaptability to market demands. The need to adapt to the ever-changing demands of the products and market was at the core and foundation of a methodology that will help the industry adapt at a more rapid pace. 

What is Agile?

Agile is a new concept that offers the ability to create and respond to change. It is a way of overcoming the effects of turbulence, transforming uncertainty into success. 

Agile Methodologists are concerned with getting good products to market by working in an environment that values more than talking about the importance of people—they actually operate as if "people" were important.

What is the Agile Model in software development?

Agile is an iterative approach to project management and software development that helps teams deliver value faster to their customers and with fewer headaches. The term refers to a set of frameworks and practices based on the values expressed in:

• Manifesto for Agile Software Development.
• 12 Principles behind Agile Manifesto. 

In the following sections, we will approach the two main areas of the manifesto and the principles that are a fundamental part of what Agile represents.

Agile Manifesto

The Agile Manifesto is a collection of values based on trust and respect for each other, as well as organizational models focused on people—collaboration between team members within a larger group or organization is encouraged. We will analyze further the main set of values affirmed by this manifesto.

A. Individuals and interactions over Processes and tool

• No matter how well-researched your process or high-tech the tools you use, it’s how effectively you work together as a team that determines success.
• The people on your team and their ability to communicate are more important than the processes or tools you use.
• Formalized processes and tools can still bring value, but they’re not the most important part of a project. If your team doesn't understand how to communicate with each other effectively, any process or tool you create will be worthless—but give an intelligent group of people both a challenging task and no way to manage it, and chances are good that someone will find some way.

B. Working software over comprehensive documentation

• In traditional product development processes, companies would often spend a great deal of time and money on documentation before any code was written.
• It's crucial to get software in the hands of customers as early as possible so that they can provide real-life feedback on how it works.
• Although it's important to ship working software and not let documentation get in the way, don't fall into the trap of thinking that there is anything wrong with writing good documentation.

C. Customer collaboration over contract negotiation

• Traditionally, product-centric processes have allowed contracts to dictate what is delivered in the end—but this leaves a lot of room for mismatched expectations.
• Many of the formalized processes that have come out of agile encourage integrating a continuous customer feedback loop into development cycles.
• Customers are involved in the development process from day one, and they help make decisions throughout.

D. Responding to change over following a plan

• Agile encourages a constant re-evaluation of project plans based on feedback from the team and stakeholders.
• The product roadmap is not a set-in-stone plan but rather an ever-evolving strategy.
• Agile methodology allows a product team to make strategic adjustments—it does not get stuck with an outdated plan simply because it has committed to seeing it through.

12 Agile Principles 

Moving forward we will take a look at the 12 Agile Principles that fundamentally guide and shape this methodology. Each of these principles represents an idea that will ultimately guide the implementation of successful digital products by helping organizations become more flexible, adaptive, and responsive to the ever-changing market demand. 

1. The highest priority is to satisfy the customer through early and continuous delivery of valuable software.

What this principle tells you is that scrum teams use MVP (minimum viable products) and rapid implementation, with frequent releases and continuous feedback cycles to test and validate ideas. For the agile methodology “shipped” is not a term equal to “done”. There is no finished product released, just a starting point that will be followed by iterations with incremental product improvements that are based on actual customer and market feedback. This ensures that the product is actually based on what’s important - the customer's needs. 

This way of delivery is actually what helps companies be more successful, test out new products, or features and minimize the failure risk. 

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

The agile process harnesses change for the customer’s competitive advantage and with that comes to a very important principle that focuses on openness. 

It’s important to acknowledge that in the classical set a requirement received in the latest stages of development can be difficult to add because of the costs and the extended-release date of the project. On the other hand, scrum teams are guided by high-level strategic goals, and delivering a better product for the customer falls into that category. This is why if a new feature is identified on the market and is what the customer will regard as an improvement, then the team will adjust the plan accordingly. With Agile's iterative process, teams shouldn't have a problem responding to any changes in a timely fashion.

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

Delivering in a shorter timescale is one of the most important improvements with Agile Methodology. The development cycles, also known as “sprints” or “iterations”, break down the product into smaller initiatives that can be completed in a specific timeframe, often from 2-4 weeks. This ensures that each iteration the customer receives small iterations that are actually more valuable because of the short release period and timing.

Another popular alternative for agile iterations is continuous deployment, a method for delivering software not by using time-boxes but by simply deciding what to do. 

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

The actual value is “business people and developers must work together daily throughout the project”, but from our perspective, it implies that agile needs to set a strong communication process between all the parties involved in the development process, but also of the product owners and business strategists. Closing the gap between technical and business is essential in order to deliver the best results for the customer and also stay focused on the main goals of the project. Daily update meetings or stand-ups are one of the techniques that agile teams use in order to establish a good environment for communication and sharing information.

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

Agile is all about reducing micromanagement and empowering teams to deliver excellence every day. This of course is achieved by setting a trusting environment that motivates and supports people. Having a close-knitted team that communicates and understands the bigger picture and the product roadmap is key to the success of delivery and launch on the market. 

That being laid out it’s important to know that each part has its role. The product team will share with development the “what” and “why” of the project and it’s up to the delivery team to decide on the “how” they will do it. And, if the proper communication setup is in place, the product team will be always available to provide support and clarifications during the sprint, thus avoiding micromanagement.

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

A direct communication method is the best way of conveying information. In agile there are many ways one can take advantage of that via daily standup meetings, sprint planning meetings, demos, pair programming, collaborative backlog grooming sessions, or informal one-on-one meetings. In the era of accessibility with Zoom, Teams, Slack, or many other platforms, achieving this sort of connectivity has never been easier. 

7. Working software is the primary measure of progress. 

This principle is quite straightforward, when designing and releasing an MVP you should consider not how much time you put into this but more importantly if the customer will use it. In addition to this, you have to be open to the fail-first mentality. Testing ideas rapidly is the best way to validate a product. After the market has validated your product you start releasing software as often as possible. Small incremental improvements are much more effective than a perfect product delivered too late. In other words, get your product out there, and don’t wait for your idea to lose its competitive advantage.

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

Sustainable development is one of the key factors in Agile. Each sprint the team should carefully consider the amount of work they are able to deliver and set estimations with the right dose of optimism but also precaution. In the phase of planning the team agrees on what tasks will be completed in the sprint and once that has begun no additional task should be included, except maybe in rare cases. Product managers are often in the role of gatekeepers and try to keep at bay the additional work on the ongoing sprint. In addition to this, the product people should be an integral part of the feedback loop and encourage it and free communications across the cross-functional team. 

9. Continuous attention to technical excellence and good design enhances agility. 

Technical excellence implies that the team should always keep in mind that what they deliver is outstanding products. The addition of new features on the backlog should bring together the developers and product team and form an understanding if the technical debt is acceptable. On a regular basis, product development will allocate resources to refactoring efforts. Refactoring should be an ongoing process in an agile environment.

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

Product managers need to have a very focused strategy that is integrated with product strategy and organizational goals. Prioritizing techniques to prioritize initiatives is one of the key agile principles of product development. The short sprints that agile is characterized by present many opportunities for rapid testing and experimentation which can help reduce uncertainty around whether initiatives will truly have the predicted impact. Using experiments to validate ideas before building them up to specifications is a great way to weed out ad ideas and identify good ones. In the end, it’s important to keep in mind that simplification of the work done is a very important and cost-effective way to deliver quality products. 

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

In Agile self-organizing teams are autonomous groups within the organization, they take control and responsibility over their respective projects and have ownership in those areas. Different organizations practice this principle differently. Spotify, for example, uses “product squads” to practice this. 

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

Experimentation and testing are not limited to the product only. Agile teams are encouraged to experiment with their processes. You may think you’re already doing something well only to test a revised version of the process and discover an even more effective method. Experimenting with your process and team is just as important as experimenting with the software you’re building.

Regular retrospectives are opportunities for the team to discuss what went well, and where the process can be tweaked to improve things in the feature. This is an excellent opportunity for both product managers and product owners to learn if there is effective communication with developers and if they are offering support before, during, and after each sprint. Another consideration to make regarding the agile principle is that in order to do it effectively you need to create a culture of trust and transparency that encourages openness and frequent sharing of feedback.

What is Estimation in Agile?

Someone once said, “It’s hard to make predictions, especially about the future.” But estimating work that needs to be done, is all about the future. There are two most popular approaches that scrum teams can go with: story points and man hours. Let’s discuss them further.

What are Story Points?

Story Points are a comparative unit of measurement. Agile teams use them to express estimations of the overall effort that is needed to implement the development user stories. So, when you estimate in story points, it really means you estimate effort and assign a point value to each backlog item. A story point is a relative value because it exists only in comparison and relation to another value. Also as important as being a relative value, it is also required the efficiency of the team that makes estimations. The experience, skill level, or familiarity with the current task can set apart an estimate from one team member to another. It is important to have some tasks that can be examples. A simple discussion between team members with examples of why they estimated that way can clear the big picture of the item and then it will be easier to settle with a specific story point. 

That is why many Agile relative estimation techniques take different scales (sizings) to express story point values:

• Fibonacci sequence where each number is the sum of the previous two in the series (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, …).
• Linear sequence where you get from one term to the next by always adding or subtracting the same amount (e.g., 1, 2, 3, 4, 5…; or 3, 6, 9, 12, 15, 18, …).

How can estimations be tackled for the first time?

It is essential that the team identifies a baseline story. It does not necessarily have to be the smallest one, but something that resonates with everyone within the team. Once the baseline story is in place, the team can begin adding story points estimation by comparing them against the baseline. 

What is time estimation in agile (Man hours)?

It is incredibly difficult to precisely estimate how long it would take to complete a given user story. The team could get hour estimations right for the easy or repeatable stories. But as the complexity and effort of the story grow, time estimation becomes harder. On the other hand, it is much easier to compare two stories and say, “The first story is easier to implement than the second one because it has very straightforward requirements. The second story is more complex and risky.”

Also, time estimations carry emotional attachment. Let’s say you estimated a task to take 5 hours and you ended up doing it for 10 hours. How would you feel about it? And what would you tell your manager?

The bottom line is that we as humans are pretty bad at absolute estimations. It is easier for us to say a task will take more or less effort compared to another task, especially when we talk about the complexity and/or uncertainty involved.

What are the benefits of Agile Estimation?

Estimates can help break down, plan and prioritize work and ultimately improve the efficiency of managing Agile projects. Proper work sizing can be beneficial to project management in various ways.

• Improved coordination - arriving at a mutual understanding about the actual size of the work requires everyone’s input. As such, estimation practices improve the team’s communication and coordination skills.
• Decision-making enhancements - teams can improve the ability to prioritize work in the backlog depending on the assigned estimates and improve the planning capabilities.
• Better risk management - proper work sizing lays the foundations for better risk management and in terms improves the chances of in-time delivery with the required quality and within budget. 

What are the downsides of Agile Estimation?

As with any topic, there are both benefits and downsides to each approach. In the case of agile estimation here are a few aspects each team should consider and be aware of.

• Estimates do not account for uncertainties - regardless of the type or scale of estimation, estimates are criticized for their inability to predict future risks. Because knowledge work is more qualitative in nature, the complexity of user stories can vary greatly from team member to team member.
• Estimates cannot be final - one of the biggest problems with estimates is that once work has been weighed, it's considered final. However, addressing emerging conditions should always be an option.
• Wrong purpose for estimations - when teams treat the agreed-upon estimates as commitments for assigning specific timelines or judging team members, they can lose sight of their primary goal—thinking through the how and why in ways that will make iterations successful.

Agile Development Life Cycle

There are a variety of Agile software methodologies practiced by organizations these days like Scrum, Kanban, DAD (Disciplined Agile Delivery), Extreme Programming, Lean Software Development, etc. 

All these methods emphasize teamwork, frequent deliveries of working software, close customer collaboration, and the ability to respond to change. Each methodology may have slight variations in defining the phases of software development, but the end goal of each method is to adapt to change and deliver working software rapidly. In addition, each team’s process flow may vary depending on the project situation as well. 

The Agile Lifecycle is a 5 step process and we will go through each of them: 

1. Define Requirements - requirements for this particular iteration are defined based on the customer and stakeholder's views. The team then analyzes and understands the defined requirements.
2. Design/Develop - having the requirements set in place, the team members start the development of the user story. This process takes the most amount of work and time.
3. Test - this phase includes all the testing methods that were defined in the test plan (unit testing, system testing, integration testing, or acceptance testing). This step is crucial before delivering the software to production.
4. Release/Delivery - after all the quality assurance is done, the working product of the corresponding iteration is released into production.
5. Feedback/Review - the release of the product will be done in its final phase, after which a review is required from the customer or stakeholders, regarding the practicality, usability, or any improvements of the software.

This concludes our walkthrough Agile. We took a look at what makes Agile different from other software development methodologies, also known as Waterfall. We explored the rules of this methodology and had an overview of the principles behind it so that you can understand why Agile is so popular among companies today. Here at OceanoBe we also use Agile and we can tell you that this had a real impact on the output and success of our work and partnerships. We hope this will give you the inspiration to do the same. 

#TimetobeUnstoppable