Having an agile development process refers to a development methodology that guides the process of software development. It is both a set of recommendations and a way of thinking about building a product. Which makes it an approach in both senses of the word. For anyone unfamiliar with the term in a development context, it basically means what it sounds. An agile process gives the ability for a business to be flexible and to make necessary changes quickly and easily, to constantly assess progress and re-examine priorities at each stage of the process.
One of the most important components of an agile development process that has broad implications for any type of business is the ability to work in sprints. These are short, usually 2-week blocks of time in which a well-defined set of tasks are completed. Here’s some information about how that works.
Working with Sprints in the Agile Development Process
A sprint has a clear goal and a well-defined timeline. In the development process, this is usually two weeks. Each sprint starts with items that you add to a to-do list and have a degree of comparative difficulty so the team can get a sense of how long each will take without trying to define an exact timeframe- which is often difficult when it comes to software development. Throughout the sprint the team works only on the items that you have put into the task list- this helps prevent distractions that can eat up time and make the process more unpredictable.
Sprints are beneficial in several ways. First, they provide a regular check-in for the team. In a sprint, a scheduled time when you can review and discuss work, re-examine priorities. Next, they are a chance for a client or team to regularly examine a functioning product. In the agile model, the team usually develops work in “slices”. Where slices refers to the completion of a specific feature that can be shown.
The Agile Sprint Meeting(s)
The nature of the sprint meeting is important to the process. First, task someone with keeping the vision of the product. There should only be one vision keeper, or “product owner” to prevent confusion in the debate over items. If there is a team behind a client project, they should designate one person as a product owner. If it’s an internal project, only one person should be able to review and determine priorities. This also prevents a “too many cooks in the kitchen” problem.
This meeting, is actually two meetings in one. You can split up the two, but you often condense them to save time. The first meeting is the sprint review meeting, this is a meeting to look at what the team did in the sprint and to check items off the to-do list. If the project is a client project, this is a chance for the client to approve the work. After that, the second meeting is a sprint planning meeting. In that meeting a team looks at the total number of tasks currently on the list. Then adds anything new that needs to be added and prioritizes tasks for the coming sprint.
Alternative to the Agile Development Process
There a couple of alternatives to the Agile methodology, but most of our clients are familiar with Waterfall. This is an older method of development where the team introduces and agrees on all requirements at the onset of the project with milestone deliverables over a long period of time. We find that when you meet milestones, there’s little change or adjustments to the final product. That is without having a significant cost increase to the client. Therefore, we recommend the agile methodology over the waterfall methodology on most projects.
If you’re interested in trying to apply a similar method in your own company, consider contacting us at Grata to help consult on how this process can best be implemented. Grata consults with companies on their technology processes to improve current methods and consider tech-driven alternatives.