Scrum bashing - natural iterative evolution

Not throwing my weight into a current Scrum bashing trend that erupted this week, as I'm a nobody when it comes to agile. But I tend to agree some of the points and disagree with others.

It all started off with Uncle Bob responding to Chris Brookins whom was looking for some of Scrum shortcomings to present at his work.

That raised a large number of responses on the thread and in the blogsphere. People such as Jeff Anderson stated that it was time for Scrum to evolve.

Others such as Jurgen Appelo came in defense of Scrum by insisting people should stop pissing on Scrum.

Issues raised

• No technical rules, ie no prescribed methods of insisting on CI, TDD etc.
  I dont agree with limiting Scrum to development only, but suggestions are fine, which they kind of already do.
  


• Sprint lengths are too long.
  They are. But again agile carrots of emphasising e.g. 2 weeks are better than bashing teams that need longer sprints.
  


• Scrum masters assume or are assumed to have to much power.
  That does happen too ften, but coaching of team members and external chickens are probably the solution.
  


• CSM, Certified Scrum Masters.
  Yup the title does not help, I even got it....,
  but dropping it may result in very few taking the courses all together. Time will give a solution to this I think.
  


• Backlog structure.
  Not sure this can be solved, because so many different type of organisations use scrum for a variety of usage, the items in the backlog are very different.
  Partially the problem here also lies in the pedantic use of manual physical task boards,which translate into difficulties in transferring stories/tasks.
  Also the tools available, e.g. Jira+Greenhopper, have poor support for Stories and Themes.
  


• Anti management.
  Scrum and its adapters have a reputation of Anti management.
  This may be true as team members often would like to introduce Scrum for the empowering of the team in the decisions.
  But once implemented it is not so much the case.
  I would actually say it is a bit pro management, once they see the results and a clearer vision of their future. Also Scum increases management due to the team's own micromanagement and constant status reporting.
  


• Automatic tests.
  It's Uncle Bob, Mr FitNesse. True, an essential part, but not always the rule.
  


• Multiple teams.
  Yes, this is one point that Scrum struggles with.
  

Future of Scrum

I think this bashing of Scrum now is a natural evolution.

The early adopters, the evangelical Scrummers, now need a new fix, and are quite vocal in Scrum's negative points. The early sceptics, also realises Scrum does not solve everything and would like to move on.

But it is natural. RUP, then XP, Lean etc are not perfect, they are just an iterative history of continual evolution and improving methodology of teams and projects.

Scrum is not a bible to follow for the next 2000 years. But now, or rather 5 years ago it was the best thing around. It has helped a huge amount of organisations become agile. Not perfect, but a lot better than before.

We should not always jump to the new shiny thing, but it is probably time to evolve, to continually improve and never rest at least not too long.


I quite like ideas suggested by Kanban. Kanban practices more common sense. As Henrik Kniberg writes in his minibook about scrum and Kanban.

But again it is not the final evolution. And everyone should adapt their needs as appropiate. There is no need for this bashing of Scrum. But neither should we not try to improve it.

Don't like Scrum. But will not use anything else! Part 2

Following on from my general rant about Scrum, Part 1, here is Part 2.


The main beef I have about Scrum, are
* the constant status updates at stand up meetings
* the use of non electronic tools
* inflexibility on tasks

These are elements that are easily changed and is probably mostly interpretation. My dislike for these can also reflect perhaps badly on me, if taken from a superficial view.

I don't like the morning stand ups. For several selfish reasons.
* I don't like mornings.
* I am not in early. (Especially now living in Norway where developers start work 4 hours earlier than in the UK even with only 1 hour time zone difference. My last job in Manchester, developers where not in till 11am. Here they start at 7am... )
* I don't like standing up.
* My memory is terrible.
* My plan for the day have not yet been thought of.
* I don't like standing up.
* I prefer to work from home in the morning, thus actually getting something done, instead of being a zombie at a meeting.
* I don't like mornings.
* I don't like the micro-management of it.
* It is a forced meeting.
* I don't like standing up.


It is not that I don't agree with status meetings and I can see standing up keeps meeting briefer.

Many of my work places, many of the companies' main issues have been solved in frequent 5min fag breaks (the English sigarette meaning of the word) even when no-ones smokes at the place. As a non-smoker I would always attend them, and discuss a bit rubberducking about things Im working on and stuck on. So informal meetings are very usefull.

Regarding standing versus sitting, I just hate standing. And not able to fully listen to anyone else's issues.

That it is just a quick run around of what you did yesterday, what you are going to do today and if any impediements, I just don't see the value for the developer. This should be clear in JIRA or any similar tool. Sure, it is a face-to-face status update for the management, so they can micro-manage everyone's day, but really mature developers should be trusted to deliver. That you can not discuss issues, devalues any development benefit from the meeting.

There are also some cultural issues to consider. Standing is meant to make it quicker, but Norwegians once a meeting is finished its timeslot will stand up and leave the room even if nothing has been resolved, or even when senior management or customers are present.


As a technologist and computer geek, the use in Scrum of non-technology such as post-it notes, sticking notes on boards, face-to-face meetings, is a sore point. Again I see the value, but it just goes against the grain of a technologiest.


Also the focussing on only the tasks on the board, post-its on your desks, and status updates on these every dawn is quite blinkered. True, it will keep people in check and some is usefull to make people consentrate on the tasks delegated.
But also have negative effects. Such as me, whom may help too many people, which is discouraged in Scrum as you should only focus on your own task.


And don't get me started on pair programming! That I should share my days with some other smelly developers odour is quite repugant. But again I see the value of writing code, solving problems together, sharing application knowledge. I just prefer frequent fag breaks and my private space! :)


BUT let me reiterate, I would only use Scrum!

Don't like Scrum. But will not use anything else! Part 1

As the title says, I don't like the Scrum (the project methadology). But I don't think I would use anything else!

It is like Churchill or Rooseveldt said something along the lines of: "Democracy is flawed, but nothing else works!". Which is also true. Democracy is the rule of the mob and pop culture, but all other governing styles leads to chaos, elitism or despotism.


I do like a lot of the ideas behind Scrum, the agile thinking is great, the XP ways do work. Everyone seems to jump on the Scrum bandwagon taking every element as gospel, and defending it religiously. But Scrum, has introduced many elements I don't like. I can see why, and what they can achive, but some I really detest.

Unfortunetly, all other project managent styles have more flaws, so I think "Scrum matured", or some better Agile methodalogies in the future is a better solution.


For Scrum and agile there are 3 sides to view from the pros and cons to its benefits.

* Management
* Developers
* Customers

It is mainly been developers who having been pushing Scrum as it will be better for customers, hence in the end for management as they are more profitable. However the bits I don't like is mostly where the benefits are purely for the management.


For management the pros are:
* Constants status updates
* Up to date status
* Future cost projectability
* Focused costs
* Low risk of wasted development


For customers the pros are:
* Ability to direct and change requirements
* Cost transparency
* Feature and status transparency
* Final release is as required


For developers the pros are:
* Low up front documentation
* Task sharing
* Modern and new, therefor interesting
* Management and customers are open to ideas
* Iterative development, of which one benefit is you dont have to solve everything immidietly


There are other pros, but they are not specific to Scrum, more that Scrum project are Agile and open to new technologies, and other methoods etc. Such as Continuous Integration, Wiki, JIRAesque.



But the cons are for developers
* Stress, due to constant pressure to perform every day
* Loosing individuality
* Turning into factory lines
* Constant status updates
* Perfect planning every day
* Orvelian supervising
* Loss of trust
* Low priority of refactoring
* Stand ups
* Back to low technology


Cons for management
* Stress and morale of staff
* Projects fix specific problems, but leave all else untouched, increasing rot and risk of general purpose tasks
* Distributed development is tricky


Cons for customers
* Probably not that much!
* Must trust supplier
* Difficulty in estimating accurate final cost


So you can see the pros does outway the cons. For Customers there really are no cons. It is just pros. For the management, once informed and convinced, they are also mostly pros.


It is just for the developers there are real cons, and they are the most noisy Scrum advocates! I am afraid as the idea behind Scrum gets older, developers will wain of it when they realise some of the consequences. But perhaps by then "agile" people will have forseen this and adapted a more mature and compatible "Agile 2.0" methodology and processes.