In this post we continue the theme of Agile and Quality with some thoughts on the people and skills that need to come together to make an effective Agile team. If we refer back to a previous post, there are several characteristics of the agile approach which impact team organisation. These further differentiate the team from the more traditional approach of waterfall style development.
Some key characteristics:
- Faster cycle times – sprints, timeboxes
- Empowered business representatives – ambassador users
- Multi-disciplinary teams
- Co-location – an interesting concept in these challenging times
- “Lab” environments
- Solution visualization – User Stories, Iterative prototyping
- Incremental development
Agile teams are based on the concept of ‘whole teams’ - an Extreme Programming (XP) practice that suggests you have sufficient skills within the team itself to get the job done. The implication is that the team has the requisite skills e.g. development, database, testing, user interface skills etc. to minimise its dependence on external experts or teams of experts for these sorts of things.
The level of “independence” required depends on the size and capability of the IT organisation, and the level of central “supports” available to Agile teams in that organisation.
Because Agile teams are ideally small and need to cover many business and technical capabilities, they tend to favour people with multiple capabilities. These people are often referred to as “generalising specialists”. A generalising specialist is someone who has at least a general knowledge of software development and the business domain in which they work. They may have one or more technical specialties e.g. Java programming, project management, database administration, software testing etc. Ultimately the team should have a common base of understanding and each person can contribute something of direct value to the team.
Ideally, each team member sees the assignment as a personal development opportunity and actively seeks to gain new skills in both their existing specialities as well as in other areas, including both technical and business domain areas. It is a given that each person is required to be “a good team player” and has good interpersonal and communication skills. It is also desirable when “building” an Agile team to keep it together over a number of iterations (sprints & time-boxes) as experience, trust, productivity increase over iterations. The temptation to “seed” good members into other teams needs to be resisted.
As well as capabilities there are team roles that need to be performed. These roles may have different names depending on the methodology being followed. Roles are not positions, and as with capabilities any member takes on one or more roles and can switch roles over time. The common Agile roles are:
- Team lead. This role is responsible for facilitating the team, obtaining resources for it. Flying “air cover” for it covers the soft skills of project management and facilitates the technical ones such as planning and scheduling activities in which the team as a whole is involved.
- Team member. These various roles, developer/programmer, tester, business user, are responsible for the creation and delivery of a solution through the full set of activities including: modelling/design, programming, testing, environment, data management, and release activities.
- Product owner. The product owner is the one person on a team (or sub-team for large projects) who is responsible for the prioritised work item list called a product backlog in Scrum. They make decisions and provide information in a timely manner.
- Stakeholder. A stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the business “owner” or “sponsor” who funds the project. This could also be a support/help desk staff member, auditors, your program/portfolio manager, developers working/maintaining other systems that integrate or interact with the one under development, or technical/infrastructure professionals potentially affected by the development and/or deployment of a software project.
The Agile process is more fluid, requires continuous testing and has certain characteristics:
- Quality/Testing is the team’s responsibility – everybody tests
- Testing is continuous
- Multiple stories/components may be in test at the same time
- Greater focus on automated testing
- Testing is “layered up” as functionality matures
- Input artefacts are different – user stories, wireframes
- Documentation develops as the function develops
As well as these characteristics there are different types of testing that need to be executed. Traditionally this would have been Unit, Integration, System, User Acceptance, Performance, Regression etc. Now testing is continuous and multiple types of testing are executed in a cycle e.g. Sprint.
Brian Marick came up with a way to categorise the different types of Agile Testing by 2 dimensions:
- Tests that support programming or the team and tests that critique the product
- Tests that are technology facing and tests that are business facing
a) Agile Quadrant I – The internal code quality is the main focus in this quadrant, and it consists of test cases which are technology driven and are implemented to support the team, it includes
- Unit Tests
- Component Tests
b) Agile Quadrant 2 – contains test cases that are business driven and are implemented to support the team. This Quadrant focuses on the requirements. The kind of test performed in this phase is:
- Testing of examples of possible scenarios and workflows
- Testing of User experience such as prototypes
- Pair testing
c) Agile Quadrant 3 – This quadrant provides feedback to quadrants one and two. The test cases can be used as the basis to perform automation testing. In this quadrant, many rounds of iterative reviews are carried out which builds confidence in the product. The kind of testing done in this quadrant is:
- Usability Testing
- Exploratory Testing
- Pair testing with customers
- Collaborative testing
- User acceptance testing
d) Agile Quadrant 4 – This quadrant concentrates on the non-functional requirements such as performance, security, stability, etc. With the help of this quadrant, the application is made to deliver the non-functional qualities and expected value. Activities include:
- Non-functional tests such as stress and performance testing
- Security testing with respect to authentication and hacking
- Infrastructure testing
- Data migration testing
- Scalability testing
- Load testing
Developers take the lead on code-level tests (including component performance) and may incrementally develop automated test packs or these may be developed by technical testers using test automation tools. Developer testing is a mix of traditional unit testing and traditional service integration testing. Developer testing verifies both the application code and the database schema.
Business representatives have a focus on acceptance testing and may do exploratory testing under guidance. Agile acceptance testing is a combination of traditional functional testing and traditional acceptance testing as the team, and stakeholders are doing it together. The non-functional requirements or “stories” are normally covered by technical specialists and the degree to which that needs to be fully satisfied within the agile team will depend on the IT model and structure supporting the teams and the degree to which Agile/DevOps practices are embedded or mature in the team and organisation.
The tester(s) on the Agile team provide early feedback during all stages of development and coach / support the “testing mindset” in the team. They are aware of progress on unit testing, functional testing and business acceptance, and take the lead on acceptance test automation, building regression test plans, and uncover additional test scenarios through exploratory testing. The Senior Tester or Agile Test Lead should act as the “Agile Test Co-Ordinator” who liaises with team members, plans and co-ordinates the test effort across the team, represents Test at “stand ups”, participates in Sprint planning and ensures that all team members are playing their part in ensuring the output meets the quality standard in “done”.
At Vantage Resources we use our METISURE framework to co-ordinate our delivery of services to clients. This support includes; helping clients identify how their SQA and Testing model is working for them, where they want to get to on their Agile journey, and what a Quality “roadmap” would look like for their organisation. We then supply whatever expert resources they require to support/assist them on the journey.
Vantage Resources can help you!
Ideally you should be able to answer a definite “yes” to the following 3 questions:
- Are you totally confident in your Quality Assurance and Testing model(s)?
- Could you clearly stand over them as best practice in the event of an issue?
- Would they stand up to external scrutiny?
If you have any concerns in attempting to answer the 3 questions you should be talking to us.