Showing posts with label post. Show all posts
Showing posts with label post. Show all posts

Wednesday, May 30, 2018

The curse of low-tech Scrum


I recently read the following article that describes how scrum disempowers devs. It criticises the "sell books and consulting" aspect that seems to have become the primary driver behind the Agile mantra. Sadly, I strongly agree with the authors' view.

Scrum brings some excellent value to the technical development process such as :
  1. Sprints offer a better way to organise than Waterfalls.
  1. Force to ship functional products as frequently as possible to get feedback early and often from the end user.
  1. Requires stopping what you're doing on a regular basis to evaluate progress and problems. 


However, Scrum quickly spread within the tech world as a way for companies to be "agile" without too much structural change. First, Scrum does not require technical practices and can be installed in place at existing waterfall companies doing what is effectively mini-waterfall. Second, such deployment generates little disruption to the corporate hierarchy (and this is the crux of the issue). As a result, Scrum allows managers and executives to feel like something is being done without disturbing the power hierarchy.
Even though the method talks about being flexible and adapting when there are real business needs to adjust to. The higher level of corporation rarely adjusts this approach which relegates scrum to allow companies to move marginally in the direction of agility and declare "mission accomplished". Agile providing a low-tech placebo solution to an organisational aspiration.
Last but not least adopting a methodology for the sake of it is often doomed to fail. If you have a customer that needs a new thing built by a specific date. Then scrum is less than ideal as it requires the flexible date and profoundly involved customer stakeholders in the process. The waterfall approach would be a better choice as it forces to define the project up front and allows for calling out changes to the plan and thus changes the scope.

It is often disappointing to see claims by consulting firms that organisation needs to adopt agile. It's a piecemeal solution that will only temporary mask deeper organisational problems without the required correct structural change. It's not because your dev teams started to use agile or devops that your organisation as a whole suddenly became agiler. 

Don't misunderstand this blog post as a complete rejection of the principle of scrum and agile. It's not. The core ideas are awesome and should be adopted where it suits. Other methodologies such as waterfall, devops, etc.. have also their place in an organisation depending on the lifecycle stage of the products. However, these need to be adopted alongside organisational change beyond the devs teams to improve the overall operations and efficiency of the company. Without these, it's just a low-tech placebo.

Friday, June 16, 2017

Maxims of Maximally Effective Startup Developer


  1. Test, then Deploy
  2. A coding Developer outranks an Architect who doesn't know what's going on
  3. If the food is good enough, the devs will stop complaining about the incoming workload
  4. Only you can prevent prod failure. 
  5. If testing wasn’t your last resort, you failed to resort to enough of it.
  6. The longer everything goes according to sprint planning, the bigger the impending disaster. 
  7. The world is richer when you turn competitors into partners, but that's not the same as you being richer.
  8. Give a developer a task, he will code for a day. Take his software away and tell him he's lucky just to be paid, and he'll figure out how to code another one for you to take tomorrow. 
  9. "Deploy and Forget" is fine, provided you never actually forget.
  10. Don't be afraid to be the first to resort to rollback.
  11. The competitor of my competitor is my competitor's competitor. No more. No less.
  12. There is no over testing.' There is only 'Continuous Integration' and 'I need to spawn more Jenkins slave'
  13. Just because a feature is easy for you, it can still be hard to your clients.
  14. There is a difference between a spare feature and extra [feature].
  15. Not all good news is competitor action. 
  16. “Do you have a backup?” means “I can’t fix this.” 
  17. The size of a developer startup stock options is inversely proportional to the likelihood of the startup surviving to collect it
  18. Don’t try to save money by conserving lines of code.
  19. Don't expect the competition to cooperate in the creation of your dream startup
  20. If it ain't broke, it hasn't been deployed to prod yet.
  21. The dev team you've got is never the dev team you want.
  22. The product management guideline you've got is never the guideline you want
  23. The best way to win a one-on-one architecture design is to be the third to arrive.
  24. It's only too many features if only the devs use them
  25. Don't bring big VMs into small servers
  26. Management knows how to do it by knowing who can code it 
  27. Failure is not an option - it is mandatory. The option is whether or not to let failure be the last thing you test.



Borrowed from Shlock Mercenary Comic