Lessons Learned in When Is A Scrum Not A Scrum? Agile Testing

From this initial experience of Scrum, the main lesson learned was that, when properly applied, Scrum is a very effective project management methodology for software development.

However, I have also worked on a number of other projects where pragmatic deviations from the prescribed Scrum methodology were made to satisfy client or wider project needs. In what follows, I consider some of these deviations and whether a project that deviates in these ways can still be considered to be following Scrum. Test-specific considerations are examined first, followed by general considerations, which affect testing and development equally.

  • System testing not carried out during the sprint. For system testing to be successfully conducted within a sprint, a “sprint test” environment is required in addition to the developer sandbox environment. The sprint test environment should be a “private” environment, for the sole use of the Scrum team. It should be possible to make frequent deployments to the environment at short notice. Without this environment, Scrum cannot function. (Note that system testing is distinct from cross-system integration testing, UAT, nonfunctional testing, and operational acceptance testing. These types of testing are not normally carried out within the same sprint–indeed they may not be subject to sprint discipline at all).
  • Testers and developers not co-located. Communication is key to Scrum, and this includes communication within the Scrum team. Sprint testing relies on the testers enjoying good relations with the developers, talking to them frequently to understand the detailed design that the development team has chosen to implement to satisfy a given user story. If testers and developers are not sitting right next to each other, the frequent informal discussions(and more formal meetings)required for (1) the testers to understand what the developers are building and(2) the developers to understand why the testers have raised a particular bug cannot happen. This leads to the breakdown of effective testing and is a frequent cause of testing failure in an agile environment.
  • No requirements at all. It’s a common misconception, but in fact agile(and Scrum)does need requirements to function. Without requirements, the project would be chaos. The requirements should take the form of “user stories”–descriptions of the functionality that the system should offer to users. They should be worked out by a business analyst, in consultation with the “product owner” and other key stakeholders.
  • Additionally, agile can often benefit from a solution architect–someone who maps out the high-level components that are required to make the solution work and to make it reusable. The solution architect should have visibility of existing systems(or anticipated future systems) in the organization and so will be able to put together a high-level design that integrates well with these existing systems or makes integration with anticipated future systems straightforward. (Note that the solution architect should not attempt to specify the technical details of how systems interact–this should be left to the development team or technical architect).
  • Highly detailed requirements. Agile does not specify up front the detail of how to implement a piece of functionality; it expects the developers to work this out for themselves. This is based on the notion that no one will have a better idea about exactly what will and won’t work than the developers. A project that tries to specify requirements to a deep level is by definition not an Agile project(see also “No requirements at all”).
  • Some projects need highly detailed requirements. A good example would be a project to implement a new piece of regulation. The regulatory requirements are fixed:there is no room for manoeuvre here. This sort of project would not be suitable for an agile approach, but would be well suited to a waterfall approach.
  • Team is not left alone during a sprint. A fundamental principle of Scrum is that, during a sprint, the Scrum team is left alone to complete the workload it had agreed to at the start of the sprint. The Scrum team can only do this if they are not interrupted by changes to the user stories agreed at the start of the sprint or by requests for new user stories to be added to the sprint. Note that this does not mean that there is no interaction between the team and the product owner during the sprint:the product owner should be on hand to answer queries from the developers and to adjudicate on “bug versus feature” disputes as required.
  • Long sprints.A “sprint” is a short development cycle. The most popular sprint lengths are two and four weeks[94]. Sprints of longer than six weeks tend to defeat the purpose of Scrum–short development cycles and frequent reviews of the software product with the product owner are key to making a success of Scrum.
  • Stand-up meetings that take too long. A stand-up meeting should be short(maximum fifteen minutes). To encourage this, it should be held standing up. If it’s taking longer than fifteen minutes, it’s not adhering to the principles of a stand-up meeting. Instead, it’s probably become a design discussion or a debate about how best to fix a particular problem. This is all very well, but not a discussion that should keep the whole team back from continuing their work. The alternative explanation is that too many people are talking at the meeting. Remember that, while anyone is welcome to attend, only members of the Scrum team (i.e., developers, testers, business analyst) can speak.
  • Customer demands fixed scope and fixed time or price. It’s not that unusual for a customer to demand fixed scope and fixed price or time, but it is certainly not agile! Agile was founded on the philosophy that scope cannot be fixed, as change is inevitable. Time and price certainly can be fixed;however, agile states that when time or money runs out, the software artifact that exists at that point should become the live system(subject to successful integration testing, UAT, and operational acceptance testing, of course).

Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Agile Testing Topics