You might have heard from frameworks or methodologies like Lean, Agile, Six Sigma or Lean Start-Up. You might have seen or experienced yourself successes or complete disasters trying to adopt (maybe forcefully) a certain way of working.
Is such a framework a blessing or a curse? As usual, it depends.
Choosing a common framework definitely has its benefits and should be your choice if your context is reasonably similar to environments in which that framework has been applied successfully.
For example, if you have one team that is trying to develop a simple app, probably ‘Scrum’ is a very good fit. If you are in a manufacturing environment producing fast moving consumer goods, probably ‘Total Productive Maintenance (TPM)’ is an excellent fit.
Choosing one methodology does not exclude other frameworks. Consider it as one being the master: this one offers your stepping stone for all the rest. You can simply add great ideas (principles or practices) from other frameworks to it.
The reason this is the preferred option is straightforward: you can move much quicker when selecting a well-known framework. The principles & practices are well documented and it is easy to get coaching or training (although the quality isn’t always as it should be, unfortunately).
Even if there is not a perfect fit, you might still want to choose a popular framework where you will make minor adaptations. And I hear you say “But our environment is very different. That does not apply to us.” or “Our environment is very complex.” Every organisation has its own context, but the above statements are often merely excuses. Most organisations have much in common and most are not that complex (contact us if you want to confirm your belief). So, most times, your organisation fits the bucket of ‘reasonable’ fit.
As an example, I worked for a pharmaceutical manufacturer for which ‘Lean’ made perfect sense. One of the lean principles, however, is one piece flow. The assumption behind one piece flow is that quality can be measured easily and foremost immediately. Unfortunately, in aseptic manufacturing, there is a compulsory check for microbiology, which involves culturing potential bacteria in a petri dish. This procedure takes >48h. It would be foolish to keep pursuing one piece flow in this context. That does not make ‘lean’ a bad thing. Pursuing ‘Lean’ still makes a lot of sense in this context. It only indicates that this context has a specific difference compared to a context in which single piece flow is a worthy goal.
A note of caution: all too often, a team makes adaptations from the standard framework without fully understanding the underlying principles. That doesn’t work very well. You quickly have a diluted version of a proven methodology that does not deliver its potential.
Although in many situations, there is a reasonable or even excellent fit, in many situations, there is not. To detect that, one needs to go back to the underlying assumptions, like the above described example for one-piece-flow. Here is another example: the ‘Spotify’-model is quite popular and people try to copy it. Unfortunately, few know Spotify developed this model at a time it was growing double digit, hiring like crazy. Their key challenge was getting people on board. The resulting structure is rather overhead heavy: senior employees trying to get many new hires on board. So the overhead heavy structure was exactly what they needed. The question is: does your context benefit from this somewhat higher overhead? If not, the ‘Spotify’-model may not be the best choice.
In another organisation I worked for, ‘Lean’ (and more specifically ‘TPM’) was the primary framework, because ‘Six Sigma’ was too complex. They had a lot of waste around their factory, which they wanted to reduce / eliminate. They decided to execute a large value stream mapping (VSM) – a common tool to map opportunities – across the full factory. A team of senior employees spent one full week on it. Unfortunately, it became a huge amount of paper that was never used. The problem, it turned out (but not as a result of the VSM), was an issue with variation in batch quality. This caused ripples across the full supply chain. Doing lean was like treating symptoms (the exact thing that ‘Lean’ wants to avoid). The required solution in such situation is ‘Six Sigma’ to reduce variation, regardless of whether that is perceived as challenging. In this particular example, ‘Lean’ would have been a suitable vehicle if the variation of the batches was in control.
In some situations, it is really hard to find a suitable framework. Say, for example, you work on an innovation team in a well-established FMCG manufacturing organisation. Your counterparts in manufacturing are probably using ‘Lean’. That feels too limited for your team, because ‘Lean’ basically eliminates waste in established processes. And what your team aims to do is to replace established processes. You have heard about ‘Agile’ for product development in IT, but unfortunately, you don’t see how to work with 2-weeks sprint (adopted from ‘Scrum’): hardware isn’t delivered every 2 weeks by your suppliers. So although you acknowledge there is value in ‘Lean’ and in ‘Agile’, neither seems to work for you.
The solution is to go back to the leading principles underlying both ‘Lean’ and ‘Agile’ and develop practices that suit your context. Obviously, that is a lot harder than just adopting a standard framework. Doing this without support from experienced coaches or consultants will be tough. And there is another problem too: by far the most coaches or consultants can’t help you in this case (they probably claim differently): they have no or limited experience in a variety of context (e.g. IT and manufacturing) and because of their own education, they don’t fully understand the underlying principles of the various frameworks. Indeed, very few people are knowledgeable about ‘Lean’, ‘Six Sigma’ and ‘Agile’. And some organisations might benefit from something different, such as Business Process Management or Stage Gate project management (yes, a specific application of the more traditional ‘waterfall’ project management. In some circumstances that simply works better than ‘Agile’) or Sociocracy.
Here are a couple of elements you could check when selecting the right coach or consultant:
- Check on their resume whether they have truly worked in a variety of contexts.
- Check on their resume how they have been trained (getting a certificate is very easy and a good starting point, but without coaching from other experienced coaches or consultants, you won’t get far).
- If they claim “this is how it should be done!” they have fallen prey to the ‘Law of Instruments’ (If you have a hammer, everything is a nail).
- If they cannot name an alternative approach, they are following a recipe: they follow the steps of their favourite framework, without fully understanding the underlying principles.
Alas, it might be hard to find a suitable professional. And I can’t guarantee I would be your perfect guide. That said, I might be able – with limited investment – to point you in a direction that might get you out of the struggle. The result of that collaboration might be that you are a step closer to select the right guide for your context and challenges.
Hence, don’t hesitate to contact us for a free introduction conversation.
You might also be interested in an e-book that explains how to use best practices to boost productivity & well-being.
Related blogs
ScrumFit: is Scrum right for us?
Pingback: Finding a balanced way of working in HR - Ithaki
Pingback: Ain't common sense enough? - Ithaki
Pingback: Selecting your Project Management approach - Ithaki