There is no ‘Best Practice’ in Agile
Joe Townsend has written an article along the lines what I have been saying for a while now – in Agile there is no ‘best practice’, and as Townsend puts it
What works for you, your team, division, corporation, etc. can bring another person, team, etc. to a screeching halt.
In particular, one needs to be very careful when trying to take waterfall best practices and trying to apply it to an agile context. Many of waterfall concepts and best practices are counter-productive and ineffective on agile projects.
Its only semantics, but the term ‘best practice’ often means this is the best way to do things and trumps all other approaches. I prefer the use the words ‘lesson learned’ or ‘guidance’. What one or more teams have done, should be used as a lesson learned that is to be adapted to the environment you are applying it to and used as guidance. No practice will work for everyone or every team in every context.
Before applying a lesson learned or guidance, you should ask yourself does it make sense and does it align with agile values and principles? Does it help me deliver software more quickly to my customers? Does it help with achieving technical excellence? Remember to discuss with the team before using any lesson learned or guidance.
RSS - Posts
Hi Chris,
I have this ongoing war with the old school of managers who have only recently adopted the agile way. The prescriptive document and checklist kind of methodology is the only one they trust.
The most recent battle is over the concept of ‘staggered testing’. The idea is to dedicate two weeks of a 6 week sprint to QA – ‘a compressed waterfall’. While I know that this is a fundamental violation of the spirit of Agile, I do not have enough ammo to make them see the benefits of interwoven QA and construction. Neither, do I have data on the pitfalls of staggered QA other than the fact that a SPRINT/Iteration could fail because of the inability to deliver a critical functionality which was broken and discovered by the QA only at the end of the Sprint.
What is your take on staggered QA?
Hi Jayant,
What you describe sounds very much like an Agile anti-pattern.
It really depends on what the ‘staggered testing’ consists of and how the team(s) are structured.
Importantly, the developers and testers need to work “together”. I don’t mean just sit near each other. The developers and testers need to collaborate with each other and the Product Owner. There should not be any throwing over the fence type mentality. Reading between the lines in what you describe it seems to indicate that the developers and testers operate in silos.
During the Sprint the team should have coded and tested functionality that is potentially shippable. Is this happening? And is the team meeting the commitments that it sets itself at the start of the Sprint?
The team should try to strive to include the following testing in the Sprint – TDD , Acceptance Testing , System Testing & Integration Testing. Is the team doing any of this? And are any of the testing automated?
If the ‘staggered testing’ consists of ‘production readiness testing’ (eg Exploratory Testing, Performance Testing, Scenario Testing, Security Testing , Regulatory Compliance Testing , UAT and other “ility” Testing) then this should be done outside the sprint. It can be done as part of the sprint, but it does require a very high performing team and lots and lots and lots of automation.
Also, you mentioned you have 6 week Sprints – this is a little long for Agile.
Chris
I think these terms, to that matter any term coined by the (software) industry to describe something, will be more relevant and expressive within “a context”. The term “guidance” and “lesson-learned” may be more appropriate when describing a generic engineering methodology or any technology agnostic methodology where you can make some critical judgment / tailoring of its usage for your needs. I believe the term “best practices” is still relevant within the technology / engineering practices. If you take a building industry analogy, where would you be if you don’t have a building code? Why software engineering can’t have one, for its engineering standards to achieve technical excellence?