Last week we took a front seat at TRIARE Team Talks session with our amazing QA Lead and Project Manager Myroslava. She discussed with us the principles and differences of agile methodology.
Agile Key Takeaways:
- Agile is the results-focused development methodology
- An agile team delivers working increments through continuous iterations
- They react quickly to the feedback and focus on continuous improvement
Why does Agile matter?
Myroslava began with conveying the basics. According to her, every project goes through similar stages from idea to realization. The sequence of the stages is called the software development life cycle (SDLC). They include:
Though one can develop a product moving randomly through all these stages, it’s better to have a clear process. It defines expectations and roles, facilitates communication, creates a common vocabulary, and formalizes what to do at each step. The work will go faster and a lot more smoothly, when you set ground rules.
Our speaker said it is because of vast experience that we now have many SDLC models to choose from. Agile was the latest to pop up. She then moved to showcasing the evolution of the models to helps us understand how Agile is different and is it really better. (Myroslava stressed that many models are still used today. We even ran a little test to recognize our own approaches.)
One of the oldest, implies a sequential passage of stages, each of which must be completed before the beginning of the next. The Waterfall model makes it easy to manage the project. Due to its rigidity, cost and time are predetermined. But this is a double-edged sword.
The waterfall model will only give excellent results in projects with pre-defined requirements. There is no way to take a step back. Testing begins only after the development is completed. Products may have flaws, which are revealed too late. The cost of making a change is high, as it usually requires a complete redo.
An iterative lifecycle model does not require a complete specification of requirements to start. Instead, creation begins with the implementation of a piece of functionality, which becomes the basis for defining further requirements (like a draft). This process is repeated.
The client is usually more satisfied, as they get to communicate their feedback at every iteration. However, a result of an iteration is still just a piece of software, which is far from a working product. The process is long, and sometimes the needs of a client can completely change before he gets a final result.
The spiral model is focused on risk analysis. It has 4 stages on each loop: planning; risk analysis; prototyping; assessment and transition to a new round. It works well for situations when failure is incompatible with the company’s operations. This model might be reasonable for complex and expensive projects, such as developing a document management system for a bank, when each next step requires more analysis than programming.
However, it is incompatible with most of the smaller projects. Designing several prototypes and assessing them takes time. The overall process is longer than just a development stage would take.
Inherited the step-by-step structure from the waterfall model. The V-shaped model is aimed at thorough checking and testing of a product at every stage, even the first ones. The testing phase occurs concurrently with the corresponding development phase, for example, unit tests are written during coding. This model applies to systems for which smooth operation is especially important. However, it takes a lot of time and effort to write the tests and documentation at every stage.
How Agile is different from other software development methodologies?
So now, we can imagine how the world looked like before Agile. All IT companies created products in their entirety. If, in the process, the team had a new idea, either it was ignored or everything had to be redone, returning to the previous stages. As a result, the deadlines and budget were stretched, and the products were not as good as they could be.
It became obvious that inflexible development is not suitable for large-scale projects. The market was constantly changing, technologies became obsolete – often making the product no longer relevant. Although agile principles were first discussed in the 1970s, the symbolical point in time is 2001, when the Agile Manifesto was published. It was written by 17 software developers who shared sympathy for a flexible, people-centric approach.
Agile is not a set of rules or guidelines. Agile is not even a methodology, rather, an umbrella term for several of them. Agile is a set of principles and values that encourage adaptability, communication, and delivering value for a client at every stage.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Principles behind the Agile Manifesto:
- Delivering value early and at every iteration is the highest priority
- Change of requirements is welcomed at any moment for the customer’s competitive advantage
- Iterations are as short as possible
- Developers work side-by-side with business people
- People should be motivated, trusted, and given all the support they need
- A face-to-face conversation is the best
- Working software is a measure of success
- Sustainable development and the constant pace is key
- Focus on technical excellence and good design increases agility
- Simplicity is essential
- Self-organizing teams produce the best products
- The team reflects on how to become more effective regularly and then follows the insights
Agile methodology steps
Agile process steps are similar to an iterative model. The major difference is that Agile is not just iterative, it is also incremental. The iterative model goes from a draft to a better version to a final version. The incremental model releases a product in parts. So, neither of them can offer a value until the project is completed. In Agile, the client receives a finalized part of a generally working product, at every stage. (That is often called an MVP – minimum viable product).
Scoping out and prioritizing is the first step for any project. The prior goal is to define the business opportunity and assess the time and work it will take to complete the project.
2. Requirement Analysis
Defining requirements for the initial sprint and a project as a whole is the next thing to do. Create a timeline, select team members, and allocate resources. Stakeholders should take an active part in the process.
This stage decides what the product will look like, especially in the first iteration.
Once a team begins work on the first iteration, intending to show a working product at the end of the sprint. The product will undergo many revisions, so the first iteration should only include MVP features. The iteration loop generally looks like:
- Assess feedback
- Plan the next round
When the customer is satisfied, the product goes into production. You finish it up with testing the system and addressing any defects, finalizing it, and launching. This phase is usually followed with ongoing support for the software and sometimes retirement.
What are the benefits of Agile?
- Rapid identification of wrong approaches
- Fast decision making
- Cooperation gives many benefits
- Changes are considered inevitable and are welcomed
- The final product contains the most useful features
- The business is more satisfied with the result
- Technical documentation takes less time and contains fewer errors
- Easier application maintenance
All this seems very tempting, but in practice, it can be difficult to switch to Agile. People are used to working on detailed terms, not every customer wants to communicate with the team every day… As soon as you start, many obstacles appear.
Myroslava summed up that there are special rule sets to simplify this task, called frameworks. In fact, Agile is a set of practices and frameworks that are collected under the “Agile umbrella”. For example, Scrum and Kanban, which are popular today. Each has its own rules, but they can be modified and adapted to the needs of the team.
To successfully adopt an Agile methodology, it is important to understand which techniques can solve which problem. After a break, we returned to discuss the Scrum system in detail.