This is the second of a three part blog series relating to Argenta’s adoption of Agile and Scrum. In this post I’m going to cover what the stages are following receipt of an order for our projects and how they utilise Agile and Scrum techniques.
The first stage of any project at Argenta is a ‘kick off’ with all the relevant team members. We have a number of objectives at kick off, the first of which is to review what the project means to Argenta as a business, closely followed by going through the technical aspects. This is kept relatively high level as we don’t want to get into designing the system at this stage.
We also need to ensure that the specification for the project is understood by our team, which requires everyone to have familiarised themselves with it prior to the project kick off. If we are collaborating with any other companies, their responsibilities are also outlined at this stage.
Our existing code and templates are then discussed to see what option best suits the project, this ensures that we are utilising fully tested architectures. An overview of the project plan ensures that all milestones are clear, so we know what is required and when.
Finally the responsibilities are distributed, which are grouped into four main categories; requirements definition, development, 3rd party testing and customer satisfaction. These fit into the roles of Developer and Tester discussed in the previous post.
The second stage of the project relates to the design of the solution, specifically how we are going to develop the software to meet the specification and how we are going to validate the solution to ensure conformity to the specification. This results in our first meeting with the client (although not the first conversation!) to go through and sign off our design and validation approach.
Stage three consists of the main element, development and testing. We start by defining the requirements and subsequently the development tasks. We have looked into NI Requirements Gateway to assist with this and can see the benefits of the tool, but need some more time to fully understand how it would integrate into our projects. Ideally the granularity should not be too detailed otherwise it becomes difficult to manage, but there needs to be enough detail to ensure the tasks are clearly defined.
Once the tasks are defined the highest risk tasks are identified and prioritised. This is to ensure risks can be mitigated as early on as possible.
During development we maintain regular contact with the client. We also adopt the Scrum approach and have short daily reviews (Scrums), longer if necessary, to highlight technical or timescale issues.
Testing is a massive part of the development process, but I will save that for another day…