From Loaded Labels to Basic Principles. Why we reject overused jargon and keep it real.

February 01, 2021

Down arrow black
to make it up I can let you dunk over me

Jim.

Operations Director


At Reason, we’re regularly asked to deliver complex, systematic changes into large organisations; and this can be fraught with difficulty. We've learned that it's often not the design and technical challenges that present the biggest problem - those we have the capabilities and experience to handle. The issue more often lies in the realisation that despite multiple meetings and planning sessions, we're united as a project team with clients, but separated by a common language of delivery.

Here we’ll dissect some misnomers and share Reason's approach to debunking the jargon of labels and methodologies. The recommendation is alignment around principles using common language all gathered from leading ways of working. This is how we successfully guide our clients through the delivery journey.

Labels: Useful but dangerous

Labels allow dangerous mis-alignment. The easiest example in digital is the term “MVP” or Minimum Viable Product.

What does it mean:

  • for a client “MVP” suggests “That sounds like everything I need to do my job great”
  • And for a digital product specialist.. “That sounds like the bare minimum we need, to validate this product has some value to customers”.

This creates a chasm of difference in expectations from the outset. They’re rarely bridged well, if at all.

The preconceptions around MVP are deep rooted. Everyone believes they understand the term. Instead, a clearer option is “Release 1”. This has no implications and it’s not an evocative term, but there still might be a preconception. There is a follow on conversation to decide on the best scope to deliver in a Release 1. No one can mind read and until there is a clear written list of what is and isn’t included, there will be misalignment.

Labels: Academic but pretentious

What does a term like Cynefin do for anyone? Why not just describe what it is: a way to model and understand complexity. This understanding aids conversations to triage a project into the most appropriate and effectively designed capability to respond to the challenge set. Simple, complicated, complex and chaotic projects should be treated and approached differently.

If people understand the word Cynefin, there’s another challenge to pronounce it. It’s too academic. Use plain english and explain the principle instead.

Remove labels and move to principles to help success.

What do Kanban, Scrum, Lean, Extreme Programming, Waterfall all mean to people? They are loaded labels where everyone brings their own superficial understanding and at times prejudice.

We need to get back to, and stick to the principles. Talk about them and align around them. Get away from the labels.

How has Reason done this?

We align on principles during kick-off workshops and project planning events. We bring a starting set of principles to the meeting and explore together as one team with the client what is needed for success on the project.

Why should I consider this?

The short answer is the quality of outcome. Aligning on principles allows better conversations and results that drive the value & outcomes your digital product work is aiming to achieve. Once the project constraints & contexts are understood, then aligning on principles drives the best capability and outcomes matching that need.

All projects are not driven by the same needs, so how can any one label be the answer?

Constraints & Contexts

At Reason, our first “Release 1” deliveries often prioritise time to market & cost control. This isn’t always the case; our Levi’s work to transform their wholesale sales process via an interactive digital showroom has quality & robustness as the key driver. And therefore our delivery principles will be applied differently.

At Reason some of the principles we focus on in our product teams are:

“Keeping the work busy” not “Keeping people busy” (from Kanban)

If you have too much work in progress, you end up becoming helpless to the context changes and everything slows down. It’s better to focus on having less in flight and completing it to high quality. What we need to do is visualise the work to be done and manage the work. If we don’t visualise the work, we end up managing what we do see, the people. Not so helpful.

Visualise the work to be done as a path to bring clarity & solve chaos, and ultimately prioritise well (from Kanban)

If the idea of visualising all the work to be done alarms you, that’s a sign that you’re doing too much. This technique also has the benefits of aiding prioritisation and getting the team to make better decisions faster. The "shine a light on it" metaphor can be take literally — it will help!

Protecting the product team from stakeholder interference and changing priorities within a sprint (from Scrum)

The designers and engineers need time to get on with the work, time to focus. It’s too easy for endless analysis & review meetings to kill the speed of output from the team. A good technical product manager can field most answers from stakeholders and let the team get on with their work.

Ensuring at the start of a project we map out dependencies and have an understanding of what a first release might look like, realistically (from Waterfall)

It’s a common misconception that Agile processes are there to save money. Agile is more about the quality of outcome and working in iterations of validation to break down uncertainty. Fixed budget envelopes are common for some projects, and the only way to achieve confidence that success will be achieved in that envelope is to plan the project out in detail.

Focus on documentation as a key pillar of success (from Waterfall)

For business critical systems, how will we know if the system is performing to specification and satisfying the users? Professional quality assurance requires documentation of the product. On some of our projects this might form a functional specification. For our client Symphony this has involved Behaviour-Driven-Development, where the business representative, engineer, designer, will all co-create and align on a human readable description of the user flows throughout the system. We can then automate testing against this specification for absolute confidence these trade bot systems are fit for purpose.

Focus on building pipelines at the start of a project, and build automation. “How long until we can get single pixel through to production” (from Extreme Programming)

Procurement of environments, building pipelines: this integration work is inherently risky in terms of unforeseen integration issues. Prove as soon as possible that you can release a single pixel (or small piece of data) all the way through to a production environment as early as possible. This is a huge proof point and very healthy as underwhelming as it may sound.

Avoid pushing work around and instead pull work (from Lean & Kanban)

Imagine this situation: A frustrated engineering team says “the user research & design team never gives us a complete specification - they need to hand us better specifications”. Generally this ends in a stalemate. The engineering team waits for the design team to solve for this and nothing happens. Better: have the engineering team “pull” the requirements from the user research and design team in a meeting. From this flip in approach, work is only done when it’s needed and the whole system becomes more efficient, while everyone gets what they need.

And more:

  • Remove or reduce waste (from Lean)
  • Eliminate process defects through root cause analysis (from Six Sigma)
  • Favouring individuals and interactions over processes and tools (from Agile)
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (from Agile)

Straight from the Agile manifesto. A relentless focus on the outcome and value our customers seek is why we exist.

How do we triage the needs of digital towards the right capability?

Start with a discovery workshop to get out of people’s heads and into the world:

  • the nuances of objectives, contexts & constraints,
  • alignment on the root problem we are solving for

And then together as one team we ascertain which principles ring true for being the best approach to achieve the outcome.

Any particular methodology is never the goal. The achievement of the desired outcome for the business is the goal.

Please contact us if you have any digital ambitions or challenges, we’d love to help you succeed in the right way for your business.