How I passed Scrum.org’s PAL-EBM certification

  • Empiricism is all about gaining knowledge from experience and making the right decisions based on what you see. It helps you to take meaningful steps to deal with complex problems. Those problems can be anything we encounter — different types of risk, new technologies, changing markets and more.
  • Remember what you need to apply an empirical approach: it’s about forming a hypothesis, running an experiment, validating that hypothesis and then repeating. You don’t know whether something is true until it is released and validated by your customer.
  • A product backlog item (PBI) is then just a hypothesis. It’ll be at the top of a backlog because somewhere in your process you’ve decided it’s valuable. However, you’ll only confirm if a PBI is valuable after you release it in the market.
  • So in that spirit, release often! Even in cases where it’s only to improve a product’s performance to release a tiny feature. Or if you have thin development resources and the team needs to release and move onto something else. Releasing often will give you faster insights to make the right decisions on how to drive value.
  • If you have to make any choice about when to release, always choose the fastest option — even if that means releasing less each time.
  • Experiment and then experiment again! Running experiments will help you gather insights into how to tap into unrealised value or understand how to close satisfaction gaps. Learn from those insights and plan your next step.
  • As discussed already, you can release small parts of a feature rather than the whole to experiment and gain insights if that means you release value to your customers sooner.
  • Defining measurements is preferred, but not essential. You can experiment and see where it takes you. Remember empiricism: knowledge comes from experience and making decisions on what is observed.
  • If you’re familiar with Kanban ways of working and the PSK accreditation, limiting work in progress and creating a clear focus will increase flow. That will lead to improved cycle time and, hopefully, more value as you will release value to your customers sooner. Though remember, more output doesn’t necessarily equal good outcomes for your customers.
  • Therefore focus on outcomes for your customers. Other metrics around activities or outputs are important, though secondary. If you’re not delivering value for our customers first, you’ve missed the purpose of EBM.
  • The role of management is to set clear goals and measure for the organisation.
  • SMART objectives are not smart in EBM — at least the majority of them aren’t! We only want goals which are specific and measurable; otherwise, they’ll be nebulous. We won’t know what is assignable/attainable or realistic in a complex world until we start experimenting. As for timescales, the bigger the goal, the less is known about it. We won’t know when we will achieve that goal, if at all. SMART goals limit an organisation’s strategic horizon and cut against what EBM is trying to achieve.
  • Putting in place rigid structures like annual planning or budget cycles will hurt an organisation’s ability to respond quickly. Avoid them.
  • The goals of the organisation are the responsibility of everyone — not just management. Don’t break them up for different levels of the organisation. We’re all equal stakeholders in our quest for customer value.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Agile Alex

Agile Alex

10 Followers

Hello! I’m Alex, a product manager based in the UK. This is my blog about product and agile.