Scrum seems to be the most popular agile framework – when you hear agile, you most probably will hear sprint, retrospective etc. Scrum is a framework.. Agile is a set of values. Scrum didn’t mention any values explicitly, but has them implicitly – some of it’s foundations can’t be used without those values.
Scrum came into this world 8 years before agile – 1993 vs 2001. Scrum, among others, is based on techniques taken from Honda and Toyota (lean), Jim Coplien’s Organizational Patterns research and research of Hirotaka Takeuchi and Ikujiro Nonaka. Scrum was first used in Easel Corp. by Jeff Sutherland and in Advanced Development Methods by Ken Schwaber. Standups idea was taken from Borland (in private talk after the course James Bach told he introduced this idea in Borland in one of his teams).
Without those values it turns out to be mechanical scrum, one of the cases of ScrumBut. It doesn’t reveal the full potential of the framework. Yes, you do iterations and some of the ceremonies. But how do you hold those – who gives estimates, who grooms the backlog, how sprint is planned (or rather pushed). Often mindset remains the same – you add ceremonies to your previous work habits and you call it Scrum, it turns out into yet another command and control model. Quite a strict control model I would say.
Treat people as individuals
If you treat different people with their unique set of problems and feelings as identical machines, by pushing same model cross all the different people. If you push certain goals and technical approaches, because one team achieved it and therefore others can too. Or, moreover, call you engineers stupid who won’t get to those approaches otherwise (real life words) – you’re braking the first agile principle – Individuals and interactions over processes and tools.
The model is here – scrum it self. If you think people are stupid and need to fulfill some additional process – you lack interactions and want processes and documents to do that job for you.
If you load people with metrics and time reports, start re-documenting the process and add rules to protect your position – you break the second rule of agile – working software over comprehensive documentation. You did the ceremonies, you did the sprints, you have tons of testing and metrics reports, yet software fails. Questions asked and your answer is – look at the reports, they’re fine. Say whaat?
Why mechanical scrum happens?
Blind adherance to the rules Aleksadnr Lokshin points out (in Russian) religious blindenss as one of the causes. People take agile tools as a set of formal ceremonies and don’t ask questions as if you don’t ask question ‘why?’ about certain religious ceremonies. It’s just because it’s done like this. The process has changed, but people reamained the same – afraid, blind and protective. Yes you do the standups, have iterations, create user stories and maybe even play planning pokker, do a retrospective for people to speak up and add some XP practices. Agile manifesto doesn’t mention any of these. Scrum doesn’t mention them, but you need them – without it’s formality, it’s not valued.
A set of techniques will very soon become a boring burrecraucy. If poeple don’t understand each others role, if documentation is more important then reality, if you don’t discuss work with product owner, but blindly do implement stories you were given – you will fail. You need culture to succeed. Understanding and using agile values is a must. And you must have certain people to help understand those.
Agile expert syndome – this is when people have to follow what an expert, a book or <company name> Agile process description says. Every advise has it’s context, moreover each advise needs knowledge to be implemented. If you detach context and knowledge and try to use ‘best practice’ just because ‘our coach said’ or ‘everyone is doing it’ you would eventually fail. You need understand the background of solution. You can’t jump to How? without understanding Why?
Separation of decision making and implementation – this case adds to agile expert – someone somewhere says how teams should perform their work, set goals and thing to be done by all means. Add metrics to measure achieving this goals and you’ll get teams faking results, not to be punished. How does this help the organisation? Teams who know the context and have their own unique set of abilities should decide how they will work. Working software and satisfaction is the metric.
Check out the remaining three in his full article.
Daniel Markham in his article Agile Ruined My Life marks down even more causes of failing agile – fake success stories, trainers who tell what teams should do, trainers who didn’t practive development, trainers and corporations dominance on the teams, cargo cult.
What to do?
Call it what it is
As Ken Schwaber says – “Scrum is like chess. You either play it as its rules state, or you don’t. Scrum and chess do not fail or succeed. They are either played, or not.”. You rather play Scrum, or play something else. If it’s not Scrum, don’t call it Scrum, call it <company name> process to become agile by year xxxx.
Agile and armies
Same goes for agile – you rather think and behave this way or you don’t. One might argue and say – but no one knows how to implement scrum/agile well, especially in big corporation. It is hard and great people and trust are the keys here. There’s enough imperical evidence on people motivation, and efficient armies conquring big territories are a great example of distributed, but well working organisations.
Some organisations, just like some armies, won’t be efficient and victorius, because they’re culture is different from the victorious ones. Armies are revamped by training great officers followed by training privates and giving them cool weapons.
Efficient armies, just like companies, don’t always need to be well distributed and autonomous. Just like many companies don’t need to be scrum. But in order to stay efficient and sustainable you need to respect people, maintain culture and obey certain values. Trying to copy those or pretending fulfilling those and not fixing problems will lead to failure.
Supplying great mechanics (read development tools) to privates who are not trained and/or don’t have strong leaders (officers/managers). Officers who are afraid to act, who don’t have decision autonomy to succeed common goal, who are corrupt and lie – will fail the army. There will be no trust between people (customers), privates (developers), officers (managers) and leaders (exectuives).
Simply said – people are the key, train them, build and maintain trust. Aknowledge that copying effective groups of people doesn’t make you effective like them. Don’t eat whole elephant at once – start with small pieces. Don’t fake, aknowledge you’re a beginner, but with strong ambition. Inspect, learn and adapt.