ROI
General rules for making good investments in our SW development are focused on spending money efficiently, to serve users
1
If there is a questionable decision anywhere (product spec., architecture, picked technologies) where a change of approach could save a lot of money, the team picks that approach without being told.
2
Everyone understands that we develop to serve users, not to have fun using technologies we fancy
3
Tasks in backlog either have estimates or are so small, that it is easy to estimate how much will it cost to develop them. PO removes stories that are not worth development or asks a team for a different approach that is cheaper.
Saving money when possible
Existing libraries have a preference for reinventing the wheel. This is true, especially for difficult algorithms like cryptography, binary data parsers & generators, and network consensus algorithms.
Solutions that are (almost) as usable as the planned ones but are significantly easier for development should be done instead of the more expensive solutions.
No unnecessary moving parts. No unnecessary technologies.
Yes, you can use Postgres for Business Intelligence, queues, unstructured data, graph data, caching, event sourcing.
Yes, sometimes the best solution is jQuery or vanilla JS. Not all apps must be SPA (Sales and Purchase Agreement)
Yes, often you can develop an app vanilla without Docker, docker-compose, or Kubernetes.
Tools like PostgREST, Hasura, CSS frameworks, and pre-built HTML components, are often great.
Building for people
The primary motivation of a developer should be creating value. Teams should focus on solutions that deliver a lot of value for users as soon and as cheap as possible even when it means we will have to use technologies that are not cool.
I know we developers want to learn, we want to use the newest technologies. Choose cool technology only if its usage is going to be as productive or more productive than using ordinary one.
I know we want to do things the same way as people who scale to 100,000,000 users. Unless you know that certain usage is guaranteed, don't optimize for scale. If the product has no users, build for 10 users.
Small tasks, estimates, purging the backlog
I will tell you how not to build a bridge. By building a piece of it and seeing if it goes well. If yes, add parts. If not, remove all unnecessary parts and start over. The bridge is hardware. It's as hard as hardware gets.
Things in development are not bridge-building. You don't have to analyze the whole backlog. And because everybody knows that once the bridge is built, you cannot move it 50 meters north, everyone will move the road. Everybody knows you can change the software. So they will always want to change the backlog. No successful software product looks exactly like it was envisioned initially.
And sometimes ideas that sound great are not so great when people think hard and understand that this little idea or cool technology adds $100,000 to the price of the thing.
With all this, you see that backlog is a place that is changing. And that has some great ideas, some ideas that are a subject of change, and some ideas that are not great at all.
The price of the feature might make an otherwise identical User Story a great idea, the idea that is a subject of change, or an idea that is not great at all
Teams have the option to do no estimates. This comes with a rule. If the team will do no estimates, all backlog items should be <8 hours of work. At that granularity, stories become a measure of progress by itself. And when PO asks, the team that doesn't provide estimates otherwise, should make an exception and give an estimate (if the team doesn't estimate and therefore doesn't have any story points, a good estimate might be a central estimate + interval of uncertainty like 3 days ±1 day).
Join Our Webinar!
Key Topics Covered:
- Challenges: Understand common issues like leadership, communication, and team dynamics.
- Skills: Learn key management skills like planning, people management, and decision-making
- Strategies: Get practical tips to make the transition from development to IT management easier
27
07:00 PM
CET
Wed, Nov 27