Lost In Translation
In my blog ‘We’re moving to Agile…’ I mentioned a few Agile specific terms which are commonly used and have specific meanings. When a business is transitioning to a new methodology such as Agile the new terminology which is part of it can provide a completely new opportunity for misunderstanding if not carefully managed.
During transformations it’s very easy for new terms to be used in meetings on the assumptions that everyone taking part knows what they mean and that everyone has the same understanding of what they mean - which isn’t always the case. Quite often, if someone isn’t clear what a term means they may try to work it out rather than ask.
More important than the obvious question ‘What does it mean?’ is the question ‘what does it mean for me?’. This cuts right to the heart of how applying a new methodology will impact the day to day work that someone does, and how misunderstanding it can create unexpected problems.
This is great example of why I think that ‘Educating The Team’ mentioned in my blog ‘Smoothing the Path to Agile’ is so important.
What does this matter in the real world? Let’s take Minimum Viable Product (MVP) as an example. This term has a number of colloquial meanings, all of which are slightly different. For a developer, it typically means basic functionality that meets the primary use cases. It is unlikely to be of production quality. For an operational support engineer, it normally means an operationally supportable release (regardless of the functionality). For a customer, it often means a functionally complete product that is of production quality that lacks some of the ‘nice to have’ features. (None of these are the Agile definition of MVP in case you were wondering.)
When Development think they’ve delivered the MVP, Operations think it isn’t fit for production release because it’s missing support requirements, and the customer thinks features are missing, frustration begins very quickly. In the worst case, this can lead to a loss of respect and confidence in the ability of teams (or even your business) to deliver.
If the meaning of ‘MVP’ had been clearly defined and communicated across the product lifecycle this misunderstanding would have been avoided.
Methodologies help avoid these misunderstandings by providing a common language, but when the language is new it needs to be defined for everyone involved. To make things as easy as possible, I recommend using standard definitions where possible. Changing them is likely to create confusion, reduce the effectiveness of any training being provided, and make the transition harder. If you do need to change it, make sure the difference is very clearly communicated across the business teams involved.
The situation described above is due to misunderstandings about the meaning of an Agile term. If we take this a step further, and think about terms which are used across methodologies or also have day to day meanings the situation can be even more confusing. (Think about ITIL incidents, project issues, change control and change management, Product Managers and Product Owners, and the interchangeable use of Project Sponsor / Project Executive / Senior Responsible Officer.)
By being methodology agnostic, Pragmatist Consulting can help you overcome challenges like these to more effectively transition and, importantly, successfully integrate, new methodologies into your existing business operations. Doing this will help you better achieve the benefits you expected whilst shortening the transition period. Contact us to discuss your challenge and find out how we can help you.
Pragmatist Consulting provides a pragmatic, emotionally intelligent business and change consultancy service which we tailor to fit your need. We focus on helping you turn your business problem into a success story.
30 March 2020