Agile and Scrum – should they die?

If you did not yet read the article “Why Scrum Should Basically Just Die In A Fire” by Giles Bowkett, you should. That is a great discussion of various key points in Scrum methodology and the shortcomings in nearly all of its implementations in real world. I have been meaning to write up a bit of my own criticism of Agile and Scrum the way it is usually implemented today but this guy pretty much nails it down.

I don’t know personally the guys who actually put together the first definition of Agile, but I think they did not mean it to be the spectacular failure it is in too many companies today. They certainly meant to concentrate on getting working software faster and with less distraction from endless meetings that bogged down software development in the nineties. They did not mean to make management lose the long-term perspective and focus on the immediate short-term “productivity” at all times.

The mechanistic approach that is now given to us under the name of “Agile” and “Scrum” does not benefit the software development. All these story points, stand-ups, short runs – they do not promote the important part of software development – the creativity – at all. Remember that software development is actually a creative work and you quickly realize that the best thing to do is to let the people actually organize the work the way they like and measure their performance with the actual working software instead of these virtual story points and numbers of user stories. Let the people know what is expected in the end and let them keep that focus on the long-term goals while they work out the minutiae of their current tasks.

I guess I am getting worked up and writing my own article here and now. I shall stop. You go read the article, please. Thank you.

Oh, and just one last thing. The great advice comes at the end that I happen to really agree to wholeheartedly:

If you’re not doing well at hiring engineers, the answer is not a deeply flawed methodology which collapses under the weight of its own contradictions on a regular basis. The answer is to get better at hiring engineers, and ultimately to get great at it.

Ain’t that the truth.




Computing in the Cloud – is it like banking?

Magnificent cumulonimbus clouds

I hear often comparison of IT and computing in the cloud with other “commodities”. Some people say, well, we do get the water and electricity centrally, why would we not get the computing centrally as well? There could be suppliers of computing power that one could use over the network and then one would not need to actually invest into own computing infrastructure. You would just send the data and the required operations into the cloud and get back results.

This is very much how the mainframes worked in the old days, you know? You would have a large computer somewhere in a computer room and you would connect to it from a terminal and submit tasks. The mainframe would compute your tasks and provide the answers. It seems pretty much the same familiar concept now all over again. But, wait, is it? In the old days, your mainframe would be inside the organization, it would still be under your control completely, the data would never leave the building, so to say. Yes, it could be physically in a different location but it would remain within the same company, university or whatever organization actually owned the mainframe. That is not the same with the cloud computing. And there is more.

When we compare computing with utilities, is that actually a good analogy? Utilities are provided to us. We consume the provided utilities and the only thing we give back is garbage, face it. We never send anything useful or valuable back to the utility company. Now, with computing, we send to the utility company the most valuable asset we have – the data and the algorithms. We trust the utility company to take care of our most precious assets. What does that look like?

Computing is not like water, it is even not like any other services. Computing is like banking. You give your data to someone just like you give your money to the bank. Bank deals with your money and promises not to lose it but pay dividend. The cloud provider is similar – it takes your data, promises not to lose it and computes something extra for you. Computing is not infrastructure, like water or payroll, it is rather a service like banking – not essential but convenient under right circumstances.

The cloud providers could be very convenient, efficient and secure – just like a bank can be. Power of the economies of scale applies, of course, making the computing at a cloud provider faster, cheaper and more precise. And just like a shady bank for your money, a cloud provider could spell disaster for your data. Your data can get lost, be corrupted, mishandled, sold to someone else … I am sure you can come up with a dozen other disastrous scenarios if you just think about it for a minute. The banking took a while to get things right and so will the cloud computing too. And, just like banking today, cloud computing can become the screwed-up industry of the next age if not set up and taken care of properly.

All of the things that apply to banking, apply to cloud computing with a twist:

  • Legal restrictions, like the country your data goes into and comes out, where it is stored, who has access to it and so on. Compare with the banking regulation, money laundering, bank secrecy, etc.
  • A larger bank can afford better security but represents a larger target and may become too big to handle efficiently the changes, which reflects directly into the cloud providers.
  • You lose control of your data when you give it over to the cloud provider just as you lose control over your money when you give it to the bank.

Everything that you do when you select a bank and decide how you use it will apply to the selection of a cloud provider. Decide what services you need, what level of trust you want to establish with the cloud provider, how much of your data you are willing to lose and see the risk of dealing with the cloud provider versus keeping the data in house.