Posts Tagged ‘Value’

Learning

There are three major types of learning:

  1. Learning through association – Classical Conditioning
  2. Learning through consequences – Operant Conditioning
  3. Learning through observation – Modeling/Observational Learning

This article is focusing around No2 (learning through consequences) and the reason for focusing on this is because it’s so popular for fellow work colleagues across any business to recognise a problem / something not getting done and the consequences of not solving / doing it, that they just get stuck in and solve it themselves because they’re passionate about the business they work for instead of leaving it for the person whose responsibility it is to solve the problem / complete the task with risk that it’ll likely not get done.

Now, many people would say that’s brilliant team work and a fantastic ‘One Team’ attitude, but actually the action of solving someone else’s problem / completing a task for them is stopping the actual person whose responsibility it is to do it from learning. Also there’s the point about the person should be doing what they’re paid to do, but most importantly unless people experience the consequences of not doing elements of their job, then they’re simply not going to learn the importance of doing that element of the job and that they need to perhaps adjust their processes or admin to ensure they take control of their responsibilities in future.

Like I said at the start, if you’re passionate about delivering value for the business then it’s certainly not easy to avoid getting stuck in and it’s hard to avoid reminding people to do their job, but if you want to achieve the goal of the person who should be solving the problem or doing the task actually does it as expected in future, then the only way this will happen in the long run is by that person recognising the consequences of it not being done, so then they can avoid leaving it in future.

There will naturally be times when someone is clearly over worked and can do with a hand and that’s where you could come in to help, but if it’s someone close by spending most of their time surfing the net or playing ping pong in the games room, then you need to take a step back, try and ignore the problem not getting solved allowing them to deal with it however they feel is effective, but what is for certain is that problems / processes don’t normally get done on their own.

Greener

There will always be an endless list of all kinds of problems for a business to solve and it’s how people come together to solve the problems which accelerates the execution of viable solutions and positive changes.

Some problems will be easier to solve than others, there will be a multitude of lengthy conversations about how to solve certain problems and there will be various opinions on the value of the problem to solve, but it’s important to respect the person responsible (and accountable) for solving the particular problem and rather than moan about things not being solved / done how you’d expect, then use influence, positivity and collaboration instead to see how things could look from a different perspective, because ultimately everyone’s heading for the same goal and would be passionate to solve problems in the most effective way.

It’s also not easy to ignore a process which you seem to have various problems with especially when it’s not a priority to solve for the person who’s responsibility it is making you feel frustrated, but you could try rewiring your brain to obsess about problems which are within your remit to solve or contribute to solving instead and when asked by senior management “what improvements do you think we can make outside of your remit?” then you’re totally within your right to give an honest answer along with what you’ve tried to do to help.

Before you jump ship because you think the grass is greener, have you thought about:

  1. Collaborating on the solution with the person directly whose responsibility it is to solve the problem in a positive way – you never know, the person who’s responsibility it is to handle the process with the particular problem at hand could do with your observations or opinion on how to overcome the problems they’re facing
  2. Obsessing about solving problems which you’re responsible for and reviewing whether you’re fulfilling all of your R&R, as not solving your own problems could have a direct impact on other areas trying to solve their own problems
  3. Discussing openly with your line manager about how they think you could help contribute to solving the problem
  4. Is it a valuable problem to solve relative to other problems across the business
  5. Listing out all of the positive and good things about the company
  6. How lucky you actually are
  7. Making more conversations
  8. How much autonomy you already have to make big changes

When you get approached with an attractive offer by a recruiter or are fed up of certain problems not being solved, have a real think about how you’ve made an effort to help solve the problem by collaborating, because you may find the same problems if not more might exist on the other side of the fence, resulting in being in the same position in six months time with your new company.

Heart beat

In order to get an idea (problem) to a customer (solution) there can be as many as 5-8 different levels / key roles to play from Developer to Product Owner and to get the idea delivered in an efficient and effective way, it’s important that everyone plays their part and gets stuck in.

One way of ensuring that you’re delivering real value by playing a part in the idea to customer flow is by providing regular heartbeat updates to your peers and stakeholders.

Dependent on the role you play, will depend on the type of heartbeat update you’d send out:

  • Developers – all that’s required from a developer (or QA) is to update the agile software tool eg. JIRA on a daily basis which will automate any type of report eg. Sprint burndowns, sprint delivery report for the Scrum Master and Product Owner
  • Scrum Master / Team Lead – fortnightly release update on in flight product iterations (epics), risks to delivery and mitigations to be sent to peers, Development Manager and Product Owner
  • Development Manager – monthly update on delivery efficiency improvements, development recruitment and strategy to deliver upcoming product iterations to be sent to peers, Product Owner, Technical Architect and head of development
  • Technical Architect – monthly update on technical architecture solutions for upcoming product iterations and quarterly presentation on architecture vision to Stakeholders, Development Teams, Product Owner and head of department
  • Product Owner – fortnightly sprint review and sprint goals report, bi-monthly update on what product iterations are up next with a product roadmap update and finally a quarterly presentation on what value has been delivered, what’s up next and an update on the product vision. The majority of updates to Stakeholders, Development Teams, Technical Architect, Directors, CTO and head of development

Once you’ve mastered the format of your updates, actually changing the content shouldn’t take long at all, so it’s easy to send out your heartbeat updates on time, but by not sending out any updates could easily give the indication that you’re a passenger on the idea to customer flow.

Problem solving image

There will never be a lack of problems to solve when it comes to product development, but handling the relentless amount of ideas and identifying the right ones to focus on can be tricky if a robust process to prioritise and track all of these is not in place.

There are many approaches you can take to handle problems and prioritisation, some product management videos I’ve seen describe the product owner to spend most of their time saying ‘NO’ to stakeholders which I tend to disagree with, because technically all problems can be solved and an idea is never a bad idea, but perhaps it just can’t be solved right now due to higher priority work, so a response to show appreciation for raising the idea / problem and that it’ll go through the prioritisation process is a more appropriate response. Some also handle prioritisation and requests by who shouts and flaps the loudest which is equally not the way to go about effective backlog prioritisation.

Two things you need in order to prioritise effectively 1. Value and 2. Effort to work out the projected ROI. Before you even spend effort discussing how much effort a problem will take to solve, the first thing which should be asked when someone approaches you with a problem, idea or bug is “what is the value?”. As a result of this, you may get:

  • A sheepish response where they don’t know, so they’ll have to go and find out (in some cases resulting in the problem being so small it’s not worth solving it, so you don’t get to hear about the problem anymore)
  • Value provided is minimal (relative to everything else in the backlog)
  • A fluffy response eg. It’ll increase traffic, it’ll increase retention rates etc, with no given metric
  • A significant problem / idea to solve which could deliver vast amounts of incremental revenue, benefits to customers or savings through efficiencies which should be fast tracked through the effort sizing and prioritisation process

Another question which can be asked to identify value is “what happens if we don’t do it for 3 months, 6 months or never” which will aid prioritisation further.

At your disposal you should have a data visualisation tool to easily view trend data and access KPIs for your products and features which is another way of identifying value for yourself, but ensuring that you and your Scrum teams are working to solve the highest value problems is fundamental in achieving a healthy ROI and successful product, so by asking just some simple questions up front will make your journey a lot more palatable.

Context switching

There’s never just one thing you could do, not just a few things, but there could be hundreds of things you could possibly do to deliver value, so by being reactional with a ‘just get it done’ attitude could result in little progress towards delivering overall business goals and lead to a few frustrated developers.

Product development isn’t as quick as setting up a new programmatic ad campaign for example and instead can take weeks to carefully craft a solution collaborating with colleagues along the way. Also with development costs not being cheap means that not making a sensible decision up front could be costly.

Context switching can impact a variety of key elements:

  • Waste – it can take hours / days for a developer to jump from one project to the next especially if they’re unrelated and the code is complex. There’s also risk that some of the learnings from the original task would be lost even if documented.
  • Morale – one of the most frustrating things for a developer is context switching either by switching in progress work or frequent disruptions. Developers take pride in doing a high quality job and to do that takes detailed technical planning to ensure they do the job well, so pulling the rug beneath them often ends in frustration. Typically they just want to get a job they’ve started on done and see the fruits of it.
  • Delivering value frequently – adapting to change quickly is important, but you may find changing a strategy often results in delivering very little.
  • Prioritisation – expecting a product owner or someone in a strategic position to juggle a significant amount of projects at once will end in the highest priority work not necessarily getting done, because it takes time to groom and value projects / requests, so if there’s less time to do this, work could be prioritised based on who shouts the loudest.

Context switching can negatively impact anyone across the majority of an organisation and is often caused by unnecessary flapping / panicking, but with a robust and strict new request process and well oiled live bug process can not only keep context switching to a minimum, but also ensure that teams are working on the highest priority item delivering value frequently to customers.