Preamble, background, etcScrum is a process improvement framework that has grown up within the world of software development and/but is increasingly used not only within the world of software, but outside of it also. Scrum in-fact lends itself well to product development in general. This post focuses on Scrum (and frameworks like it); in particular how it copes (or doesn't cope) with significant organisational change and where/when improvisation becomes more important than a framework.
The following links provide some information about Scrum:
- A 1986 HBR article that introduces the basic concepts: https://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG
- The Wikipedia page on Scrum: http://en.wikipedia.org/wiki/Scrum_%28software_development%29
An acquaintance of mine recently asked an interesting question about Scrum...which was essentially:
"What do you do when an established Scrum team encounters a serious problem?"
["What do you do...what do you do...?" - source: http://chaffeenguyen.com/win-win-situations/]
As a process improvement framework, Scrum is able to cope effectively with most of the day-to-day problems that an organisation may face. Occasionally though the problem is simply a mismatch for the framework - just too big. For example; the business has changed hands, management has changed and/or the business' strategic direction changes.
Scrum works great when business is relatively smooth; it surfaces problems to be resolved by the team/business, etc. Beyond a certain size/volume of problem(s) though Scrum seems to become impractical. What emerges then is a need for the team to lean more heavily on it's ability to self organise and improvise - outside of any framework - in order to be able to recover effectively or perhaps survive. For this reason, I have come to think that drilling a Scrum regime across an organisation is not necessarily always best for business.
Strategy and the importance of improvisationTo reach their true potential, teams need to have the freedom to explore, develop and optimise their own capabilities within themselves and outside of any set framework. Rigorous adherence to a framework can mar the natural and relatively fragile team-gelling process. Another trade-off to rigorous adherence to a framework is that a team's improvisation skills become rusty. And the ability to improvise in particular is key not only in emergency situations but also (arguably, more-so) in day-to-day business.
[Miles Davis; exemplary improviser - source: http://www.fastcompany.com/3000340/if-miles-davis-taught-your-office-improvise]
Furthermore, in reality, business is not about trying to get things to go as smoothly as possible - to survive and be prosperous, a business must seek out and overcome difficult challenges. If we focus on "getting to smooth" then we invariably begin to steer clear of challenges (AKA opportunities).
A successful business (or one that at least plans to succeed) will have strategic direction and in alignment with that strategy some challenges will need to be avoided. More importantly though a business' strategy ideally will generally - and openly - identify the type of challenge that it wants to line-up and engage. That way at least everyone knows what the intention and direction of the business is and can have a feel for what's right and what's not.
Of course, engaging and avoiding challenge is a balancing act that needs to take in to account resourcing, scheduling, cashflow, etc. Shying away from challenge purely in the interest of maintaining stability though is essentially laziness or myopia. Of course, this is deadly in business - remember Kodak? MySpace? Etc.
Where am I going with this in terms of the framework...? Well, from a strategic perspective, the framework is simply a tool that's there to help a business reach it's strategic objective. Interestingly, working within the framework it can be difficult to identify if/when the framework itself has become a problem. It can happen though, especially in times of significant organisational change - a framework can in-fact be used as a shelter; a means to avoid or delay dealing with organisational change openly. In this situation things can become fuzzy and political - so I won't take this line of thought any further. I wanted to at least identify this point as part of this post though.
Is the framework still relevant?So, certainly not suggesting that Scrum and frameworks like it are rubbish - far from it - they can help new teams get a great kick-start and can provide a clear ramp-up for organisations new to Agile.
[Bamboo scaffolding, Hong Kong - source: http://www.archdaily.com/tag/architectural-photography/]
What I am suggesting is that beyond a certain point - whether it's due to an organisation reaching a certain level of maturity or an unavoidable and significant organisational change - the framework may become irrelevant and perhaps even cumbersome. It's worth being aware of this as a possible scenario, and if possible maintaining a general "feel" for a framework's relevance within the organisation.