AuraQ has vast experience helping organisations find the gaps that can be filled to enhance their business. This could be to improve efficiency, integrate legacy systems or deliver new portals and strategic applications to create competitive advantage. Contact us to request a free, no obligation Gap Analysis.
The Agile road to software development
The rapid growth of the digital economy in the last few years has brought a drastic change in the field of software engineering. When we talk about selecting a software development methodology, choosing one that is agile has secured its place in many organisations and it is common place to find traditional software development methodologies frequently being replaced by agile ones which can handle changing business requirements much more effectively.
Agile software development has a major influence on how software development is conducted and enables organisations to build applications rapidly with regular customer interaction. Traditional methodologies, like Waterfall, take a step by step approach to the software development lifecycle e.g. defining, designing the requirements, building and then releasing. Agile methodologies, such as Scrum, differ by doing a little of everything in each iteration (sprint) of the software development lifecycle.
There are many versions of agile methodologies (Extreme Programming (XP), Scrum, Kanban, Feature-driven development etc) but in this blog, I would like to share a brief introduction about Agile Scrum and how software development is done in this way at AuraQ, whether it be internal or for our customers.
We follow the agile values and principles to their core. As most of you know, a team can go off track very easily and think they are following agile correctly but, in reality, they just create their own version of Agile Scrum. So, at the start of each project, we try to make sure everyone within the project team are practicing Agile Scrum appropriately. It’s important that everyone in the team has at least a basic understanding of Agile Scrum, know their role within the project and agree ‘Definition of Done’ so for this reason, we would suggest running a brief introduction session on Agile Scrum (2-3 hours) covering the agile manifesto, key agile principles and characteristics:
Manifesto:
Key Principles and Characteristics;
- Satisfy the customer through early and continuous delivery
- Welcome changing requirements, even late in development
- Deliver working software frequently
- Business people (end users) and developers must work together
- Face-to-face conversation
- Team retrospectives
- Self-organising teams
- Iterative, incremental and time bound – product progresses in a series of two to four week “Sprints”
- Capture requirements as items in a list of “Product Backlog”
The Agile Approach
With the team familiar with Agile, the next step is to outline, analyse, design, plan and prioritise all of the project requirements and define a set of requirements for the first iteration. Once the first interation is in place, then further processing takes place to include planning, analysis and design followed by development and testing.
This process/approach is followed in every iteration. Lessons learned would be discussed within the team after each iteration, and the outcome of this discussion is found in the answers of these three questions; what did we do well? What could we improve? What mistakes and problems could have been avoided?
What is Scrum?:
The Scrum process is strictly time-boxed and the below Scrum framework diagram illustrates the software development lifecycle using the Agile Scrum methodology (this is worth going through with the team even if they know agile scrum as it provides a good recap).
The Scrum Framework:
A brief description of the scrum framework is illustrated in the below diagrams:
With the above in mind, here is a further break down of how sprints are planned and how the above roles, artifacts and ceremonies are included:
Project planning: Initial project planning is conducted (Sprint 0) with input from end users, customers and other stakeholders, this is where all functional and non-functional requirements are captured. A list of all these requirements is called the product backlog, which is owned, managed and refined by the product owner.
All requirements are captured in terms of user stories (a short, simple description of a feature told from the perspective of the person who desires the new capability) and there will be acceptance criteria against every user story. The format of a typical user story would be:
Sprint planning: The next phase is sprint planning. A sprint is an iteration for a fixed duration of time (1 – 4 weeks). Agile projects make progress in a series of sprints and therefore each sprint includes a selection of user stories from the product backlog. Each sprint begins with a sprint planning meeting, the length of this meeting will depend on the length of the sprint e.g. if the sprint duration is four weeks then the meeting will be time-boxed to a maximum of eight hours. (In general, to estimate the total length of a sprint planning meeting you can multiply the number of weeks in your sprint by two hours).
Attendees for sprint planning include the product owner, scrum master and the development team (it may also include end users, developers, business analysts, UI designers and testers that are related to the sprint). The product owner explains the prioritised requirements that need to be developed in the sprint and scrum master will act as facilitator to enable self-organisation, close collaboration, ensure the team is fully functional and productive, enact agile values and practices and remove any impediments.
At the end of sprint planning, the list of user stories will be selected from the overall product backlog and the list of selected stories will become the “sprint backlog.” At this point, a sprint goal and duration is defined and the development team will work for the agreed sprint duration to achieve sprint goal.
*Best practice tip: Constant sprint duration leads to a better rhythm and it’s advisable to plan sprint durations around how long you can commit to keeping change out of the sprint.
Sprint kick-off: The sprint cycle starts as soon as the sprint backlog is created and the sprint duration is defined. In the sprint cycle, the development team will start to analyse, design, build and test the user stories in the sprint backlog and daily scrum meetings will be conducted.
The daily scrum is a communication meeting within the team which is time-boxed to 15 mins and the product owner, scrum master and development team will attend. This meeting will be hosted by the scrum master and the main agenda will be to provide updates on the sprint progress, e.g. what have I accomplished since the last daily scrum? What do I plan to accomplish between now and our next daily scrum? Is anything impeding my progress?
As soon as a user story in the sprint backlog is developed and tested the story is then marked as “Done”. A scrum board will display the sprint status to stakeholders and the project team; and will display how many stories are at the status of “ToDo”, “Running” and “Done”. These statuses will then be input for the burndown chart which is produced at the end of every sprint.
Sprint completion: Once a sprint duration is completed and all stories are marked as “Done”, a sprint review meeting (time-boxed between 1 – 4 hours depending on sprint duration) is conducted. This meeting is a show and tell session on everything that has been ‘done’ in the sprint and typically takes the form of a demonstration of the new features.
The purpose of this meeting is to receive feedback from end-users and gauge an understanding of whether the project is still going in the right direction. At the end of this meeting, the product owner will decide if the sprint goal has been achieved successfully, if yes then the sprint is ready for deployment, the next sprint planning meeting is arranged and the sprint cycle starts again.
Lastly, there should be a sprint retrospective meeting which will be scheduled after every sprint review meeting (time-boxed between 1 – 3 hours depending on the sprint). The product owner, scrum master and development team will participate in this meeting and the focus will be to review how things went with respect to the process and the relationships among the people and the tools. It will also identify what went well, what didn’t and detect potential improvements to come up with a plan for improving things in the next sprint.
If you would like to seek any help or support related to Agile Scrum, feel free to contact us.
Related Blogs
Drag