A peek into developers mind on the edge of Agile Business Transformation.
Foreword
This is an article Bartosz wrote 7 years ago when going through Agile transformation at eBay Classifieds. This gives you a peek into a mind of a developer on an Agile journey, trying to understand where to go further from a fairly optimised dev environment. Make sure to read a response from Tatiana from around the same time to understand dynamic of development vs. business turning into real Agile product teams.
Have you ever wondered how much crap you produce everyday?
And I don’t mean physical waste – I mean unusable features? Seriously, think about it – how often have you said ‘yes’ to a request, which made no sense to you? I bet a lot. Imagine where you would be if you didn’t build all these things? And on a global scale – where would the human race be if we didn’t build every ridiculous thing people want from us? Hint – I should be writing this on my iPad Air (because it’s made of air, not because it’s thin), using my thoughts, while sitting in a space shuttle heading for the eBay HQ on Mars. There you go.
You are a sum of your assumptions
Ridiculous requests you say? Well, the reason is fairly simple. It’s pure math really. You have your project and you always have that person saying we should build this and that. And you listen, and you trust the person makes sense. In non-Agile world these people are called something like Business Analyst, in Agile (Scrum) world – Product Owner, and in all worlds – stakeholders (or, as I learned recently, there exists a special kind – HiPPOs – Highest Paid Person in Organization). But the way we devs translate and see these people is simply the one who knows sh**t we need to build. We assume they’re walking, talking domain encyclopedia, believing everything they say. Hey, why not? They trust us with the keyboard, don’t they? And what is it about if not trust? You have also this second type – the one who knows sh**t. period. Well, you don’t trust them, but they’re beyond point of salvation, so you just keep on building what they tell you, to be able to watch them fall and crumble under the weight of their own mistakes. We devs are like that – we’re cool, we know better, but we keep our mouths shut.
But in all seriousness – we all assume our positions in companies and every time I ask business or devs to draw a simplified picture of their structure, they end up with this:
whereas you would actually like to see this:
The solution
Ok. So you find yourself in the first picture, or you feel your product -ers are not doing their job well. What do you do? Well, we devs have one thing in common – we love algorithms. Wish there was one for this. Wait! There is! Before I reveal it for posterity to build me a space shuttle, let me give you a context of what triggered me to come up with this in first place.
The story
It’s a story of a button. So it happened one day that my fellow dev (for the purpose of this story we will call him Mr. W) came to me with a question about part of the system, that I know a bit better. (Disclaimer for Mr.W – the following lines may differ from your experience, duh! I’m trying to make a point here!) The request he received from one of our Product Managers was to change a label of a button from A to B if in the next step user would have to pay (in devish: if (userHasToPay) B else A). It triggered a lava of questions from my side, starting with why? (actually the first was wtf?, but that’s how I respond to most of things). I explained how the possible implementation of userHasToPay was tricky, that the rules would have to be duplicated outside of the business service or refactored to a shared logic, and implementing it in only one of our frontends would be confusing for the user. So for me it was a no. For Mr. W – a conditional no – he would have to check with the PM.
Write this down:
the ability to say no is proportional to a distance from a person you’re saying no to.
After a while he came back asking me to list all my reasons again, because when confronted with the request again, he simply forgot. When I repeated it, there was a follow up question waiting:
– ‘What’s your secret?’ – ‘Wtf?’ – ‘I mean, how do you come to such clear conclusions?’ – ‘Well, I’m just awesome’ – another of my standard responses.
The solution (continued)
Actually it was a very good question. I never thought about it, but after years of dealing with requests I actually set up a subconscious algorithm (imagine red, terminator-style HUD display dealing with requests). And it goes something like this (continue reading for example conversations):
Someone has a 'problem'.
- Sir/Madam – is it a problem or an idea (for improvement)? - A problem. - How do you know it’s a problem? - It bothers me. - Go to 1.
Metrics stable? Users happy? Yes? Ok, let’s try again.
- Sir/Madam – is it a problem or an idea (for improvement)? - An idea. - What do you want to achieve? - I want a different color. - Go to 1.
And I want to be somewhere else right now. I’m sorry, but we can’t have both. Let’s try again.
- Sir/Madam – is it a problem or an idea (for improvement)? - An idea. - What do you want to achieve? - I want better usability for the users. - How will you measure that it works? - Oh I will know.
What a coincidence! I already know it doesn’t! Again?
And now for the scenarios that would make me start to consider solutions for the request...
Happy scenario A - Sir/Madam – is it a problem or an idea (for improvement)? - A problem. - How do you know it’s a problem? - Users are complaining. - Let’s take a look.
I would also accept – Metrics are going down or simply running around shouting – We’re loosing money!
Happy scenario B - Sir/Madam – is it a problem or an idea (for improvement)? - An idea. - What do you want to achieve? - I want better usability for the users. - How will you measure that it works? - The finish rate for the flow will go up. - Let’s take a look.
Life after conditional 'yes'
But it’s far from over. Now comes the hard part. Saying no is easy (now that you know how), but saying Let’s take a look requires some attention to detail. First – you need to figure out what kind of effort are we talking about. Secondly agree on the value gained from fulfilling the request. But one thing that is many times overlooked is what I call sacrifices. Effort is one time thing and mostly easy to estimate (+-50%). But there is always a long-term impact on your system. Remember the button example? If we do it quick and dirty – the effort is small, but we need to consider sacrifice of having business logic spread around and impact it may have on the next generation of devs coming into this uncharted territory (that means any dev coming back to their own code after a long weekend). If, however, we try to minimize the sacrifices, the effort goes up. The end step is to balance effort, gain and sacrifices in a way you can say no with pure heart (you can say yes from time to time as well – that’s what you’re being paid for).
Catchy summary
Think backwards – imagine that you have succeeded or failed and understand what it means (hint: metrics) before you even start talking about solutions.
Expect that especially from the person who is making the request.
Anything less is just an opinion and you’re always entitled to your own.
Comments