As Agile Practice Consultant at Planit, I began to notice trends in the types of questions I was being asked by both staff and clients. As such, I decided to invite the team to an open session on Agile where they could ask any questions they liked. This paper contains the collection of questions together my answer.
Question 1 from Maureen Lorenz: Should the Daily Standup occur in the morning or afternoon?
There are two school of thoughts when considering when a standup should occur as both have positive and negative impacts.
A good point around the morning is that issues can be addressed during the day as opposed to a standup in the afternoon which may be too late to get issues resolved, at least that day. However if there are major issues then those issues should not be left until the standup and should be addressed immediately by the tester and pursued to get a result.
On the other hand, a good point of having a meeting in the afternoon is that as soon as you come in the morning, you already have your plan for the day. It doesn’t really matter when a standup occurs as the points for team to discuss are:
- What did you do yesterday
- What are you planning for today
- Any blockers
Any discussions outside the above should be taken off line as the standup should be only 15 mins in duration.
The most important consideration is what is best for the whole team.
Question 2 from Maureen Lorenz: How do we get Project Managers to let go of the “management” of the project and let the team run the effort?
Story Task Boards and Burn Down Charts area good way for Managers to see immediately what is happening with the testing effort (or in fact any activities within the team) and can be used for them to report to higher authority. Agile is much more visible in showing progress, as long as the Project Manager can read this output.
This is in contrast to the general methods used by Project Managers which is a Gantt chart with percentage complete for each task. Project Managers often use this as they have no other way to identify progress.
Question 3 from Phaneendra Guntupalli: What are the typical quality metrics in Agile?
The most important of all the metrics is whether the Project team is delivering value, i.e. the functionality is delivered to the user successfully within the planned timeframe/cost/effort against the acceptance criteria as part of the showcase.
Other metrics that can be implemented are code coverage and Risk coverage, depending on the specific project needs, which would help in not only measuring testing success / failure, but also as an input into the test process improvement.
Care needs to be taken when using metrics in that they are used for the right purpose and not just as a way to highlight individuals which may not be performing in line with project / organisational expectations. Also there is no point collecting lots of data (which wastes time) when it is not going to be used.
Question 4 from Mannix Young: Why is test statistics progress information such as the # of test cases executed and passed/failed not so relevant in Agile methodology?
Agile is focused on delivering incremental Business value prioritising the highest value first. The key metric being, acceptance by the Business Owner of the delivered user story. Being 80% complete means nothing in Agile, it is either done or not done.
Even in traditional projects, the above statistic is of little value in itself. What needs to be articulated are the completed requirements or even a reduction in the residual risk.
Question 5 from Pavani Vaddireddy: Can an urgent request (from backlog) be brought into an iteration that has already started?
Once the iteration has started, ideally there should be no more CHANGE REQUESTS coming from the Business Owner. All new or changed stories should go into the product backlog. However, if there is an urgent request, it may be included into an existing iteration under certain circumstances.
This now depends on the length of the iteration and the period to the end of the iteration. For example, an urgent request can replace another user story when the iteration has just started but not when the iteration is almost finishing and work has already begun on developing it or technical debt will start to accrue. The team must agree to this and may agree to put other user stories back into the backlog to cater for this urgent request.
Question 6 from Nandini Chetia: Is Planit doing Agile Testing in client sites?
There are lots of Planit clients who are following Agile practices. Approximately 80% of Planit clients have at least one project that is using Agile methodologies and many more projects using hybrid forms.
It is worth noting that in the Planit Index respondents stated that around 72% of projects in some way follow the Agile practices in their organisation.
Question 7 from Lorenzo Gonzales: Is there any studies conducted that show Agile is cheaper compared to the traditional models?
There has been some analysis done in the industry comparing Agile with other traditional software development models but this is quite limited or is nothing more than anecdotal. In Planit, there was a study completed which set out to compare the benefits based on several pre-set criteria and conditions.
Five teams were formed to work on the same requirements and software in a common environment. These teams were made up of similar skill levels although those working in agile had sat the CAT course or had industry experience in agile. Two teams used Agile, one used traditional (waterfall) methodology and two teams did a bug hunt. Based on the gathered results, the team who used Agile identified more high severity defects compared to the other teams. For the bug hunt teams, we can consider that they were more cost effective given their shorter timeframes. It was also evident that the quality of the staff and the tool selection played a major impact in the results regardless of methodologies used.
Further information regarding this evaluation can be found here.
Question 8 from Monika Jha: How do Agile implementations differ based on the type of organisation?
Those specifically discussed were Government organisation where there is a challenge on maintaining traceability; Medical project with stringent standard requirement.
To overcome constraints within the organisation that you mentioned, we need to have additional documentation (although not as much as in traditional projects and only written “just in time”) in place and to maintain requirement traceability. We also need to have a robust process defined and followed by the team.
For projects where there are these additional constraints agile can be used, but additional rigour needs to be applied.
Question 9 from Jenny Trembath: Does the test basis for an Agile project differ from a traditional project?
The test basis for an Agile project is the same as for a traditional project, i.e. Business Requirements Document, Technical Specification, etc. However these may be in a different format e.g. user stories. Also the amount of documentation is likely to be substantially less as in agile projects the team are encouraged to talk about requirements rather than necessarily write them down. Also a lot more pictures are used or wireframes or prototypes.