I am under no illusion that this is a topic that divides many in the Agile community. Obviously, I bring my own perspective and in the spirit of Agile and everything collaboration, I welcome (and am open to) other opinions and experiences.
Back in 2006, I had the opportunity to learn about this shiny new methodology called Agile Scrum. As I went through various classroom courses, one message that came up repeatedly was that “you are not doing it right if you don’t do this by the book”. This comment was repeated when 100% of the training audience found the ‘requirement’ of having a dedicated team on Scrum projects unreasonable. Subsequently, other topics came up such as elimination of non-value add documentation, self-managed teams, co-located workspaces, etc. While I understand, appreciate, support, and advocate for these tenets, something didn’t sit right with me about the ‘all or nothing’ deal with Agile – i.e., real life is rarely “by the book”.
Let me elaborate further; one thing that the ‘book/literature’ fails to capture in its full essence is the context which happens to be different for every entity whether it is an organization or a person. While we can come up with a somewhat compelling framework that could apply (at a high level) to organizations with certain similarities, there is still a need for tailoring and adjustment. Not to oversimplify this scenario, there are organizations (public, financial, insurance, and others) that are regulated to produce certain deliverables that may be considered non-value add from Agile standards but are absolutely needed. Similarly, some organizations are too engrained and advanced in their current frameworks (traditional methodologies) that it is neither practical nor feasible for them to jump into a full-blown Agile implementation (dedicated teams per project, abandonment of existing deliverables, etc). I have personally witnessed organizations struggle/fail due to the ‘big bang all-in’ approach to Agile.
Regardless, the Agile community has most certainly evolved over the last decade and many practitioners have realized the need for different implementation strategies based on the organization’s size, portfolio, and other factors. This has resulted in an enlightened view of Agile Scrum implementations and several new proprietary Agile methods such as Scaled Agile, Disciplined Agile, and more. While these methods may adapt better to today’s organizations, one-size still doesn’t fit all. Despite a better appreciation for organizational characteristics such as size and portfolio, what remains missing is the understanding of culture and context which makes every single organization UNIQUE. This is where the judgment comes in … finding the right balance between ‘being Agile’ and ‘looking like Agile’. I have found that the right Agile leadership and enablement team is crucial to address the judgment aspect of implementations. In fact, this could be the deciding factor in whether the implementation would be a success or a failure.
If an organization embraces the Agile principles too loosely, they run into the risk of ‘bad implementation’ which only creates an additional workload for employees (to learn and apply new toolkit) without the benefits. An example would be an organization that decides to use “Agile Scrum” with 3-6 month sprints/iterations thus eroding the value derived from manageable iterative development (fail fast, learn fast). Similarly, an organization that chooses to follow the traditional Waterfall approach by forcibly fitting it into “Sprints” thus ignoring the core value of building something of customer value at the end of each sprint.
On the other hand, an Agile implementation that is well-tailored to the organizational culture and context could produce powerful results without ‘by the book’ implementation. For example, a software company legislated to produce comprehensive legal policy prior to releasing the finished product, thus requiring the use of a hybrid methodology (Scrum-Waterfall); Scrum for product development, and Waterfall for the tail-end legal activities. Another example would be an organization that ends up using ‘semi-dedicated’ team on Scrum projects with fixed allocation, thus allowing for velocity to stabilize (for adaptive planning) without having to uproot the existing resource model. Guess what? It works for some organizations, but not for others. As a side note, this example typically sparks a heated debate among Agilists, but there is only one thing that truly matters … does this model provide the desired benefits to the organization? If yes, let’s move on. If not, we have just learned something important (in the context of a particular organization), and can further adjust the approach for better results.
The intent of this article is neither to discuss the intricate details of each of the examples presented above, nor is it possible to do so at this forum. The key message is to appreciate the uniqueness of each organization, as you decide on a strategy and approach to implementing Agile methods at your own organization.
So what do you think? Is it worth it to push towards a “by the book” Agile implementation?
