The basics of Agile methodology
Agile is a term that has gained considerable traction in recent years. Agile software development, Agile project management, Agile marketing – Agile “you name it” – have all gained prominence. Nearly everyone these days does something Agile, and they do it for a reason – because it works for many modern projects.
The core of any discussion on Agile is the Agile Manifesto, popularized many years ago and still very much up-to-date in the third decade of the century.
Agile Product Development delivers (predominantly) digital products that emphasize flexibility, communication, and adaptability. It’s an excellent choice when there are many unknowns, and the project relies on a set of hypotheses. Unsurprisingly, that’s the reality of the vast majority of products in the early development stages.
The Agile methodology allows teams to deliver quick results, adapt to ever-changing circumstances, and save valuable resources.
Project delivery with short iterations
Rather than planning and executing the entire project, the first stage of the product lifecycle is done differently. It is broken down into a series of much shorter phases, known as sprints, where progress is examined more regularly.
Having the timeboxed iterations helps to concentrate on what’s most important. Some requirements may not get addressed because of the time limits. However, what gets developed is the most essential of the required features.
Timeboxing minimizes the effort and resources required to achieve the expected goal. It also helps prevent “feature creep,” where features are constantly added to the products without accessing their relevance or need.
Phase by phase building, testing and reviewing
Contrary to the sequential nature of traditional product development, agile teams deliver nearly all the time. Towards the end of every sprint, deliverables are tested, assessed, and reviewed. Then, the adjusted plans are made for the following sprint.
This forces agile teams to efficiently use their time, effort, and resources to create working MVPs. This, in turn, helps to adjust the plan for every cycle that follows until the project is completed.
Feedback
Feedback is used to fix problems or refine improvements before moving on to the next iteration of development work. It’s also an essential part of product discovery – it helps the team understand if the idea makes sense and if the team is moving in the right direction.
This works well with the incremental nature of agile. After each new iteration is shipped, agile teams rush to gather feedback from users, beta testers, and virtually whoever agrees to give the product a try. In this, they’re trying to figure out:
- which features solve business and customer problems in a satisfactory manner
- which features require further attention
- which desired features have been overlooked
- which features are critical in the customers’ purchasing decision
- whether the design helps users achieve their goals or, quite contrary, detracts them from it
All the feedback they can acquire this way, they can then process, validate against their hypotheses, and build future sprints based on all the information currently at their disposal.
This approach gives the product teams a much better chance of finding the right match. It lets them see their work results first-hand, keeping them engaged and connected to the outside world.
Traditional vs. Agile product development – pitfalls and benefits
The traditional approach to product development (waterfall methodology) relies on different principles. It emphasizes careful planning, structure, and clear responsibilities. Waterfall is a sequential product development model – meaning that teams move from one stage of the process only after they’ve completed the previous one.
To understand the difference between the two, let’s look at the example. Suppose you came up with a revolutionary idea for an app that would match pets living in a nearby shelter with people willing to adopt them. Let’s call it PetMatch.
PetMatch uses advanced ML and AI techniques to analyze your social profiles, interests, past behaviors and does all sorts of creepy stuff to ensure a perfect match.
If you were a waterfall person, you would write down your hypotheses, do deep research on similar apps, measure the demand for that kind of solution and assemble a team. Together, you would draw the first designs of the app and build a product roadmap, detailing everything that needs to be done to complete the app. This process can be streamlined significantly with the use of a white label app builder, which offers customizable features, enabling a more efficient and cost-effective development journey.
The team would then split responsibilities and tackle the epics, one by one, until all required features are taken care of. Once you’re finished, you would then test the app, fixing any bugs and eventually releasing the app to the first users.
As a part of an agile team, you would also start similarly. You would write down hypotheses, research the topic, and perhaps visit a few shelters in the area. You would run the idea by as many people as you could encounter, diligently noting their inputs and adjusting your assumptions accordingly.
You would then build a very basic version of your app and head back to the very same people to gather their feedback. You would repeat it with each new iteration, heavily iterating, possibly even pivoting at some point, and testing each new version on the spot. Eventually, you would release the app’s final version and rush back to the users to gather their feedback.
When waterfall works well
Sequential methodologies such as waterfall work well when:
- Systems can be described in detail beforehand.
- Requirements are known and most likely won’t change throughout the project.
- It’s safe to plan the roadmap and then execute it.
This is the case in many traditional industries – for example, enormous energy and construction infrastructure projects. These activities generally must occur in sequence and with a model that’s well-tried and tested. Although small internal tests and early feedback obtained this way are possible, these organizations tend to be too bureaucratic to allow changes on the fly. As a result, the iterative approach and feedback gained this way are not the focus.
Same way, a waterfall works excellent when your plan is based on facts rather than assumptions – in other words, when you’re about to build something that has been made before, in the same or a similar way. This can be launching a new restaurant, designing a new mobile phone, developing a system that already exists but will now be targeted at a different niche. In all these cases, waterfall could be a faster way of completing a project.
The problem with waterfall
However, more often than not, in our fast-changing world, precisely defining a project at its start is difficult at best. A lot of our ideas are based on assumptions that eventually need to be validated. And it’s far easier to validate them early in the product development process.
During the final product testing phases, a considerable amount of time, effort, and resources have already been spent. So the potential for waste is enormous. Fundamental mistakes noticed at the last minute are likely to be costly and have serious consequences.
This creates long delays in launching new products in the market. The result is disappointed customers and losing out to your competitors. With the waterfall approach, the risk often outweighs the reward.
Validating our assumptions fast mitigates the risks of building the wrong product. As founders or product people, we assume that people would use different features or that a product would immediately gain traction. The reality is that without any viable evidence of the market demand, our assumptions will remain what they are – just assumptions.
Agile Product Development
Agile product development alleviates issues by identifying them at various project stages – not just at the end.
Ideally, each phase or iteration will produce a part of the envisaged new product that can be tested before moving on to the project’s next step. Sprints, commonly referred to in Scrum terminology, can vary in length but average at around two weeks and no more than one month.
As the sprint comes to an end, ideally, new user data flows in, and an agile team can quickly adapt – focus on a more prospective feature, expand user testing to confirm or discard a particular assumption, etc. This gives them a distinct advantage over waterfall teams because they know about any issues firsthand and have the flexibility to react to them.
Continuing with our previous agile example – early in the product lifecycle, we realized something is wrong with PetMatch. Users sign up but don’t even complete their profiles. Advanced matching algorithms are there, and they work like a charm but don’t bring much value to a user. The design gets better with each new release, but the results don’t follow.
Had we been taking this the waterfall way, we would have been already sitting in the AppStore with a complete app but no users, wondering what went wrong.
Being agile, we’ve spotted what’s coming early in the cycle. We’ve since simplified the user questionnaire and cut the features no one would use, one by one. Since none of these brought the expected results, we’ve made a pivot and reshaped our initial assumptions. Eventually, we got rid of the whole matching thing and built a fantastic app for dog owners to meet and hang out together. And it became an instant hit.
Don’t get us wrong. Agile is not the magical solution for building the next unicorns, just like that. But it works so much better in such an unpredictable, dynamic environment than the typical waterfall approach.
Minimum viable product
Another common term associated with Agile is MVP (minimum viable product). MVP is the version of a product that requires the smallest amount of effort possible to create just enough features that can be tested with real users.
It might take one or several sprints to create an MVP, and it is an efficient way to test the technical merits of a new product and test the market. This is the best way to see whether there is enough customer interest to justify further product development.
Product development strategy components
The most crucial parts of the product development strategy should be followed through with an MVP, which will be implemented in miniature. The process should include the following stages:
- customer research
- competitor analysis
- business model review
- market/macro research
At each stage, we’re trying to gauge the interest in certain features of our product and understand their overall impression of the product to potential customers (and stakeholders – in some cases). This helps the project team shape the product and further improve or ditch features. It’s also beneficial for validating ideas and adjusting the strategy.
When the release candidate is finally prepared, you launch with far greater confidence. The earlier feedback gave you proof that the investment was worth it, and if you were agile enough, you invested resources just in the right features.
Agile cyclical iteration workflow applied to software development
Each agile cycle has the same or a similar workflow. The end of one always means the beginning of the following one, continuing until the product is developed.
A typical agile flow looks like this:
- Requirements – based on project objectives and customer/stakeholder feedback, define the iteration requirements or scope to be addressed.
- Development – design and develop software based on the defined requirements.
- Testing – product testing and quality assurance, the development of documentation, and knowledge sharing.
- Delivery – taking the working iteration into production or showing it to the early adopters.
- Feedback – obtaining detailed customer/stakeholder feedback – assessing whether the product met their expectations, solved their problems, and if it was clear how to use it.
As the feedback is gathered, it’s prioritized and used to plan the next iteration. And then it goes again, starting with requirements for the next sprint.
Agile product development teams
Since each iteration requires several activities to be performed, including (but not limited to) design, marketing, development, and testing, agile teams are cross-functional. Different specialists have the same goal, and they need to work with other teammates to achieve it.
This is different from a traditional process, where specialists hand over work to each other – e.g., the implementation team finishes their part of work and hands it over to the QA team. In Agile, the whole team is responsible for the delivery, and no hand-offs are assumed, which results in high productivity and engagement.
Whilst some members of the project team focus on specialist tasks that require expert knowledge and skills, others perform more of a general role. They devote more attention to project road-mapping, facilitating communication, or progress tracking.
Specialists are typically designers, developers, QAs, and customer satisfaction researchers, and the more general roles would be business analysts and project managers.
It’s important to note that the structure of teams can change throughout the process. There are no fixed roles, no “my tasks” and “someone else’s tasks.” The key is getting the job done, and the structure needs to be flexible enough to help achieve this goal.
Product teams can have different structures depending on the product domain, the development phase, and the agile framework used.
An efficient team should be able to:
- Define: set the goal of iteration and outline its scope
- Build: there should be specialists who can deliver the required product increment
- Test: make sure that the created increments meets the goal and have the correct scope
- Deploy/Analyze: be able to deliver and analyze the results
Agile teams are meant to be self-organized. The role of a manager is to remove the obstacles and provide the missing information rather than instruct individual team members on what they should do.
The common approaches to agile
There are various methods of running an agile team. Some are very different from each other, while others have small differences between them. It’s common to combine practices from several approaches and adapt them to the teams’ needs.
Feature Driven Development (FDD)
An iterative and incremental software development process, FDD is another Agile method for developing software.
It consists of five basic activities and is used to deliver “feature projects.”
- Develop an overall model
- Build a features list
- Plan by feature
- Design by feature
- Build by feature
FDD is used when you need to scale agile processes to larger teams.
Dynamic Systems Development Method
Another iterative, incremental approach, DSDM, is an agile software development methodology largely based on the Rapid Application Development (RAD) methodology.
Adaptive Software Development (ASD)
Pioneered by the work of Sam Bayer and Jim Highsmith on rapid application development, adaptive software development is a process that encapsulates the idea that continuous adaptation of a process to the task at hand is the norm.
Crystal
Instead of focusing on processes and tools, the Crystal methodology focuses primarily on people and their interactions in project work.
Lean Software Development (LSD)
Adapted from the Toyota Production System, lean software development represents applying lean manufacturing principles and practices to software development.
eXtreme Programming (XP)
eXtreme Programming (XP) software development methodology is intended to improve software quality and responsiveness to changing customer requirements.
XP is often used in conjunction with scrum. It puts the focus on testing and assessing customer satisfaction at each iteration. It also provides the team with regular and speedy feedback in short development cycles, using:
- code review
- pair programming
- unit-testing
- frequent customer interaction
Scrum
Scrum is the go-to framework for developing, delivering, and sustaining complex products. Initially focused on software development, it can also be used in research, marketing, and sales.
Scrum is the most used Agile approach. And the most crucial element of this principle is employing a small and effective cross-functional team. The team members work closely together during each sprint.
There are frequent review and planning meetings, and each iteration runs a fixed amount of time. There are four components of a typical scrum: the product owner, the scrum master, the development team, and the stakeholders.
The role of product owners is both strategic and tactical. And this encompasses setting objectives and planning activities, and hands-on involvement. At a strategic level, the product vision is created based on the following:
- target group (who are your customers)
- their needs (what problem your product solves)
- competitive advantages (what makes your product stand out)
- business goals (benefits for the company)
Tactical planning activities include backlog management, prioritization, pivoting (when necessary), and data-driven decision-making. Product managers or dedicated product owners usually perform them.
Scrum master
The role of the scrum master could be described as the oil which keeps the wheels turning. This role provides guidance and facilitation to the work of the development team. It ensures that the right tasks are completed on time and any potential obstacles removed.
Development team
The “development team” is a cross-functional and self-organized group of specialists. They have the technical knowledge and skills to design, produce, test, and deliver new product or software phases.
Stakeholders
Stakeholders are also part of the scrum framework. These cover a range of different participants in a software development project. Examples are end-users, company management and investors, customer researchers, market researchers, operations managers, and support.
See more Scrum alternatives in our dedicated article.
Our favorite tools for Agile product development
A big challenge with overseeing Agile teams is managing the iteration scope, tracking the progress, and staying focused on the goal. After all, we want to encourage freedom, innovation, creativity, and self-management among the project specialists.
In the past, most managers used a combination of spreadsheets, presentations, and whiteboards to communicate their product strategy and roadmap. Then, they would use rigid project management systems to distribute the tasks between team members and deliver the fixed scope.
But as the application of Agile methodology evolved, another way emerged. It became clear that we needed purpose-built software tools for effective project coordination and communication. Many tools were born, and the vast majority of them work well with agile methodology.
Here are some that we frequently use for product development purposes at Railsware. They help us with management, product discovery, as well as things like requirements and documentation:
- Figma – for crafting interfaces and collaborating on them
- Jira – for managing and tracking complex projects, encompassing several teams
- Trello – for smaller projects and cross-team collaboration
- Coda – for team collaboration on ideas, solutions, and research
- Mural – for complex planning sessions and agile product inceptions
- ClickUp – for tracking bugs and prioritizing work
- Slack – for seamless communication within the team and with external stakeholders
- Google Hangouts – for video calls because nothing feels better than finally seeing your remote colleagues :)
- Dashboards for project management – for managing tasks and improving collaboration with the help of clear visuals and real-time data
- BRIDGeS – a flexible decision-making framework for product discovery and problem-solving. After years of experimenting with a host of similar tools, we decided to create our own — BRIDGeS — inspired by Pivotal Lab’s Inception framework. Since then, we have used this tool to develop ideas and solutions for countless in-house and client products.
Wrapping up
When comparing agile with a traditional approach, the former is often more challenging than the two. That’s often the case because:
- each team member is responsible for the feature, not only for their part of the work
- self-organization is required
- high-qualified specialists are needed
- ability to work in a team is crucial
- constant learning is a must.
However, it’s a practical approach to building products that clients will love with the right vision, tools, and people.
If you’re interested in exploring more about product development and discovery, be sure to explore our blog and BRIDGeS page, where we cover different techniques in detail and share a lot of our knowledge.
Thanks for reading!