If there is one thing that we software developers are infamous for, it is our inability to estimate our work accurately.
The problem is so commonplace that many project managers consider it best practice to multiply developer estimates by a factor of two — at least.
Whether you are a software developer or not doesn’t matter; if you have been in the vicinity of a software project, you probably know what I am talking about.
Why has it come to this? Why is the simple question “how long will it take to build this?” so hard to answer?
A couple of days ago, I talked to a friend of mine who is running a small website development agency. Despite COVID, 2020 had been an excellent year for business.
The only problem? They were charging by the hour, and they had maxed out their capacity.
So. In an attempt to become more scalable, they were in the process of switching over from hourly rates to value-based pricing.
If you’re not familiar with the term, value-based pricing is basically about fixed-rate projects or services, with a twist. …
Milton Friedman used to say that nothing is so permanent as a temporary government program.
The same phenomenon is commonly seen in the business world when it comes to defining processes and metrics. What usually starts as a “let’s implement this and see how well it works” quickly becomes a habit and, often sooner than later, a regulation.
Once a process has been established, it can be very challenging to replace it — even when hard facts prove that the process isn’t providing optimal value or accurate results.
What usually happens instead?
The process becomes subject to investigation and optimization…
Picture this. You’re a small business owner running a digital advertising and promotion agency with 8 employees.
After a year of trying to make ends meet during the pandemic, the situation is — to say the least — strained.
Everyone is working hard and trying their best to keep the remaining clients happy, but you can’t rid yourself of that nagging suspicion that the effort doesn’t match what you read on the bottom line. Not to mention that the bottom line isn’t updated as frequently as it should be.
The staff has already been trimmed down to the bare essentials…
“Work smarter, not harder” is a staple quote in the world of business and startup inspiration porn. At face value, I think we all can agree that this is nothing short of a solid piece of advice.
After all, getting more done with less effort or fewer resources is the very definition of being efficient.
But what happens if you invest a lot of time and effort to “work smarter” on the wrong things? What if you are barking up the wrong proverbial tree?
In my experience, it almost always pays off to be on the lookout for process optimizations…
Picture this: you are attending a workshop. You are sitting in a room with twenty people, most of which you haven’t met before. The facilitator opens by saying,
“Before we get started, let’s go around the table and have everyone introduce themselves.”
After gazing around the room, in a way that reminds you of the Eye of Sauron, he casually stops at you. The physical reaction is immediate. Your heart starts pumping faster, and you feel how your face turns red. For what feels like an eternity, you sit there, paralyzed.
Until he smiles and says, “I can go first.”
If you want to be genuinely productive, you need to focus 100% on what you are doing. With tasks perceived as fun and interesting, that shouldn’t be too hard; since you enjoy doing them, the focus comes for free.
But if you need to deal with something you don’t feel like doing, like a not-so-interesting work task, then the game changes completely. Depending on how strong your self-discipline muscle is, your mind will start to wander, and it will be harder to stay focused.
How can we deal with this? Often, the biggest hurdle is that we haven’t yet decided…
In the beginning, the Agile movement was mostly about a set of values and disciplines aiming to help software development teams to build small to mid-sized products. The focus was on craftsmanship, close customer collaboration, and to bridge the gap between developers and management.
The primary measure of success? Working software. And the ability to keep a sustainable pace to keep delivering.
To boil it down to a single word: Trust.
Today, most managers and developers still subscribe to the ideas in the manifesto, at least in theory. …
So, you have decided to pursue that business idea you’ve been pondering for so long and build a SaaS. Good for you!
To develop your own software can be one of the most rewarding endeavors out there, especially when you get that initial traction and your first customers. Finally, all those evenings and weekends you spent on endless problem-solving instead of watching Netflix are paying off.
But beware — while it’s easy to realize your software concept in theory, it might be just a little bit more demanding in real life. …
Questions along these lines are not just relevant; they are vital — as much in the SaaS products space as in wingsuit flying.
But while they prevent us from taking the leap before we can deliver, they can also seriously hamstring our confidence.
While I have yet to toss myself off a cliff wearing a flying squirrel suit, I can confidently say I have some first-hand, hard-earned experience when it comes to launching products.
Experiences that have rendered me cautious and, according to my wife, way too perfectionistic for my own good.
I have spent my entire 2020 building and…