A walkthrough in Agile
A comprehensive guide for agile methodology
A comprehensive guide for agile methodology
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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:
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.