Project management methodology for lazy people

"I will always choose a lazy person to do a difficult job because he will find an easy way to do it" - Bill Gates once said. A human is a terribly lazy creature. At least 99% of us are lazy and I will leave it up to you to decide whether you are one of them. It's part of human nature to be lazy. That's why, you can either keep struggling with the fact that you don't have wings - or you can learn to live with what you have. The same can be said about laziness. You shouldn't have to deny it, instead you have to create circumstances where you would be able use your laziness as your weapon.

If we go back to 2 or 3 decades ago, technology at the time placed extreme demands upon people. It also required ultimate precision and concentration from a developer. There was undoubtedly less room for laziness.

Time passed by and technology advanced to what it is now. It was laziness that has led to simplified interfaces, protocol unification and getting rid of the unnecessary. Yet it's undeniable that laziness also led to project failures when it was unreasonably managed. It became a necessity to deal with it somehow, which gave birth to project management methodologies as a result.

It is unbelievable how many new concepts and ideas have been created. Let's take the Waterfall methodology for example. It is a good methodology but it's becoming old fashioned as it cannot stand high dynamics and ever-changing requirements. In fact, lazybones could do nothing for months and when it came to project delivery - it became yet another failure.

Unlike Waterfall, modern Agile methodologies tend to meet present-day realities. Scrum, for example, manages to get lazybones out of hibernation. No wonder it's so popular.

  • Turning it into a formality and failing to apply changes gradually. Your team has to get used to it and feel the benefits for themselves.
  • Expecting rapid results."Now we finally have Agile, and we will do everything we want" - top managers might think this in the beginning. After a month or two: "We've had enough of Agile, it doesn't work for us". You shouldn't expect it to work purely because it's cool, popular and is said to be effective. Every methodology is implemented by different people and thus it cannot be successful just because you use it.
  • Underestimating team work. Even if you have team members that are really good without Agile and they don't have time for your "new games", involvement of the whole team is necessary. Agile is a team game, and even if at least one player plays against the rules, it affects the whole team.
  • Optional application."Ok guys, we have a very urgent task now from a customer. Forget about all the methodologies and get down to work very quickly. We'll proceed with Agile later." - a very common mistake that managers often make. You shouldn't think that Agile is suitable only when everything is fine and calm. You should learn to apply it even if you are working with very urgent projects.

TDD and laziness as a perfect match

Or, let's take TDD (test driven development) - probably the most interesting process in terms of laziness. It can actually use laziness to increase productivity. Imagine you are programming without TDD. You are writing code and you forget to check input data or fail to find any exclusion. You could make a spelling mistake or perhaps even a more serious mistake. And it's obvious why - you are trying to reduce the volume of your work - however this is where buggy code comes from.

And now let's imagine you are working with TDD. You start with writing tests but you are lazy again, nothing has changed except that now you are not writing the production code first but the test. Here is the difference - you will write a test that is very similar to what your real code will look like. So that you could use it later for reference or even copy it. And this is brilliant - you will test exactly what is needed, save your time and get the documentation. At the same time, you will think of a suitable name for your test arguments. You will try to do this test as simply as possible and your real code will most probably inherit these features.

Even though TDD is a software development technique often related to Agile, I feel confident enough to claim that it is possible for it to work with website development or content development as well. Here, preliminary creating of test prototypes and structures will significantly facilitate the process of creating real websites or writing real articles. As you will be too lazy to write complex prototypes and plans, the process of implementation will be free from excess complexity as well.

Final word

Laziness will always be with you whatever you do, if you belong to those 99% I mentioned, of course. You cannot just get rid of it or make your team do your tasks for you either. But you can make sure laziness does not cause harm to the way in which you work. Confused with all the project management methodologies? Or with their pros and cons? Contact us, our specialists will help you choose the best option for you.

We use cookies to improve performance and enhance your experience. By continuing to use this website you are agreeing to use our cookies.