Economy decisions... with other expenses

I had a busy, week....and I think anyone can say this. Being busy does not necessarily mean being productive....it might mean just occupied instead.

Recently, together with my wife, we attended a Bon Jovi concert in Bucharest...being my wife's favorite music band, we decided to go.
There were two options:

1. Go to the concert in Vienna (about 500km and 4.5h, almost 100% on highway)
2. Go to Bucharest (about 660 km and 9hours drive, about 20% on highway )

The difference between the two was the ticket price, which in Austria was about 20 % more. Considering this and the fact that historically the concerts have been more engaging in Bucharest we took the economy option.

It was a long weekend...and a great concert...

Romania is a great country, with very nice places...and as some used to say "pretty bad that it's populated".

Bottom line is that sparing that 20-30% on the tickets, made us spend more on travel...invest more mental energy in coping with a wannabe European capital and it's inhabitants.

My father had a saying which goes something like this: "You did not overpay...just worked more for it".

How many times do we get in the same situation...when we cut corners...because that's the cheapest way to solve a problem? ...and than over time we end up just working more to fix things...

In some (most) cases, economy is not a way to go.
Using an open source framework...or just a free thing for your long term product might get you there faster...but how much will you invest in learning and getting to know the code...and later maintain it?

Choose wisely...or leave a door to opt out later.

Scrum - perils of the treadwheel

Keep your head down and work....that's what they used to say. ...no comments allowed...

Fortunately these times have passed and now you have the freedom of speech and you can raise your voice whenever you feel so...we live in a democracy (at least in the development world)...theoretically.


Agile practices have been invented to address the concerns of slowness and bureaucracy in the software development process. They focus on creating a clear view on what needs to be done and also they facilitate the communication between the team members and everyone involved in a project. So you can ask questions, raise concerns...but besides that you keep your head down and focus on the backlog.


The authoritarian roles (Architects, Project managers, ....) in the development have been replaced by democratic processes involving everyone. We strive for democracy.

With agile, and Scrum in particular, there is no single point of failure in a project anymore.... everyone is equal...and mediocre in the same time.
Regardless of your expertise, you have a voice...and that's freedom of speech.


Scrum makes you eat up the backlog one sprint at a time (divide and conquer).
If you fail to complete, you are little bit shamed by the not so optimal burn-down chart...but you will start over...you get a new chance....with a new backlog.
You learn to to keep your eyes only on the sprint backlog...that's only what matters now...for two weeks.


But what about the strategy? What happens to the long term goals of a project? Is a team capable to agree on a strategy and follow through? Who decides the strategy?

If you keep your head buried in the backlog, there is no time for strategic thinking...it's not in the backlog...you should not care.

A bit like factory workers...you have a voice but you learn that it does not change anything.


Every great achievement in the human history was achieved with a leader...and a great team that followed him. There is always a leader.

Should Agile teams democratically elect a leader? ... that could focus on strategy ... and future ...and could fight the battles...and lead the way... or should we leave this to the Product Owner?