If you didn't read the first part go there and read so you get some context.
So to know what to do next and in which order to execute, you will have to know how much value and effort takes each of the goals you want to achieve. After you have this clear you can classify them in 4 groups and this method also helps you to prioritize tasks. Identify for your business what are the most valuable things that you can do without complicating things too much.
High value / low effort
Quick wins, but don't confuse them with "quick & dirty" solutions. Quick wins are well developed, tested, consistent with the current architecture and simple modifications that you can apply and get a lot of benefit from. They don't introduce a lot of complexity but will give you a lot of value. This are the first tasks you need to attack.
What doesn't classify here?: a hack. If your quick solution, creates a problem for later, even if it looks like low effort execution now, i twill complicate things in the future, and when this "hacks" accumulate they will come for you in the more inadequate moment and hit you where it hurts the most.
High value / high effort
As this game is not always about taking the low hanging fruit. There will be complex features that will introduce complexity and need a lot of time to complete because they need to get done A, B, C, D and E. But they are business critical, and you have to get them it doesn't matter what. How to work on this ones? How to deal with them?
My advice, is evaluate if you really need the to go that path. Be careful, do your clients will really benefit from this features? are those existing clients and you need this to keep them? or are those "imaginary clients"? Existing clients are usually more valuable than potential or imaginary clients. Don't go into this kind of tasks because the sales team is pushing you, or the CEO came with a great idea, or whatever else... Use as much factual data as you can to decide if you really need to execute this.
But if you really need this task done don't lay down a 3 month plan or something like that. Specially because complex tasks have a high level of uncertainty and you have no clue on how to estimate them and you don't have a clue on how to do whole trip to the end. So, select the simplest and more independent thing that the team can work that will lead you in the goal direction. If you have clear intermediate milestones well, good for you... but sometimes I personally had not, I knew what I wanted at the end but was not until I started working that I was able to identify what was the next step to slowly climb to the top. So, if you don't have everything clear, that's fine, just keep an open mind in case you have to abandon or change path on the way there.
Very important for me is that this tiny milestones can be deployed to production when they are completed even if they don't make too much sense by themselves alone and that they are small, sometimes just a few hours of time, a day or two. But having something in production quickly gives you immediate feedback and that's very important to change course if you have to.
In this case I don't do any kind of estimates, because long tasks will be interrupted by smaller ones that will be interleaved, because you can't stop time and work for 3 weeks in a bubble; things will happen and that's fine. So, if your boss asks, just be sincere: You have no clue, but you will work towards the goal until completion, and you have this clear milestones, and you should have at least something small to show soon. I had done this, some people don't like it, but I prefer not to lie and pretend to be a know-it-all.
Low value / low effort
This tasks usually are not part of the critical path towards success. But are nice to have. My advice is to use them for people joining the team. Is very nice to come to a new job and that same day get something out in production. Also they are good for training interns or mentoring junior developers or keep a senior engineer from being bored or tired of working in big stuff. This kind of tasks are usually refreshing to do. So this ones are not a big deal.
Low value / high effort
Just don't! No, no, no... Don't! Even if someone tells you that is very nice to have, if you know that the cost is way higher than the benefit just don't... This tasks have overall negative impact. It is preferable to have a simple system than a complex one, it will make you fast, have a happy team, reliable software.
Wrapping up
Keep in mind every time you make a commitment your boss will hold to it and will come for it later. So, try not to make many commitments... just work and deliver valuable chunks of work, always open to the needs of the organization and the business. If you are not lazy you will achieve what you want, it just takes time to build things in the right way and make the process sustainable so there is a tomorrow after you complete a goal.
Remember that working producing software is a very very long way, you will have to maintain that software probably until no one uses it. So is not a race, is not sprints (specially not the SCRUM ones), is a marathon. Your software needs to adapt and be flexible. Don't let someone that doesn't work in your code base push you to screw it up, or negotiate with you and your team time with your family and friends, your nights and your life.
Keep it cool!
Oldest comments (9)
Great point you have here. I just read the first part as well and I have to say I agree with you. It is important to be a professional, set you own quality bar and keep it. Usually it looks like a negotiation with our team, although it is never about quality. The quality is set, we can change features, make the iterations smaller, or implement them differently, but the quality stays.
Effort is the one think that seems easy / easier to measure, that's what estimates are for. Yes they can be wrong, but a team should be getting better at this with time, so they should be better and better. The value still seems an abstract to me and will always have some kind of gut feeling part to it.
But keep in mind, the quality you make isn't just for your boss, it is your responsibility as professional software engineer!
When I talk about value it is, for example... if save 70% of operational time because you automate something. That has value. If you make the sign up process, or complain process easier that has value. If you add monitoring to something in your system or infrastructure that has value. You just need to evaluate that value against effort and see if it worth it.
Totally! If we were doctors, and we don't wash our hands, give pills without a diagnostic... or crazy things we would loose our license. Should be the same for us.
Saving time is one of the easiest values to out against the effort. If you are talking about the other stuff it gets hard for me.
Speeding up the sign up process will make it easier. But how many people don't sign up because of this, how many extra people will sign up. And even if you can predict that, how much money will they make you, are these the same users as you now have or will they behave differently?
Speeding up the complaint process will increase service, but how many people leave because of this? How many money will this bring you in the end?
Adding monitoring will reduce the impact of downtime and maybe even prevent it. But how many people would you loose because of the downtime, how much money would that cost you?
A lot of the things give a feeling for value, but I find it hard to put them into actual numbers to make decisions on them. Luckily our projects have a more predictable clientele, but I'd really love to hear how more public sites estimate these values.
You are right, sometimes we just try things and see what works. But if you have some data to take that decision use it...
I'm a little bit biased here because the software I make I have people at less than 50m that use it. So, sometimes I just walk around I see they are trying a workaround to do something, I ask them... but what if you could do that like this, if they like it I think about implementing it for them... I have it easy there... :P
Having the users close by can make it a lot easier to find these things. I'm rather interested, do you have any formal way of getting feedback from them? Have you tried getting to a point where they report it themselves when they are using workarounds, so do their own feature requests?
Aside form the informal one, I have a "process" lol....
I have this trello board that I use to track the progress and the backlock, and what we are doing. So the most left column is called «Add you crazy ideas here» and I encourage everybody to use this column exactly for that.
Every time we are done with some goal completion I go review this column (some times with the authors to get more context on what they want, what are they trying to achieve, what's the problem they wanna solve and what's the value they get from it) and I promote somethings to be executed, or I change them because sometimes the real problem is not what they wrote but something else underlying. Some things I reject or I put them on hold because the value we get is too small and the execution is too complex. Let's call this «grooming», even if is not "SCRUM's grooming" exactly.
Anyways, it doesn't matter what the read map is. I will try always to insert groomed tasks that are aligned with the read map or really help a lot, or are bugs... and get some of them executed during our iteration process.
Now that I mention iteration, the iteration is not time fixed, that would be insane. The iteration depends on goal completion. This also doens't mean that the iteration is just focused on a goal, there will be plenty of changes during execution, things popping up and so on. Because I can't pause the business and people from using our software while we develop it.
Very interesting, thanks for the detailed explanation! Looks a lot like the way we are using scrum, the only real difference being the fixed time iteration, which we do have. Thanks again for all the info, love seeing how other people find their own way of working that suits them.
Thanks, should I write a post about that? About our iteration process? :D
I can't speak for others, but I'd love to read it :)