Part of my usual lunch time routine at work is to get myself some distance from my pc. I’m not a big fan of eating at my desk, and not really leaving work to one side for a small while. Many people underestimate the value of making that break, getting your head out of what business problem troubles you, refreshing, and coming back with a clearer state of mind. This morning, I had a brief, but interesting, discussion with two of my team mates. I thought it interesting enough to share.
Some background. We are delivering an enhancement to several of our clients. The project has been interesting for me for a number of reasons. This is the first project I have spent with this team. The first sprint was kicking off as I moved over from the team I had been working with. At that point my new team was agile only by company description, it’s actually the reason I was asked to join the team. We are a much improved team some 10 weeks later. Still a way to go but good signs that we are travelling in the right direction.
During early testing of the enhancement both the team BA and myself, almost at the same time, noticed that a piece of legacy functionality, when used in context of the new function, was not really correct. The initial response “The clients know this and are OK with it”. We thought that there was value in making the change, the data being reported was not right in some scenarios, but placed it low on the product backlog as we had plenty to do and if the clients weren’t chasing the change then the value proposition wasn’t massively strong (and one could ask why we wanted to add it to the backlog at all). As it turned out, funnily enough, one of clients did want the report changed, we, apparently misunderstood a business requirement. It should have been there all along. At least that added gravitas to the story being in the backlog.
I guess at this point I could talk about how something we thought might be easy, turned out not to be, but then turned out to again seem pretty easy to achieve (all because we were thinking and learning as we went and not committing big design plans up front – another blog some other time). However my intent was to talk about a conversation…….. So, this report can be produced in two ways (probably more if we wanted to be really inventive but that would likely accrue cost well above value). The conversation went something like this:
BA: I think we need to make the changes via “X”. We could do it via “Y” but that would mean we have to retest a lot of stuff.
Me: Do we know for sure there is a lot of risk making the required changes in “Y”? We’ve only just started with “X” so we know the risk is low, and especially so because of the way we retrieve the data”
BA: Haven’t confirmed it, but we have done a lot of testing so changing “Y” becomes risky. A lot of retesting.
Me: If you were the client does the report gives you greatest value when it is part of “X” or part of “Y”?
BA: “Y”
PO: “Y”
Me: Yep, I think the same thing. How about we talk to the developer and get an understanding of the risk profile. We should focus on delivering the highest value. We could even raise this with our clients. They might not actually want the report in “X”, although I strongly suspect they will. We can consider the full implication of our choice once we get some more information.
Pretty much end of discussion ( at least any bits I want to put in here).
There are a couple of points that stood out for me in this conversation:
1. even though the highest value proposition was thought to be “Y” it was not assigned “best option” by default
2. perceived, rather than known or analysed, risk was allowed to influence a value choice and move us away from “Y” (preferred) to “X”
How often, at work and outside of work, do we make choices and go for the safer option rather than grabbing an understanding of the risks involved with our preferred option? An option is preferred for a reason, we perceive that it will deliver greater joy, the quality of our experience will be higher. When we go the lesser preferred route we run a real risk of undervaluing potential joy and satisfaction, interactions that will feed into an assessment of quality. My suggestion, remove those assumptions, question them into knowns, get them to a level where we can make informed decisions. Once you have done that select the option that will deliver the highest level of delight.
Regards
Paul
@Beaglesays 
Hi Paul,
thanks for the article, nicely written, I recognise similar situations.
You wrote “An option is preferred for a reason, we perceive that it will deliver greater joy, the quality of our experience will be higher.”
My question would be “for whom”?
Doing everything to delight the customer is the done thing. Some people pay lip service, others mean it. In a customer/supplier relationship there’s two opposing interests though that is often ignored – one wants to receive as much money as possible, the other wants to get as much as possible with spending the least amount of money they can get away with. There are situations, i.e. charity where this is not the case but mostly this is the situation we start with.
Recognising the starting point makes it clear that project teams often value the supplier interests as high if not higher than the customers interests. The disparity between expectations is where the problems occur.
Do I disagree with your point? No, but giving a possible explanation.
Thanks,
Thomas
LikeLike
Hi Thomas,
thanks for the kind words and leaving some comments – appreciated. The “for whom” question you raise is interesting. I had a quick re-read of my article and while I said “we” it almost feels like I could equally be saying “I”. The switch to a first person perspective was not intended, or intended to be implied, it would be counter the idea of making value decisions as a group. Now part of that group should be the client. The client is really the “for whom” but there is quite often distance between the true client and the software development. The Product Owner may in fact be an interpreter of requirements and thus flavoring the client value proposition with their own value thoughts. I think it is valid to ask the question if we are delivering client value or our perception of it. If we are delivering our perception, not validated by our client, are we better off under agile?
Regards
Paul
LikeLike
Hi Paul,
thanks for the answer. To (at least partly) get around the problem of our perception of client value is to have developers or testers speak directly to clients, ideally to someone who is going to use the software later on, i.e. not the Project Managers but the end users.
My point goes in a slightly different direction though. If you were to put on a diagram the developer, PM, Product Manager, CEO (or other senior manager) plus the client (that the software is delivered to) you’ll see that there is more than one relationship line.
For example for a tester or developer the direct client would be a Project Manager (role) with a dotted line to an external customer representative. That we call an external customer a client as well only confuse matters.
In this scenario the PM may have other requirements (budget constraints, internal policies, etc) than the customer, thus my question “for whom?”. If the team goes for option X our stock value may go up delighting the internal client, conversely option Y may delight the external customer.
My point is, who is the person that matters (most) and how does it influence my and the teams decision? If it’s not one person how does that influence our thinking?
LikeLike