Agile development methods have many benefits; adaptability to changes, close collaboration with stakeholders and improved efficiency being the most valued ones. But how do you make sure your project is really taking full advantage of Agile, and not just being agile on the surface?
In this post, we have explored some of the basics of Agile software development from a practical point of view. We interviewed Richard Yang, one of our experienced team leaders who plays the role of a scrum master, business analyst and project manager, depending a little bit on the type of project.
The first thing to understand is that agile development is a combination of methods, tools and a mindset. They all work together to speed up the process and make the development team focus on the most important points. Take for example the stand-up meeting. It is meant to be a quick review of what's been done, what is planned next and what might be blocking the progress. To make it efficient, every team member should prepare for it, at least mentally, so that all topics can be covered briefly yet thoroughly enough. If the stand-up meeting starts taking more than 15-20 minutes and turns into lengthy discussions or debates, you'll know the team has drifted away from Agile. Regroup, re-focus and try again.
Delivering frequent, tested and usable increments of the (software) project is what we aim for in Agile delivery. Frequent delivery can create a tight feedback loop between the development team and stakeholders, the customer. This loop is vital especially when they are also the end-users of the software. That is because it might be difficult for them to envision the final requirement before they have seen or tried how the software feature works. Essential dependencies or variations come to mind when viewing the demo.
In Agile we start with defining the user stories so that the most critical features are prioritized and worked on first. In the sprint backlog the user story should be small and clear enough to be estimated in story points. If they are too general or vague like "invoicing module for account manager use" it might not be possible to finish the whole big chunk in one sprint. It just becomes too difficult to pick the most crucial functionality to complete, and timelines start creeping. You should go back to the user story and break it into smaller pieces, and make sure each story has a defined completion criterion. That way you can keep building an efficiently groomed backlog and keep the project on track. In our example case we divided one invoicing feature into three stories:
DevOps works very much hand in hand with the agile process. DevOps also aims to make the whole development cycle faster and eliminate any unnecessary back and forth, like the developer having to go back to infra team to set-up new access to the environment, and tester having to deal with unclear expectations from the business users because the function is no longer how they required. This could be the scenario if the team has worked on the release a long time before finally introducing it. The principle in DevOps is to integrate the development and operations, and one way to technically achieve it is using continuous integration.
Continuous integration is commonly used in Agile, but it is not a default. Teams still might have different ways of doing it. The benefit is that when everyone delivers their part or piece of software, it is all coming together incrementally, just as intended. Testing can be carried out quickly at every stage, and any changes or clarifications in user requirements that would also result in changes in other functions or modules are detected immediately. Some popular tools used for continuous integration are Jenkins, Bamboo and Travis CI.
Continuous learning and improvement are at the heart of true Agile. Retrospective meetings are a great way to assess how well did the sprint go, and could the team do some things differently in the next one to make it even better. We're not meant to criticize but look at things critically and give the team a chance to improve. Self-motivated developers and teams are encouraged to seek better alternatives and consider the business value.
If you would like to learn more about Shinetech services and our agile delivery models, please visit our website www.shinetechsoftware.com