> Engaged as a service provider or consultant by a larger corporate customer and not authorized to make product decisions yourself?
Then you won't be able to do scrum. You have a waterfall built into your development process: requirements and designs are generated and committed to on the customer side, then "fall down to" the consulting development team.
Scrum (or, really, any methodology that attempts to keep time constant by managing scope) is an iterated conversation between the people who want things, and the people who make things. If the people who want things aren't at the table, you can't have that conversation, and so you can't control scope. Period.
I love collecting these rants. For a long time, I've been convinced that various techniques may be fine and dandy, but the way we implement change in organizations sucks.
Fair disclosure: 1) I teach/coach Agile/Lean/Kanban/Scrum, and 2) I couldn't care less about brand names and religious dogma. I'm a developer first. If it works, do it.
Having said that, this author does not know what he is talking about. Apologies for being so blunt, but there it is. And he probably doesn't know what he's talking about because his organization has failed at making changes.
Really there's just a couple of questions to ask yourself. Can you get everybody important to the project into the room working together? Can you guess what you might do over the next week or two?
If you can do those things, hell if I care what you call it. If, however, you believe that complex systems must always consist of dozens of people with various deep-dive specialties? Then we've got a problem.
The problem isn't that some things in life are tough. Technology development is certainly tough. It's that you need to realize that the enemy of productivity has been siloing people and specialists that want to hand-off their work to others.
In some cases, the business environment means you can't have everybody in the same room. Fine, there are strategies for that (too much to go into here). In some cases, people just want to keep working the way they've always worked. Most of the time it's the latter case, not the former.
It's a shame that this person's environment has failed them in this way. No, Scrum is not made for a lot of things, but you are not a special snowflake. I can freaking guarantee you that no matter what technology problem you're solving, all that Scrum/Lean/Kanban/yadda yadda stuff has been used to help folks run fast. I would suggest trying to find other teams doing the same thing you are, only much faster, and watching what they do. That's how all these buzzwords came about, anyway. If you don't want to believe the books and trainers, and I'm fine with that, go watch it work. Then write another article. :)
> It's that you need to realize that the enemy of productivity has been siloing people and specialists that want to hand-off their work to others.
I think you're wrong. What you should realize that there are many enemies of productivity, and different for different people.
For instance, for me, having useless meetings (like standups or groomings) is mentally exhausting, and it kills a lot of motivation for the day.
I was most productive under well managed waterfall - where we had one longer status meeting each week, and instead of grooming interrupting work on the problem every week or so, we had time to think about the problem complexity at the beginning of the project.
In my view, the key to productivity in programming is focus. Whether you focus as a team or as a person doesn't matter. What is needed though is someone reliable who can shield you from all the distractions, and can do that without actually distracting you. In my experience with SCRUM, all the distractions are dumped onto developers (all of them in fact, via standup).
I am not against Agile development (in particular, just like author, I am not against iterative development or Agile manifesto), but the SCRUM I found rather silly. It's an attempt to do one-size fits all.
Not every feature requires exactly the number of people in the team. Not every feature requires one sprint of time. Some require less, some require more. If your work is managed correctly, you don't have worry about these arbitrary boundaries (which will always exist because time-boxing and standups, no matter how long the sprint or how big the team, are the key features of SCRUM).
For me it is exactly the other way around. I hated those weekly 3hr status meetings. Sometimes, I fell asleep. And I hated that all the specifications had to be upfront, without flexibility for the team or the stakeholder. Nothing was more counterproductive than implementing a solution, that when I knew half-way in that it was flawed.
With Scrum, if something bugs me, I bring it up. We do standups only if required (put a signal on the board). Meetings have a single goal and having it as a ritual (culture) helps to accept it. My team is not always the exact amount of people. People get sick or have holidays or just migrate into other teams. If my team needs a specialist for something, we bring someone on board for the required time. But we also try to share knowledge and not to specialize, because that would be a risk (sickness, holidays, termination etc). We also learned to break down requirements into stories that are small enough, so we can reason about it. We understand Scrum as a foundation that we can agree on. And if we disagree, we figure out how to change the boundaries of Scrum so we can move on.
Well, if my math is correct, 15 minute meeting every day still beats 3hr status meeting every week. Our status meeting was only about 0.5-1hr long, and we actually got a bit more done, because you're not supposed to go into detail during the standup.
Anyway, what you seem to praise is Agile (as per the manifesto), not SCRUM, and I agree (although some problems are actually suitable for upfront specification). Still, distractions can be a problem on the other extreme that needs to be managed too.
That assumes a 15 minute meeting only steals 15 minutes from your day. It's usually closer to an hour once you factor in the work-free buffer zones surrounding it. (Cf http://www.paulgraham.com/makersschedule.html)
"Technology development is certainly tough. It's that you need to realize that the enemy of productivity has been siloing people and specialists that want to hand-off their work to others."
What if the type of challenges that need to be solved involves: embedded device all the way up to cloud, big data, and devops automation where some of these things require specialties?
Some sprints might be heavy duty on a specific area of specialties, how can Scrum balance the productivity within a team?
>What if the type of challenges that need to be solved involves: embedded device all the way up to cloud, big data, and devops automation where some of these things require specialties?
Then maybe Scrum isn't the best approach. Scrum (and agile methodologies more generally) are not designed to solve cutting-edge problems where it isn't even clear whether the product is possible, much less feasible, to build. Scrum is designed for software teams working in a well-known problem space (e.g. line-of-business web applications) where the challenges are organizational (getting a clear set of requirements and managing requirements churn) rather than technical.
I certainly wouldn't expect a scrum team to deliver software for a brand new problem domain. For something like that, I'd expect better results from something like spiral, which explicitly includes room for research, experimentation and prototyping at each stage.
"Scrum is designed for software teams working in a well-known problem space"
More narrowly, it's for problems which can be broken down into more or less independent "features". It's not too helpful if you're building something which doesn't do anything useful until all the parts are working. The Scrum mindset is to first build a flashlight app, then add features.
(If only that were a joke.)
Flashlight app with an EULA, a privacy policy, and ads.[1]
Flashlight app with in-app purchases.[2]
Flashlight app with spyware.[3]
> Scrum is designed for software teams working in a well-known problem space
I always have to wonder, if your problem was already solved, why don't you just buy off-the-shelf solution? If you aren't doing anything new, what is the point? It seems like you cannot organize the work correctly already! Frankly, if you have failed to use what was already done, no amount of management methods will help cover _that_ productivity screw up. :-)
Well known != well solved. It's the difference between "we need to build a web application to do X" and "we're going to redefine how people do X".
Secondly have you seen Salesforce? The COTS solution isn't zero configuration in many cases. Plus many businesses decide their unique selling point can be having bespoke software that has a feature that the COTS version can't do, or do as well.
I've just spent 3 years using SCRUM to build a CRM system after my employer decided not to go with Salesforce because they wanted everything to match up to how we do things. Plenty of other firms in our industry are extremely jealous of what we've produced because it is domain specific rather than over generalised.
The problem is that research and prototyping is difficult to estimate even when you have a history of estimates. The advantages of scrum really kick in around sprint #4 or 5, when your team has a history of estimates that you can refer to when you're estimating future work items.
In a research setting, this breaks down because the work for sprint N is totally different than the work for sprint N-1, which means that you can't use the work logs from your previous sprints to estimate the next sprint's work.
If you cannot estimate something, then you should do it in a timebox over and over again, until you are satisfied. If my project requires lots of research and prototyping, I still have valid and useful options in Scrum.
For research, my team will have short sprints with timeboxed backlog items. The result of a research item can be a presentation of the discoveries and a vote / discussion on what to research next (sprint review). If my team's research isn't done within that timebox, the findings are presented anyway and the team / stakeholder may decide to simply file a new backlog item on the same topic for the next sprint. Or the incomplete result is a sign of complexity which can be split into many backlog items. Such items can be that the team decided to get external consultancy or a product presentation by a vendor.
If the team has to mix research with prototyping, it could do two types of sprints: short research sprints as explained above and longer implementation sprints for the prototype that are based on the research results. For example, the team may require two, one week sprints for doing research and then a two week sprint for implementing or continuing a prototype. At the end of each sprint (sprint review) there is a decision on whether the next sprint will be a research or a prototyping one.
So Scrum is still a valid method that enables a team to even steer research and prototyping efforts. This is where Scrum actually shines, because it gives you flexibility and transparency (!) in an uncertain environment.
That actually sounds like a really neat process and I'm glad it works for you. One question I have is about how you measure velocity with variable length sprints. My understanding of scrum is that the point of having fixed length sprints is that it lets you easily estimate how much you can deliver in a sprint, since each sprint is the same length.
If you have different length research and implementation sprints, how would you estimate the amount of work (whether in story points or whatever else) that can be done in a given sprint? Is it a matter of making sure to compare "like to like"?
A good friend of mine exclusively helps embedded teams. I just got through doing cloud with some folks. Big data is its own thing, but certainly not a show stopper.
If you're serious, email me. Happy to explain to any depth you find adequate.
I am not a coach or trainer. I am just a developer trying to remain sane. I tend to believe that any thoughtful process can work as long as you stick to it. It just so happens I do agile/scrum.
I believe that at its core, agile is about two things. Planning on a shorter time frame so you can react quickly as unknowns surface, and continuously improving your process. The ceremony is meant to achieve those two things. If you are are doing the rituals, and fail to achieve those two things, I can see how it would seem worse than useless.
Here is what they don't tell you, it doesn't make software development easier. In fact, it can make it harder. What it does for me is make it sustainable and sane.
Like committing to a sprint target. And literally doing everything to fulfill it. Like not waiting for a manager to step in and ask for overtime and weekend shifts. Remember? Scrum teams take all the necessary steps themselves. Always!
Isn't the entire point of scrum to enforce a sustainable pace of development? One that doesn't require heroics like having programmers come in on nights and weekends to finish? The entire point of tracking time and making burndown charts is so that you can avoid taking on too much work. If your team doesn't have the ability to push back on the requirements and say, "Hey, this is too much, we need to push features X, Y, and Z into the next sprint," you're not really doing scrum. You're doing kabuki-scrum, which is usually just waterfall with all the meetings relabeled.
Much as I dislike scrum and find it anti-agile, the author seems unaware that official scrum docs removed the word 'commitment' years ago because it was misunderstood as more than a target and misapplied just about everywhere.
Well, as far as I understood, Scrum's fundamental principle dictates that the team delivers working software at the end of every Sprint.
This has partially to do with not over committing at the beginning, but if the team fails to judge correctly, it has to do what needs to be done to fulfil its promises.
Unfortunately, this clear obligation gets forgotten to often – as I pointed out in the original post.
I don't care what methodology you're using, if it includes crunch then it's broken.
Proper, grown-up coding on a business application is incredibly wearying on the mind, and results have shown time and time again through research studies and professional management that past 8 hours coding in a day the average programmer's code quality starts to deteriorate. Past 10 hours it goes negative - at this point the code base is actually being damaged.
"doing what needs to be done to fulfil the promise" is actually alerting the team that you've made a poor estimate of the effort required for this feature and need to recalibrate. It is absolutely not sticking with your poor estimate and delivering shoddy code to the project.
Be careful what you wish for... I know several PM types that can match you insane hour per insane hour - some had skin in the game (part ownership), others were just overzealous and I know at least one burned out.
>it has to do what needs to be done to fulfil its promises.
No. Scrum is explicitly open to renegotiation. This is where burn-down charts come in to play. This is where having the product-owner be part of the team comes into play. If a feature is costing a lot more hours than anticipated due to unforeseen problems, it is expected that the team gets the product owner involved early so that a decision can be made: do we drop other work to deliver this feature, or do we drop other features to deliver this?
The core premise of scrum and other agile methodologies is that given the uncertainties inherent in software development, it is impossible to fix both the featureset and the schedule. Scrum fixes the schedule and explicitly allows for flexibility in the featureset. Other methodologies (like spiral, for example) fix the featureset and allow for flexibility in the schedule. Waterfall attempts to fix both, and fails as a methodology.
Once a team starts to work overtime and weekends to finish stories (on its own accord or by instruction) then the value of your velocity measurement is shot to pieces. Predicting and committing to future sprints is then a complete guesswork (or rather even more of a guesswork..) when bad committal is masqueraded with pulling a rabbit out of hat.
It also masks the problem in the retrospective - in my view the most important part of scrum. Developers put down positives for going above and beyond rather than being forced to admit, and therefore analyse, that the team failed.
I've found, though perhaps it is a British cultural thing, that there are plenty of things people sit on and don't mention out of politeness - they only come out after a particularly bad failure.
> Well, as far as I understood, Scrum's fundamental principle dictates that the team delivers working software at the end of every Sprint.
Working software yes. If you break the build the minute before the end of Sprint then yeah you better fix it. Sensible teams resolve this by not committing at the last minute, and by having the Sprint end at, say, midday Thursday, not 9AM on Monday.
> if the team fails to judge correctly, it has to do what needs to be done to fulfil its promises.
Nope. There are no promises, no "clear obligation". Half the point of the daily standups is that if a feature is not going to be deliverable in its original form within the sprint, you catch this early, and then you talk about it, you have contact with the product owner, and you decide something sensible.
But another point often forgotten is that the main goal is to deliver a working increment. Even if not the whole sprint gets delivered for some reason.
My experience with scrum is that it is degrading to developers - it tries to turn developers into interchangeable cogs in the machine, filled with micromanagement (aka 'daily standups') and puts to much decision making power into the hands of the 'Product Owners'.
I'm a grown up, i can make my own decisions, i can talk to clients (in fact, i want to - no that, is not a distraction), and I don't need anyone looking over my shoulder all the time.
Exactly my experience. Scrum is, above all, a system of controlling people.
Although it's defined as 'an iterative and incremental software development methodology for managing product development', in reality it's a system for managing power distribution within an organisation and managing dissent.
That is both a good and bad thing, depending on which perspective you want to take. Some people love the structure and team consensus that scrum produces, others are choked by the religious/dogmatic nature of the system.
I guess the more creative types are struggling most with scrum, because they feel like they are not working at their full potential and hence feel like 'cogs' in the system.
yes, of course it's always the "creative types" -- they can't work in a team, they can't work anywhere except their own sound isolation booth, and they demand 22 continuous hours for 1 hour of flow, but they're somehow more productive...
I'm so sick of everybody trying to cater to these crybabies. They can go work for the government or something.
The author challenged your perspective and you provided no rebuttal. Neither side has any evidence, but in my anecdotal experience I agree with you. I've worked in pretty much every type of tech organization imaginable and the ones that trusted developers across the development spectrum fared best. The ones that had managers handle priorities and wanted heads down coders to implement fared worse, by far. There is an incredible amount of craftsmanship in software, and often times developers are the best product managers because a passion for product is what led them to learn to develop in the first place. Cutting them out of everything but the coding is a mistake, except for a smaller subset of coders who do prefer a heads down role. You can find good spots for them on the right team, but if you don't you end up with a lot of well written code that solves the wrong problem.
The reality is a lot of us are cogs in a machine. Anyone can make a CRUD webapp, and maybe I can do it 20% faster than someone else, with better craftsmanship that will make it easier to maintain, but fundamentally we're substitutable. Self-deception would upset me much more. I see standups as the opposite of micromanagement; they give me the opportunity to ask for what I need, and the format almost forces my manager to shut up and listen.
It does put a lot of emphasis on a single Product Owner, and there are downsides to that. For my money you get better products if one person takes responsibility for the decisions and you follow them consistently, even when on a local scale you have a better idea.
Turning developers into interchangeable cogs is the holy grail of project management. It's the motivator behind most methodologies and also a large part of the motivation for many development frameworks (J2EE comes to mind, for one).
Unfortunately this has about as much chance of working as trying to develop an assembly line manufacturing process where every product is unique. It's not possible. People keep trying though.
If you feel degraded by the version of Scrum your team is doing, then the team is doing it wrong or at least the retrospectives are not working. And if you want to make your own decisions, then you are probably better off alone. But that is not the fault of Scrum.
How do you come to think, that almost everybody is failing at it? I don't experience that. Isn't it like with every other problem in our world? We hear from them far earlier and with big noise. Success remains quiet.
I actually started writing a point-by-point response to this, but it mutated into a thousand words and will be better suited to a blog post at some point in the future.
In the meantime, I think these are generally the same shallow straw-man arguments against Scrum that we all see pretty frequently. I guess the key points to bear in mind will be:
- Scrum is not a be-all and end-all solution to all product development. If you are developing a product for a slow-moving third-party (a case which is described as one of Scrum's downfalls) then you are correct – it's probably a bad choice. So is any agile approach. That is totally fine, and I'm not sure why it's seen as a bad thing.
- Scrum is not a fully-described, cast-iron set of rules that have to be followed. It's a framework which can (and must!) be changed to suit the team, and the product that's being developed. Concerns like wider-scale management and integration of multiple projects are so dependent on the functioning of an individual organisation that it would be ineffective to have a prescriptive set of rules. Your 'Agile Coach', product owners and management team generally have to deal with these issues in other ways.
- Scrum is (apparently, based on the objections in this article) implemented poorly in many places. For example, the 'seemingly endless series of meetings'? That's explicitly one of the things that Scrum does not encourage! Micromanagement is the same. Scope change during a sprint as well. That Scrum is poorly implemented is not a reasonable criticism of it, for me.
- It's okay to fail to meet targets when delivering software, and inevitable that it will happen. Scrum provides the tools to manage and recover from those failures, and to help ensure they are limited in scope. Those retrospectives, for example – it's totally valid to say 'We committed to feature <x>, and failed to deliver it because <unforeseen dependency y> prevented us from doing so'. The important thing is to understand what caused that failure, and how similar failures can be prevented in the future. That's a fantastically powerful tool to have.
Perhaps I'm just biased, because I've been working in excellently-managed agile teams that have been delivering software very effectively, and have seen how useful Scrum has been as a framework to manage the complexity of planning it.
"Perhaps I'm just biased, because I've been working in excellently-managed agile teams that have been delivering software very effectively, and have seen how useful Scrum has been as a framework to manage the complexity of planning it."
I'm lucky enough to have been in the industry before agile and scrum were popular and back before the agile days I worked on excellently managed teams that delivered great software effectively. I've also seen a lot of agile projects crash and burn.
At it's core agile is a small set of guiding principles. Principals I'm sure most of us agree with. Yet it's hard to sell these principles to process heavy organisations. I've seen it fail time and time again despite the efforts of top consultants and coaches.
IMO, agiles real success has been in giving structure to cowboy driven teams. Teams that now actually write requirements down. You could never convince these "cowboys" to write an SRS... But a few user stories... That's more realistic.
I value your opinion, even if I do not agree with it. The argument of "Scrum being poorly implemented" is brought again and again.
It's just another one of these go-to killer arguments.
If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly?
Maybe we should start thinking of a framework, that people can actually implement and make successful, without requiring an entire army of coaches and consultants, who make a ton of money from it.
I'd love if you'd continue the discussion over at Agile Overflow.
If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly?
That's simple, I think:
- 1. Scrum is not actually 'mega simple'. Like I said, it's a framework of outline for building a system suited to your organisation. It still requires skilled people to implement it correctly. It's like expecting coders to become magically better because they start using a framework like Rails - it might describe good practices, but it won't fix bad developers!
- 2. Related to that, we see bad implementations because methodology will not fix a broken organisation. If you have bad developers or bad managers, you will not produce good products. If you hire a bad consultant, you will not produce a working Scrum implementation.
Maybe we should start thinking of a framework, that people can actually implement and make successful, without requiring an entire army of coaches and consultants, who make a ton of money from it
It's obviously possible to have working and efficient implementations of Scrum; I'll testify that ours is excellent, and that's mostly down to hiring a very effective Agile Coach who knows how to implement it properly. And I know we're not the only ones - I expect you'll never hear about the good implementations full of happy developers!
The existence of an army of awful, unqualified consultants is a separate issue. You wouldn't expect to hire bad programmers and get good software; why would you expect good methodologies from bad consultants?
Hire someone skilled and let them implement a good system, and it will work.
If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly?
It fails because the problem it is trying to solve is so hard.
There is no silver-bullet methodology that make delivering quality software on time easy. Scrum does make a decent job of it though in an environment where Scrum can be implemented correctly. If it can't be implemented, then it won't work.
I'm reminded of the discussions about XP when it was newer. Lotta folks thought XP meant "cowboy away" and then got excited when it invariably didn't work--the original folks said "well, look, you're not doing the process; you can't blame it if you're not doing it".
Now the thing is this looks a hell of a lot like a No True Scotsman argument, especially if you're only glancing at it in passing. Yet, boundary setting is a legitimate thing to do; the XP folks had put up their lists of practices, etc. XP is/was very demanding, very tricky to do; it was an open question for a little while whether it was actually implementable by average organizations. The interface with the product owner was a particular issue, and is still in Scrum.
Put another way, when you say "Scrum says to do X" (say, very few meetings which should go quickly), and someone goes "Scrum sucks because we're constantly in meetings explaining why we're not getting any work done", and you say "You're not doing Scrum"... you have a point. Scrum teams are not supposed to be crunching; if the product has to ship by date X, then some of the features won't get in, and it's the product owner's _responsibility_ to say which ones those are. If the product owner says "I don't care these are all mission critical we can't discard any of them" then you're not doing Scrum, even if you have some highly educated boob with a certificate from some idiot making them a Scrum Ninja or whatever saying that you are!
Now, some of the practices are more important than others, and most of these frameworks say "you kinda need to be flexible, but try it first". So there are grey areas. And sometimes (as with XP) the existence proof that it is even possible to do the process is nontrivial. But kabuki-scrum (thank you, quanticle!) is a real thing.
From my experience most of the time companies/teams didn't even try to implement Scrum. Like having multiple product owners, skipping meetings, inventing new meetings, product owners not attending sprint planing or developers not caring about the process at all. The product owner is a single point of failure. If he does not work well it is hard for a team to deliver. In most teams I worked so far team members haven't even read the Scrum Guide nor gotten any training and didn't care.
It's a great point. To my mind scrum is actually a compromise aimed at selling agile into waterfall organisations. Apart from the flaws of scrum itself (too much process/waste), the two really big blockers are that it requires organisational change but is applied at a project level, and that good agile project leads/TPM's are way rarer than the good developers everybody says are impossible to find.
We fail because it is about people interacting with each other. We fail, because we were trained to work on our own and competitively. We fail, because we have trouble to change our mindset and have even more trouble to change the minds of others. This is why we will fail at alternatives to Scrum, too.
Scrum requires a different mindset. It requires us to work in a team with honesty and jointly in order to be successful.
Teams fail at Scrum because they are dysfunctional from the start, don't share the same mindset about their work and processes or don't embrace the ideas Scrum provides.
Do you live in Utopia? How do you get around in your environment?
Scrum is not a solution that you buy off the shelf and just run in your company. It is a framework to manage work and scope in a team. And it acknowledges that we are individuals who have to interact with each other in order to achieve success. Both aspects are equally important and have to be addressed. Scrum will not make problems disappear. But it helps you to manage them in a transparent and controlled fashion.
Don't you live in an environment with rules (law) and frameworks (social culture)? Is that environment perfect? I guess not. That's why we deal with imperfections on a daily basis. Like we have to do when living Scrum.
> If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly?
Just because something's simple doesn't mean it's got buy-in. It fails because implementers fail to get buy-in from people with power, and those people insist on keeping their pet processes in place.
If you have no control over requirements and a bunch of people who can't work together towards a common goal, I'm not sure what, if any, methodology will work.
The main complaints against Agile by developers are:
1) I want to hide in my technology rathole and never come out.
2) I'm allergic to accountability and can't take people asking me once per day what I'm up to.
3) I don't want to have to talk to other people.
So, if any of those apply to someone you're going to implement Agile with, they're not going to be happy.
Agile is as much a cultural agreement as a methodological agreement.
None of these complaints is in the original post, which I agree with - the things he talks about are problems of SCRUM. Also, AFAIK the standup is not about accountability, it's about communication.
Just wanted to jump in and let you know that I do read your feedback and * very much * appreciate it. I'm quite busy with responding over at Agile Overflow but will eventually comment back here, too.
> While they just try to focus on building software, Scrum dragged them into seemingly endless series of meetings called Reviews, Retrospectives, Plannings and Dailies.
This just caught my eye. The Scrum process as originally described had three meetings - one planning meeting per sprint, one retrospective per sprint, and one daily stand-up. It's a stand-up, as opposed to a sit-down, to try to enforce brevity. It's also typically recommended to spend 5% of your sprint in backlog grooming/refinement whatever we're calling it.
You should, of course, iterate on your process to make it suit yourself. My team, for example, decided that we'd spread that backlog refinement over multiple days to keep it short, sweet, and relevant. We probably spend more time on it than 5%, but that's purely self-interest, as it keeps our plannings short (we are usually coding by the afternoon of the first day of sprint), and our stories well-estimated and deliverable.
But then it's hardly reasonable to complain that your modified process means that the underlying principles are bad.
That grabbed me too. Our coders pretty much just code. They talk amongst each other sometimes to the PO to clarify requirements. That's about it. We never ask coders to write stories unless they're developer stories they have asked for themselves.
I worked a remote job last year which used Scrum. We typically would have 2 hour stand-up meetings per day, A 3 hour retrospective meeting every week (usually Friday) and 4-5 hour meetings at the end of each sprint for figuring out what we were going to be doing for the next sprint (every 2 weeks). The business owner would many times be figuring things out as we went along during these 5 hour meetings..sometimes painfully slow.
This was all for a 5 person dev team. I was consistently billing more hours for meetings than actual coding work. At one point, the owner decided to have a meeting every Friday to just "hangout" where we would either tell a joke or a story..to "get to know each other" (this was another hour). I was the only American working for the company. The rest of the team was from India, Mexico, and Egypt.
To give you an idea of the work environment, one of the other remote employees kept overwriting all of our git checkins. They never figured out who it was (I'm not sure why), but I had to re-do all of my checkins for 3 weeks. It was complete chaos.
I finally quit when my business started making enough for me to survive without it.
The icing on the cake was when the owner changed the name of the LLC a few months ago, so all of my shares became worthless.
Yep, that sounds pretty terrible. To give you a contrast, our stand-ups take 10 minutes at worst, and our retrospectives take 3 hours every third Friday, and plannings are about 3 hours also, again once per three week sprint.
Slightly off-topic. Does anyone know the origin of this (frankly weird) terminology of scrum "master and "coach"?
Merits of the actual methodology aside, I just have to admit that it rubs me the wrong way. Is it really that necessary to indicate that most places don't have scrum-like qualities in their processes, and require someone certified to "teach" or "coach" it to them?
Scrum / Agile can have failure points both technically (code/development) as well as socially (requirements/planning). It sounds like you've seen a lot of social failure points in your experience.
I would hate to address all your complaints point-by-point, but I'll address the first which leaps out to me: that of a requirements phase prior to sprint start.
In the training I've gotten for scrum, there's an overriding principle that you don't (nay, can't) commit to work when you don't have all the dependencies. I can't commit to building a brick wall when the bricks haven't arrived yet.
If you have a hard requirement where you need/want to have an architecture phase prior to sprint start then you should be staggering your architectural planning phases with your development phases. In the current sprint you can be working the architecture requirements for the upcoming sprint, and developing off the requirements/design that was worked out in the previous sprint.
Overall, I think you've got some valid complaints but many that are misguided. I worked with someone who "just wanted to code" and didn't work to grasp the big picture. Much of what he did had to be re-done because it didn't meet the actual customer needs.
You would likely look at that and scream: "See, scrum doesn't work! We should have had a requirements document written 18 months ago that this code monkey could have worked from!"
I looked at it and said: "Wow, I can't afford to babysit this guy who has all the tools, information, and access necessary to correctly meet the customer requirements, but consistently doesn't manage to do so."
In the first case, you have more clarity up front but less flexibility while the work is in progress (front-loading work).
In the second case, we would have had to have two people doing the job that one person should have been able to do (incorrect delivery was a persistent problem with him which we worked over a year mentoring him on).
You are absolutely correct that scrum is a terrible methodology for building a bridge. And waterfall is a terrible methodology for building a startup.
Scrum/Agile (when properly used) has two main purposes... to better predict delivery of a particular technical capability (ie: when can I ship feature "foo" to customer "xyz"), and focus on keeping the product under development in a shippable state throughout the development process (ie: even though feature "foo" isn't done, I can still ship A, B, and C with minimal incremental work).
Waterfall is pretty much the opposite of incremental delivery, and in my experience does a poor job of predicting delivery dates.
If you are in a problem domain where you have hard requirements up front, a hard deadline, extremely well known technologies, then you are effectively building a bridge.
Break out the gantt charts, put a flag in the ground that says: "We're doing Waterfall" and be proud of it. But please try to avoid muddying the waters of scrum when you're using a tool for something it wasn't designed for and getting poor results.
My experience with agile/scrum is that it puts a more important bounding function on the product/biz side, where they place demands. The most effective scrum meetings I've seen have been where the biz side presents its desires, then the engineers give them actual level of effort, then the biz side decides _right then_ that they didn't care as much about this feature or that. That's an incredible improvement over documents whizzing this way and that, meetings, spreadsheets with LoE. Instead, just a quick meeting of minds.
"I want the blue button very, very badly."
"no problem. it will take three of us the entire scrum"
"my goodness, I didn't want it that much. Ok, punted."
"Scrum/Agile (when properly used) has two main purposes... to better predict delivery of a particular technical capability (ie: when can I ship feature "foo" to customer "xyz"), and focus on keeping the product under development in a shippable state throughout the development process (ie: even though feature "foo" isn't done, I can still ship A, B, and C with minimal incremental work)."
A lot of people think that those are the core purposes of agile.... and that's part of the problem.
The real core purpose of agile is shortening the feedback loop. If you aren't shortening the feedback loop you are wasting your time.
I think the OP's mindset is flawed and perhaps had some bad experiences/coaches with Scrum and possibly only one go at it?
I'm not sure why anyone would say "Scrum doesn't want to solve this". When I've worked with teams new to Scrum and the question "how does this fit into Scrum?" comes up, I'll discuss with the team and we come to a pragmatic agreement that is right for the situation and context. Similar to TDD, I think it's great but it's not always the right approach in 100% of situations; adapt it to your needs.
All methodologies have their flaws and Scrum can sometimes frustrate me (I'm not a purist) but I definitely prefer it to waterfall. Mature teams take the bits that work for them and improve on the ones that don't. It seems the OP is taking the methodology too literally which implies a lack of experience in trying to apply it.
I've tried (and failed) to get a team to work on a feature as a team, refactoring as they go. This didn't work, not because of the methodology, but because the team just couldn't get their heads round it. We decided this was fine and worked on UX a sprint ahead (and built this into the definition of ready). A methodology should not have to cater for every personality and set of skills - that's down to you as a team to figure that out.
Teams at first won't organise themselves but once they start taking true accountability for their work (and not keep looking to a project manager for direction) I've seen teams start to get more efficient and more motivated because they get to take control of their work and define the process.
I pretty sure you're not doing this here, but there's a lot of options outside of the set of Waterfall & Scrum. All too often when scrum is debated it's often set up in the "well, at least it's better than waterfall!" argument. Great, that might be the case - I'd rather a kick in the ass than the nuts but really I'd prefer neither :)
"the methodology too literally"
As the saying goes, "how big is your but" - because everyone does scrum-but. I'm not a fan of scrum in general, but once the but becomes large enough "scrum" and i can be friends again. The purists drive me bonkers though.
I think when most people talk about agile, or any specific instantiation of it, all they mean is "we're going to not-do-waterfall, and then intuit the rest, while attaching names from some methodology book to whatever results."
I think my statement about waterfall is misplaced - really I mean the benefits of scrum in my experience outweigh the negatives but I can't say the same for waterfall.
I'm well aware of alternatives to Scrum and if I could choose I would prefer a kanban approach supporting continuous delivery/deployment; rather than be bound by all the constraints of the scrum ceremonies and sprint timelines. Hopefully I'll get to put this into practice in the next couple of months with my team.
I don't know why we are obsessed with that bogey man. While there are some places that use waterfall, sometimes with good reason (things where the spec is critical), the most common state of unenlightened software engineering certainly isn't to have big design up front. It's to have design on a napkin and lousy communication with stakeholders, more wild west than waterfall.
Scrum is here NOT to solving ANY of YOURS problems. It's like a car - it's give you ability to drive, but how you drive is up to you. If you can't drive - you drive nowhere. If the street is broken - you can't drive, too.
What Scrum do, based on it's pillars (Scrum Theory, http://www.scrumguides.org/scrum-guide.html), is ability (and force you) to solve your own problems. Not more. OK, there are some preventive things and some sort of problems just don't happen with Scrum (if you can drive, of course), but it's not goal of Scrum.
And because, I think, there is no alibis at all. It's just disability to drive.
/Scrum Master && Developer, who fight against large organization every f* day for ability to drive/
I felt the typo was one where I had to do a double-take and make sure it wasn't some purposeful acronym. So, I posted a quick note since it looked like the HN poster also was the article writer, and my comment would drift to the bottom quickly and wouldn't get too far in the way of a larger discussion.
I could see maybe I should have made my comment more verbose so someone wouldn't interpret it as being short or something? Or is there an unwritten rule about not making quick editorial comments?
> Hey curious about downvote (honestly, want to know why). I didn't see anything saying that was a bad idea in the HN guidelines
I didn't downvote the typo comment but I find it odd you would read through the guidelines to see if commenting about typos is taboo but failed to notice it says Resist commenting about being downvoted. It never does any good, and it makes boring reading.
I've noticed, in 30 years of software development experience, that a lot of new-fangled psychological/management "innovations" exist primarily to provide justifications for bad behaviour.
Scrum being perceived this way is hardly surprising - its hard to develop a methodology for anything where responsibility and control are arbitrated in a fashion that gives the user (of the methodology) more of each component. Taking full responsibility for things is not the same thing as having alibis for when things "inevitably" go wrong .. if the methodology is a defense mechanism from the damage that occurs when projects overrun, its not going to be as effective at actually pushing projects through as it were if it were an attack mechanism for how to make things go right, no matter what happens. Alas, being effective versus being effected, is whats at play here. Few of us actually want to face the fact of our own failing, unless of course we 'predict it' in some fashion, first of all - and therefore create the conditions for failure to occur, 'comfortably'.
But like all tooling and methodology, it is a matter of the original intention of the user that counts. If you're adopting Scrum to save your ass 'in case things go wrong', you're doing it wrong already. If you're adopting it 'to make things go right, and do things properly', then you're doing it right. The only difference is the intention of those adopting the methodology.
There is a reason scrum sounds so close to bum, because they are both full of shit.
Whilst the mediocre teams in the crap organisations lurch from methodology to methodology, paying consultants to lie to them in the vain hope of improvement, the rest of us quietly and quickly deliver software of value to our clients.
The only good to come from scrum is more fucked projects for professionals to clean up later at decent profit.
I love that you weren't brave enough to make this comment on a legit account and take the downvotes there. Bravo (brava?) to you.
I agree that there are teams that struggle with Agile/scrum, but those struggles and failures generally have more to do with overall company culture than they do with the teams themselves.
Get a good Scrum master, with appropriate chops, a spine, and good people management skills, and you will have yourself a good scrum team. Full stop. Halfway embrace the process by letting your dev manager run scrum, or let your POs bully the team into things that aren't realistic, and you will have failure. It's as simple as that. Whatever project management methodology you choose has to be committed to fully for it to succeed. There's a reason why Project Management exists as a job outside of software development.
And you're fooling yourself if you really think that that superheroic "more fucked projects for professionals to clean up" line is buying you any credibility. I've seen more fucked projects and mountains of technical debt come out of "professional" clowns that swoop in to "fix" shit than I care to relate.
I love these threads, because you get to see a bunch of "* coaches" with a financial stake in these ideas scramble to justify their existence in the comments.
Then you won't be able to do scrum. You have a waterfall built into your development process: requirements and designs are generated and committed to on the customer side, then "fall down to" the consulting development team.
Scrum (or, really, any methodology that attempts to keep time constant by managing scope) is an iterated conversation between the people who want things, and the people who make things. If the people who want things aren't at the table, you can't have that conversation, and so you can't control scope. Period.