There are different practices on each phase of modern software projects, but there is one that is present in all of them, agile. In the Ideation phase the business ideas are created by defining value-creation opportunities. Then the business strategies are defined to start and grow up the business. The Development phase includes the design, coding, and testing of the solution and services. When a stable and useful solution is built it’s time to deploy it to the costumers. During Data Analytics some metrics are measured and tracked against the business objectives. And based on these metrics the team can improve user experience and start again in the loop until the project is considered finished or canceled.
But why is agile so important in modern IT projects? Is it tendency or is there a big advantage over other methodologies? Are companies using it correctly? And most importantly what is the idea behind agile?
Let’s find out.
SCRUM, Kanban and XP are some examples of the most widely-used agile methodologies. But there are some people, including me, who believe that agile is also a mindset. I remember a teacher asking during a master class “what animal do you think on when I say ‘agile’?”. The most common answer was ‘Cheetah’ because it is the fastest land animal, but he argued that agile is not about the speed but the adaptation to the new circumstances so his answer was a ‘Chameleon’ because it camouflages to the environment.
The most important thing in these methodologies is the team and how they adapt to the challenges in their projects. There is a popular misconception that agile means to be faster and create fully working products in a short period of time, but the truth is that it is almost impossible to achieve. An agile team must be able to take decisions and prioritize features that are valuable for the users and the business. And this is one of the main differences between doing agile (just following the methodology, i.e., doing waterfall inside SCRUM) and being agile (the team truly adapting to the circumstances and taking the best decisions).
Let us now focus on SCRUM where we have the roles of Product Owner (PO), Scrum Master, and the Development Team. The PO is in charge of defining the backlog items, prioritize activities, and solve the business questions that the Development Team may have. The Scrum Master must be able to coordinate the efforts and ensure the team follows the agile practices. The Development Team must be cross-functional and self-managed. However, these roles are not easy to implement as it depends on the maturity level of the whole team. If the team is not mature enough in SCRUM it requires the constant involvement of the Scrum Master to solve conflicts, recall the responsibilities of the members, etc.
Some tools are popular in the market for agile teams such as Jira Software, Azure DevOps Server, Trello, and the list continues. These tools are very powerful and give solutions to manage the agile projects, however using them does not mean the team is agile. For instance, the user stories should have the characteristics of the INVEST acronym (Independent, Negotiable, Valuable, Estimable, Small and Testable), but in some cases these characteristics are omitted in the user story refinements.
In the image below you can identify four parts of a user story(remember the business objective it’s the value and dictates the importance of the user story).
The ideal project would be the one that have a defined plan and design, a complete list of clear requirements, coded in the right time without issues or bugs, working in the first attempt, and deploy so the users gets exactly what they wanted on time and without extra costs. This may seem utopic. But luckily, we have agile to break down this process into small pieces and execute those pieces in iterations. The idea of these iterations is that the team can provide product increments that are valuable to the customer and get feedback to make corrections or improvements. Basically, do not try to get it all right from the beginning and do not build it all at once.
The question now is, why there are still projects following the waterfall approach? There are different answers to it. There are big companies with huge systems and applications that still require a lot of documentation, or applications that do not need to be in the market in the near future, or simply because it is hard to change. Remember agile is a mindset, and one of the most difficult things to change are people’s ideas. Despite adopting Scrum, XP, Kanban etc., many teams still find it hard to create successful projects.
Explaining the Agile Manifesto and Principles
If you are working on an agile methodology keep in mind the following agile manifesto, which will help you identify what is more valuable for the team.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. From now on,please have more conversations with your team, ask questions, and do not rely lotto much on the tools, emails, etc. Having a working software is more important than creating a complex document that few people will read. Involve the customer in early stages and along the project development instead of asking their feedback late in the game. Above all, be flexible to changes.
Based on the agile manifesto there are 12 principles that help teams to be agile. I will briefly explain what each of them are about:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
It is important to identify customer needs and prioritize features. This will help you solve their needs and obtain valuable feedback from them.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
This doesn’t mean all changes are going to be accepted without discussion. But again, the team should be flexible and open to dialog when there are more important features to build.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Releasing the most valuable features to the users will help you gain valuable feedback to take better decisions.
4. Business people and developers must work together daily throughout the project.
Since there are no exhaustive documentation, the developers and BAs must work together to clear doubts and take quick decisions.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Agile teams must be self-driven and cross-functional. They should be proactive and be experts in what they do.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversations.
The most ideal way is to have the entire team in the same place. That’s easier said than done, since teams are evolving and with the current health crisis situation it is hard to have them under the same roof. However, there are alternatives such as a video conferencing and virtual meets etc.
7. Working software is the primary measure of progress.
Enough said. Having something working is the clearest evidence of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The team should focus on what is important, and do not get distracted with other processes that may affect their work and deliverables.
9. Continuous attention to technical excellence and good design enhances agility.
Following tech best practices enables the team to obtain better results and focus on improvements rather than just fighting with technical issues.
10. Simplicityis essential.
Keep it simple. Do not over complicate tasks on assumptions and needless work.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
Having the whole team involved in the development process improves their performance. Also, the need for documenting every single decision can be avoided as everyone is aware of what is going around.
12. At regular intervals, the team reflects on how to become more effective; then tunes and adjusts its behavior accordingly.
From time to time, the team proactively retrospectives to what is working and what is not, based on which they can take necessary actions.
Conclusion
Agile is all about the people, and quickly getting the right feedback to generate value to final users. If you think your team is just doing agile instead of being agile, try and implement the agile manifesto and principles to achieve better project outcomes. Remember to be a Chameleon and adapt, instead of being a Cheetah who just does things fast.
More interesting information about agile can be found here: https://www.agilealliance.org/agile101/
