Agile Common Sense – What the Founders Believed

 The founders of the Scrum Alliance and earliest Agile practitioners always maintained that Agile is NOT a prescriptive process- it’s a framework. The original intent was to set out some principles and then allow practitioners flexibility in determining what works best for them.  But human nature being what it is, there will always be people who are more comfortable with absolutes rather than shades of grey.

 In our practice, we constantly see users fall into the trap of treating Agile best practices as inflexible prescriptions.   In any dispute between what is considered “True Agile” versus a common sense approach to your specific situation, I firmly believe that common sense must triumph!

 Ken Schwaber references an example of the “Scrum of Scrums “ practice in his book “Agile Project Management with Scrum”. The “Scrum of Scrums” is used when there are large projects with interdependencies – usually on the same complex system. In the “Scrum of Scrums” , representatives from each individual  Agile team meet once daily. This is to resolve dependencies between teams. Some purist practitioners feel this violates the principle of “self-organization”  – that instead of a prescribed meeting, Scrum team members should freely talk across teams to resolve dependencies.  If your teams are able to self-organize without formal meetings, by all means avoid the “Scrum of Scrums”. If the complexity of the project makes it essential to have a “Scrum of Scrums” and if your teams are struggling to resolve dependencies, as a common sense solution go ahead with the ” Scrum of Scrums” and do not worry about violating some sacrosanct principle ! 

Similarly, we often find that on many projects, Agile principles are followed and each Sprint produces working and accepted code that is theoretically “Production Ready”.  But realistically, there are often a number of additional steps required to actually deploy the work into true production ( like : setting up the technical environment, communication, switching servers etc.) to be  “market deployable”. To address this, we typically recommend a formal “ Release readiness Sprint” where larger business and technical teams are given the chance to perform the necessary work.

Now, this idea should have purists steamed up because the basis of Agile is that you produce “shippable code”. In real-life, however we have found that in addition to these tasks, businesses have large numbers of additional stakeholders who are not directly involved in accepting stories (sometimes for political reasons!) It is sensible to have this larger group  take a look at the end-to-end system before official “release”.  In this situation, conducting “ User Acceptance Test sessions” , is a common sense solution. Of course, it must be structured so that any new requests go back to the Product backlog. Sometimes – especially if automated testing is not implemented – its even possible that minor bugs are discovered (of course that makes the case for automated testing – but that’s the subject for another post!).

In every situation,  refer to best practices, read up on others’ experience, but always apply common sense to your decisions!

Comments are closed.

About FitForProjects

Based in San Francisco, we specialize in dramatically improving organizational performance by utilizing pragmatic analytics and advanced project management techniques.

Contact Us

Need to contact Us? You can send an email to via LinkedIn or Facebook