When I took over development of a extremely dysfunctional engeering team at an established startup with 100 people, the first thing I did (after watching for a bit to learn) was put in scrum. It worked. And it worked really, really well.
2 years later, it didn't work anymore. The team had matured, the organization itself had adapted to the leaner processes and mindset and, in time, the actual scrum process was too much. It was time to change again...
And that is something I think most agile advocates don't realize. Agile should be viewed as an organizational tool that has prescripted and prescribed rules that work in general, but maybe don't work in the specific. It is great if you need something forceful with books or documentation in the beginning, but in time, the organization should mature to the point where agile/scrum/whatever is actually too much.
One last thought. I highly recommend people look at agile for the times when you need a drop in process....but there is absolutely no subsitute for hiring quality people capable of making good decisions. Agile will get more out of bad developers, IMO, but having nothing and good developers you trust is always going to be more productive.
I think your last point is key. You can't use process to turn a bad programmer into a mediocre one - any process that does will also turn a great programmer into just a mediocre one.
That's cowboy programmer bullshit., the kind of thing mediocre but cocky programmers tell themselves to justify primadonna behaviour
"having nothing and good developers you trust" is either a recipe for disaster, or a short prelude to those good developers coming up with a minimal ad hoc process that fits the project and most likely is remarkably similar to one established Agile methodology or another.
Here is another perfect examplee of what's wrong with SCRUM, it creates zealots. When someone starts talking about a need to give good, self-disciplined devs a little freedom instead of micromanaging them to death the scrum zombies start shouting about "cowboy programmers". When someone starts talking about long-term or strategic planning they start screaming about "waterfall".
The truth is that there is a lot of evidence from the field that having good developers and zero formal process is actually fairly workable, and often produces results. It's typically not the best system, but it's a strong antidote to the poisonous ideas of SCRUM, which holds that constant micromanaging at every level is strictly necessary otherwise puppies will die.
There are good elements within agile, such as iterative development, continuous integration, etc. but if you just choke down a whole ideology without exercising any degree of critical thought then you're going to make a lot of people miserable.
Good developers+zero formal process only works to a certain scale, though. I think that's where scrum might have a place, just enough process to keep things from going off the rails when the team is too big to self-organize over a long period of time.
Agree about the danger of zealotry though. Also, the vocabulary is just so ridiculous - I have to mentally think "black dog grooming" when I say "backlog grooming" just to keep my self-respect.
It also depends on the nature of the work. Is it more mechanical, a more-or-less straightforward implementation of a spec? Or does it require real creativity, invention, non-linear thinking? Anyone who truly understands the creative process knows you have to give it freedom.
Scrum might have valuable in big hierarchical companies or when there are many average-talent programmers, but there's no way I'd foist it on a team of smart developers much less and early stage startup.
Scrum is pretty much exactly the opposite of what you apparently think it is. Is is ALL ABOUT giving the developers freedom and and inteded exactly for projects that require creativity and don't have a spect to implement straightforwardly.
The truth is that there is a lot of evidence from the field that having good developers and zero formal process is actually fairly workable, and often produces results.
It's typically not the best system, but it's a strong antidote to the poisonous ideas of SCRUM, which holds that constant micromanaging at every level is strictly necessary otherwise puppies will die.
If you've got a team claiming their doing Scrum where you see constant micromanaging - that team is not doing Scrum. At the very core of Scrum is the idea that the team organise their own work (within the very few practices that Scrum enforces).
(Obniggle: Scrum is not an acronym you don't need to SHOUT :-)
You obviously have no idea whatsoever what you are talking about. Please actually do some reading about what SCRUM is before you spread this kind of FUD.
I completely disagree [1]. There's a difference between a cowboy programmer and a programmer that can go more than a day or two without checking in with his superior. In my personal opinion, based on the level of intelligence required to do good programming, the best programmers are self-managing.
As a corollary to that, it's too expensive to hire development managers (in the traditional "management" sense) that can actually add value. Good programmers are that good.
[1] I've fired every cowboy coder that ever worked for me except one.
Actually, you completely agree with me. A Scrum Team very explicitly is self-managing. Agile processes ARE frameworks for coordinating self-management at the team level, and which have been found to work repeatably. That doesn't mean a given one will work everywhere. Specifically, Scrum is probably not ideal for startups doing something truly new, since it assumes there is someone who can prioritize features by their business value.
Why would you tell somebody that they completely agree with you when they just said that they disagreed? That's so rude. You say "That's cowboy programmer bullshit", he says "I completely disagree." Do you really think there's a chance he secretly agrees that his view is "cowboy programmer bullshit"?
In Scrum, superiors check in once per sprint at the end of one / beginning of next, unless they want to change priorities (not plans, priorities) for the team and cancel previously requestd delverables.
Isn't that just a No True Scotsman argument? You're saying that Agile is good because it's isomorphic to any successful, minimal ad hoc process that fits the project. Well, OK, if that's your defintion of "Agile".
But the "Agile" (rather "Scrum") described in books and web videos and blog posts isn't like that at all. It has become a decidedly "heavy" process with all sorts of jargon behind it. My guess is that this is what the linked post was talking about, and not your "Agile==good" metadefinition.
I know - it does come across as the one-true-scotsman argument at times.
Disclaimer: I'm a fan of agile. I even seem to be turning into one of those evil consultant people in my old age (but only just recently - and I still code :-)
I'd urge agile sceptics to put aside some of the crap they see in the real world. Go take a look at the original sources (e.g. both of Beck's books on XP are fun reads - and short :-). Take a look at the Scrum guide (http://www.scrum.org/Scrum-Guides) - it's only 16 pages long. Does that look like a heavy process?
Agile got popular in the early 00's coz it helped many teams get better. It then suffered the curse of getting popular. Everybody and their dog started doing it badly, or relabelling what they were doing already as agile. Pretty much every agile method came from developers. XP in particular was process that came from developers observing what worked well for them. Ditto Cockburn's Crystal methods. Scrum worked so well because it kept management out of the loop during sprint development (and that's also one of it's failings... but that's a different argument :-)
To pick a pure development analogy. Large chunks of the OO code I see isn't really OO code. It's some procedural code and some pure data structures wrapped up into classes and methods. Because of this it doesn't reap the benefits that good OO code provides.
Because I've seen good OO code, and because I can write vaguely decent OO code, I can see that. I can see the difference between the surface artefacts (classes and methods) and the underlying philosophy of an OO breakdown.
It's the same deal with agile a the moment. There are lots of places that are "doing agile" that are only touching upon a couple of the surface artefacts, but not actually making any of the philosophical changes that mean they build better code.
For me this doesn't mean agile sucks, any more than it means object-orientation sucks.
I'm sorry - I could have been clearer. The point I was trying to make was that the process of reading to determine whether it is a heavy weight process is not an onerous one.
You're yelling at the wrong guy. What @debacle said was "You can't use process to turn a bad programmer into a mediocre one - any process that does will also turn a great programmer into just a mediocre one." That's decidedly not "cowboy programmer bullshit". If your response was directed at @fingerprinter's statement that "having nothing and good developers you trust is always going to be more productive", then maybe you should have been rude to him instead of @debacle.
I think @debacle nailed it. One of the major problems with all the processes I've ever seen is that people (large corporations, mostly) expect them to solve the problem of having teams made of bad or mediocre programmers. It's quite similar to the idea that you can solve just about any problem with technology.
No it's not. It's pretty well documented in the scientific literature that making people who've mastered something (eg. doctors, airline pilots) work from intuition a lot of the time, so following a set of prescriptive rules inhibits their performance.
If you're still learning how to do things, then how-tos, recipes and best practices like Scrum will help.
Respectfully, I think that an established startup with 100 people is a bit of an oxymoron.
I know that no company ever wants to think of itself as "big and established", in fact my previous company had been around for 13 years, had hundreds of millions in revenue and almost 1k employees and they still liked to pretend they were a disruptive startup.
That was an excellent observation. I like to explain the phenomenon you observed using queuing theory - As time went on, each of you (and you yourself) were able to estimate tasks very, very accurately. I'd like to think that this was a period of low attrition.. but even if it was not, you were able to model the behavior of a 100 employees (a large enough set) to come up with good estimates.
An agile/scrum process is designed to work with tasks of inaccurate estimates - the whole business of story points is designed around that fact. Since your underlying phenomenon changed, the process was no longer optimal.
I'm not sure if you experimented with your own "lean" inventions beyond agile - single queues, multiple queues, queues with an artificial stop signal to reduce variance, etc. - but it would have been interesting.
Agile should also be subject to Agile. I like to think of it in terms of the Viable System Model in which the system has the potential to change itself based upon feedback. Put another way - make sure your implementation of Agile/Scrum supports tail call optimization and macro expansion or face the reality of being stuck in BlubScrum.
Agile is a toolbox of best practices and tricks. You need to use the ones that make sense. That is formalised in methodologies like SCRUM by doing a retrospective after each sprint.
For inexperimented teams, it is a good idea to start with out-of-the-box scrum and remove/replace bits that are not working out for team after a while.
For experimented teams, you just start with just a daily scrum end of day and add bits as you go along. (effectively start with 1 day iteration)
* XP folk very explicitly state that you shouldn't be "doing XP" N months down the road. You should be optimising your process
* The Kanban/Lean folks whole method is about having a process for process improvement
* Scrum very explicitly has Sprint retrospective and reviews aimed at looking what happened and changing the process to improve results next time.
* Crystal is all about aligning the amount of process you do to the working context you're in.
Of all the agile processes Scrum is really the only one that says you must do certain things in a certain way - and even there it's a very light framework of five events and three artefacts) that gives you a space to figure out your own process in.
I've done a bunch of reading about Scrum. If you read between the lines, you realize that Scrum was created and popularized by consultants who go into dysfunctional teams/organizations, and tries to fix the worse problems. For example, the idea of a sprint is for a team to be able to work for at least a couple weeks on a single thing, without people being asked to work on other "small" projects, or without the entire direction of development changing every week.
Once the team is functioning well, you can usefully relax a lot of the aspects of Scrum.
After a bit of experience with scrum, one of the things I"ve come to appreciate is that it's not a one-size-fits-all methodology. I think the spirit of scrum (break work into chunks, have working code at each stake in the ground, define a project in terms of user stories, etc) is more important than the letter of the law, and being able to tailor the process to your current reality is more valuable than dogmatic adherence to some prescription.
Scrum is by and for management, not developers. Want your devs in at 9am? No problem, hold the standup then. Want to easily replace your dev team with an outsourced one? No problem, a Scrum team is a black box as far as the rest of the organization is concerned, one with a well-documented interface. Etc, etc.
Ir's insidious because it tricks devs into thinking it's for them.
What does management want anyway? Do they want a black box with a well defined interface? What other options do they get?
It seems to me that this question depends very much on the kinds of commitments management is making. Which in turn depends on whom they are making them to. If it's to a customer that has some hard requirements, enumerated in a contract, and providing those is the source of money, then management's focus is (and should be) executing those requirements. Which would seem to imply that a black box is just fine.
The problem is not the desire for a black box approach, but that boxes fail. Management is risk averse (and their risk aversion is what keeps your paycheck coming, in theory).
(Actually, black boxes are creeping into software development all of the time. For example, there's no reason to not have fast PSD-to-HTML turn-around anymore. That process has been black-boxed. Not shrink-wrapped, but black-boxed. Yes, there are still quality variations, questionable use of excessive markup, etc, but its not bad.)
Anyway, I just question your tacit assumption that management wanting a black box with a well defined interface is a bad thing. It seems like a reasonable goal.
It's not healthy for the organization as a whole if the only point of contact between "the business" and the developers is enshrined in the Product Owner. It is however very amenable to empire building and short-term cost savings, both of which are examples of a manager favouring their own interests over that of the organization. In short, Scrum is most useful for those for whom a dysfunctional organization is their goal. That the turkeys (devs) are voting for Christmas themselves is the icing on the cake.
Um, one of the first rules of scrum is that management is not invited to the Standup. Scrum is a process for a team to communicate effectively with each other and their customers.
I think you're being a bit generous. The consultants who sell "Agile" to dysfunctional organizations are the same ones who sold every fad methodology that preceded it to those same dysfunctional organizations.
This is a really interesting insight. I have seen so many instances of prescriptive Scrum with no explanation as to why that it's appropriate, i.e. Cargo Culting.
Without trying to be inflammatory, this is no way qualifies you to speak with any authority on Scrum, or indeed any topic where your experience amounts to nothing more than a bunch of reading.
That is not to say that you don't make any valid points. I think the fundamental tenets could be relaxed over time, but I guess with some organisations when you start removing some of the restrictions you'll eventually remove more and more until you're back where you started.
> With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint,
No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating.
> Iteration planning meetings are seriously expensive.
Then you're doing it wrong (god, I feel awful for saying that). If you're spending that much time in pre-sprint planning, people aren't bringing enough to the table and you're not defining your problems well enough before trying to solve them.
> I hate the term “scrum-but”.
Ironic that that sounds like exactly what the environment you were working in sounds like.
> This might be a bit controversial, but the big difference between Scrum and things like Lean Software Development for me were the difference of focusing on process versus delivery.
I think this is a "forest for the trees" issue. Scrum is about abstracting the process into a rigid and lightweight framework so you only have to think about it, at most, fifteen minutes a day (unless you have the misfortune of being the Scrum master/cat wrangler)
> It can’t, and it’s not a problem with your organization if it doesn’t. It’s a problem with Scrum.
That's a non-sequitur. It's a problem with neither. If my company can't implement a waterfall methodology because our clients require faster iteration, that doesn't mean there's a problem with either - it's just not a good fit.
But if your company tries to implement Scrum and throws it out six weeks or six months later because it's "too hard" or "bad," my assumption is that real Scrum probably wasn't happening.
Will Scrum work for everyone? Fuck no. Scrum is hard. It requires the kind of buy in that, if you've got it, you probably don't need Scrum anyway.
Can Scrum work for everyone? Probably. Scrum is only hard when you've got conflicting goals. If you have a smart enough team, you can tweak your sprint lengths from as little as a few days to as long as six to eight weeks, and after you've been on Scrum for a few sprints your planning meetings should take an hour or two, tops.
In my experience (six months at a job that does Scrum and, I think, does it very well), the thing that slows down iteration planning meetings is when the product manager hands down a one-sentence feature description, the engineers say “we can’t size that, it’s too vague”, and then you need a five-to-fifteen-minute discussion in order to expand that one sentence into something resembling a spec.
These are exactly the sort of problems that should show up in sprint retrospectives. Hopefully folk then generate ideas for solving them (e.g. PO breaking down stories further before the planning meeting, or devs getting more up to speed in the problem domain so they can grok brief feature descriptions more easily).
So - what's happening in your sprint retrospectives?
If the project manager throws out a feature description like that, just say "Yes" and throw it to the bottom of the backlog - it'll be revisited when it's well defined.
The product backlog? The engineers don't control the product backlog.
This strategy falls flat when the PM committed to a stakeholder that they'd get a feature done without defining it well or resolving dependencies, so now we have to sit for 15 minutes hammering it out.
Note that I'm not totally disagreeing, but textbook scrum and what-happens-when-people-spend-a-lot-of-money-to-develop-something scrum often diverge greatly.
The ultimate business purpose of scrum is to manage expectations. What's going to be done, when's it going to be done, if something's stuck who is responsible, etc. If the PM starts making wild promises and setting crazy expectations -- which PMs are wont to do -- all the methodology in the world isn't going to save you.
No - because you're not the business owner and don't decide what order things go in the backlog.
A better way is to just give a sufficiently large estimate: "That's 100 points* due to risk and uncertainty." If they want a more detailed estimate, then they have to give a more detailed story.
This is one of the best things an older programmer has taught me. If people want estimations on vague things, give them 8 month full team full time. Minimum. Doesn't matter what it is. Implement a new, small feature? 8 month. Move the office furniture around? 8 month. People talking to you learn quickly to give out more precise specifications.
I should point out that just throwing out a 100 point story over nothing is a bad plan career-wise - you definitely need to be able to back it up with reasons (we need to interface with systems x, y and z, this is comparable to other system w which took 8 months, we don't have any spec for doing a, b or c).
In that sense the 100 point estimate is a real one - a "small" feature (eg. add a form to your web site) might be two or three weeks of work.
“A bad system, will defeat a good person, every time.”
-- Deming
I can no longer count how often I heard "you're doing it wrong" when people explain why scrum didn't work for them or when they feel there needs to be something that works 'better'.
Getting Scrum right is hard. Managing huge backlogs is hard. Doing time-based sprint plannings is hard, especially if you are working on stuff that is either new or new to your team.
If you are doing routine work you might as well use waterfall or "jfdi" as your approach. Burn-down charts, velocity and sprint planning doesn't help if you just don't know where the next problem will be or when your team variation changes constantly (people move to other teams, new people join, people get sick, …).
I've found that changing/being able to change the 'system' (scrum) to something else that works better (agile/lean to its roots, kanban, different stand-up meeting format, evidence based time-tracking, value-flow …) is way more effective than changing the people to become 'better' at Scrum and doing it less 'wrong'.
>It requires the kind of buy in that, if you've got it, you probably don't need Scrum anyway.
I agreed up until this. I worked for a company that was doing waterfall and miserable. Things were getting done, but it was a sloppy mess. Clearly we didn't have our stuff together.
Our manager went and took scrum classes, and then we spent a few months trying it out. There was no day-one benefit, but over those months we managed to wrangle things around until everyone was on the same page. After that, things went a lot smoother. Management was actually planning things out (instead of just throwing projects around and hoping) and we had a clear view of what we would be working on at any given time. Shared resources, like the sysadmin and network admin and db admin, were able to be scheduled more effectively instead of project waiting on them, or them sitting around doing nothing.
So no, I don't think that Scrum requires the kind of buy-in that indicates you don't need Scrum in the first place.
No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating.
"The two parts of the Sprint Planning Meeting answer the
following questions, respectively:
What will be delivered in the Increment resulting from the upcoming Sprint?
How will the work needed to deliver the Increment be achieved?"
The commitment on delivering a certain chunk of work has been one of the more controversial elements of Scrum. Many people who say they're doing Scrum don't do this. But it is very definitely part of the Scrum process as defined.
> > With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint,
> No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven.
Of course there is. There is no burn-down, no 'time', without tasks. So while in a pedantic sense you're right that you commit to 'time', time is measured in stories.
Substitute one for the other. The people depending on your delivery don't understand (or care) that you're doing a x-point sprint, they care that their feature is delivered.
If they "don't understand (or care) that you're doing a x-point sprint", then you have big problems, since they have to choose 'x' points worth of stories to put into a sprint, and that's one of their two key responsibilities.
Also, you cannot substitute points for stories - that's the whole point of the estimation process. (and also a large part of why software projects fail. "Doing 'A' is 10x harder than doing 'B'" seems to be hard to understand until you have points to spend).
I find this thread fascinating as Scrum actually says nothing about stories, or points, or hours. It also says nothing about the estimation process that the team should use. It also says nothing about the process to be used to select the sprint goal and the PBIs to be completed in the sprint.
All Scrum says is that:
1) there are things on the backlog (it doesn't specific what product backlog items are or should be - they could be user stories, they could be old-fashioned requirements docs, they could be use cases - Scrum doesn't care).
2) there is a Sprint Planning Meeting where the team and the product owner agree what the sprint goal is and the team forecasts the Product Backlog items it will deliver to meet that sprint goal.
The rest is up to the team.
Teams decide to track hours or points or story counting. Teams decide whether an estimation process is useful.
Also, you cannot substitute points for stories - that's the whole point of the estimation process. (and also a large part of why software projects fail. "Doing 'A' is 10x harder than doing 'B'" seems to be hard to understand until you have points to spend
Many teams can and do just count stories. Folk like Ron Jeffries who invented the point counting / velocity concept now prefer and recommend story counting. There's a whole group of folk who eschew estimating entirely (See stuff like naked planning for example http://aaron.sanders.name/agile-fashion/naked-planning-expla...).
The problem with SCRUM is that it is not agile.
That's why we see most of the pragmatic companies adopting a kanban or scrumban approach and they see good results.
I would argue that just having a kanban board during stand-up meetings and "walking the board" instead of interrogation-like status reporting is going to do wonders to team collaboration atmosphere, morale and actual productivity.
You start to see and talk about the flow of value, what's next, what's in the moment ("what can we do right now?). You see context. All of that is missing with SCRUM or only possible with a highly motivated and responsible team that communicates a lot automatically.
I'm not yet saying that kanban is solving the software crisis [1] but it turned around quite a few teams that I've seen and been part of.
I might have a harsh tone in my previous comment but I've got really frustrated with scrum (or implementations of it) over the last few years.
Scrum in my eyes is a process and from what I've seen it makes teams very process oriented. The whole idea of scrum master certification and the success it had in enterprise adoption might have something to do with that.
It incentivises teams (at least all the teams I've seen) to work for the process as good as possible. They focus on complying to the process, getting estimates right (or working in a way that makes the estimates right), they focus on the backlog instead of throughput or frequent re-prioritization …
If you can free yourself from viewing the 'process' as fundamental religion it's easier to apply agile & lean principles like focusing on delivering value and improving the framework, changing things, changing the process so it fits your needs, etc.
In a nutshell: I see scrum incentivising people to work in a way that is not agile but pseudo-agile/feel-good-agile. I see no feedback loop for the process itself (at least I see no one doing that, except teams that adopt kanban and scrumban or do scrum but …).
But I'm interested in learning from people who've made other experiences. It's an exciting topic.
If a team fails to deliver the functionality they committed to, there are consequences. Before the next sprint starts, they figure out what went wrong and incorporate that knowledge going forward. That's feedback on the process. And whether they have a green sprint or a red one, their velocity on the sprint is measured and used to project forward. Again, that's feedback on the process. Then there is a actually a dedicated retrospective phase at the sprint review where the team gives specific feedback on how the process went. The whole point of having sprints is to ensure that there's frequent feedback on the team's performance, distinct from any feedback they get on the product itself.
Disclaimer: I actually use a kanbanish leanish approach myself myself. It's my preferred process for my current working context. I'm also very much not a fan of the Scrum certification process and what that has tended to produce in the industry. However:
I see no feedback loop for the process itself
Is just nonsense :-)
Scrum has only five events - and two of those are retrospectives (one on the increment, one on the process used). If you aren't inspecting and adapting the process then you are not doing Scrum.
Now I freely admit that one of the most common ways that people don't do Scrum is by skipping those steps. Then again it's also the most common way I see people do kanban/lean badly as well.
Certification is a gimmick. Scrum guidebooks don't say you need to get certified. You can buy a degree in Kanban too if you want. Is programming worthless because Java certification exists?
I've heard this before. I think the most simple reasoning there is that the Agile manifesto says: Individuals and interactions over processes and tools. In Scrum it is process over individuals. The process is what is important, not the individuals.
That's certainly not the intent behind Scrum though. The intent behind Scrum is to let the team within the sprint be pretty much completely free to implement whatever process they like to deliver the sprint goal. It's whole focus is to remove management interference from the main body of work the team does. PO figures out what needs doing. Team figures out the best way of doing it. Scrum provides a framework for accountability on both sides.
Scrum - done well - should be a tool to let the team figure out the best way to deliver.
I know that. The historical motivator is the 1986 paper, "The new new product development game". I think the difference in what happens in Scrum is that the team gets further isolated from an organization through the ScrumMaster and Product Owner and therefore has less ability to influence and more process imposed (the various invariable rituals of Scrum and more). The teams are now viewed as units of production, stick story in, get implementation out. Almost never will the Product Owner be really a product owner within the intention of Scrum and the ScrumMaster will drift towards a semi-team-lead role and his incentives are not aligned with those of the company or the team.
Agreed. That sort of setup does suck. But then again that sort of team isn't really doing Scrum (they're certainly ignoring the way the roles should work, and they're certainly not using the sprint retrospective to improve).
This isn't Agile sucking, or Scrum sucking. This is folks not doing Scrum sucking.
The issues that caused the OP to move from Scrum to a Lean approach - I can go with most of those (indeed they match my observations of some other transitions)... but the delivery one doesn't ring true in my experience. I've seen a bunch of Scrum teams with a laser like focus on delivery.
tosh has replied already, but I'll offer my explanation as well: Scrum is not Agile because it's all about ceremonies (the planning meeting, the daily standup). The only ceremony that brings some value to the project is the retrospective.
Just because something happens routinely doesn't make it ceremonial. You turn on your computer every day as you begin work. Is that a ceremony? You eat a meal every day. Is that a ceremony? Pay rent or make a house payment every month? More ceremony?
What you mean, I think, is that you don't see the value in the activity, or have some other aversion to it, so it's purely ceremonial to you. I assume (maybe incorrectly) that you do see the value in planning your work and communicating with your teammates, you just prefer not to do it on a regular schedule. I'd prefer not to make my house payment on a regular schedule either, but doing it every month ensures that a) I'm always making steady progress on my mortgage, and b) I don't caught in a cash flow bind when I suddenly have 6 months' worth of payments to catch up on.
You have a good point in that I don't see the value of imposing communication and forcing people into meetings, however why the straw man? Eating and paying rent definitely have a value, so why bring up the comparison?
Because communication and planning also have value, even according to you, as long as they aren't 'imposed'. But what is really being imposed here? Simply the timing, the regularity of the events. Just like eating or paying the rent.
The author is right that, with scrum you end up focusing more on process and not delivery.
There are nice things about scrum, but I think scrum followers are too doctrinaire. It has some well-defined practices and is associated with that agile "manifesto" that you are compelled to buy into if you adopt scrum. Being doctrinaire about anything is guaranteed to distance you from reality - you give project managers a weapon to coerce you into worrying about how to break down your work into a velocity and stories and tasks. Any time you enforce a process like that, you are disengaging yourself from the reality of having to ship something.
Scrum is focused almost exclusively on delivery. Every sprint, you should be delivering working features. It's not that hard: every sprint, you commit to a set of stories to finish before the next sprint. Every day you meet briefly to tell everyone how you're progressing and to air out any impediments. That's about it. To me, scrum is stripping process down to the bare minimum you need to be effective.
Haha, that is only true for a certain type of person. For other people Scrum becomes about "the rules" and if you break one of the rules, you're doing it wrong, even if that might be the best decision at the time.
Agile is a philosophy, Scrum is meant to be more of a framework to implement that philosophy, but many people treat it as a set of rules on how to do things, which tends to violate the philosophy of Agile process in the first place.
In that regard, how is scrum different from anything ever? Anyone can be process obsessed in any system. And, dare I say it, giving a process to Asperger, socially tone-deaf, shoe-staring programmers may help them contribute more effectively to a larger organization.
And it's fantastic when you're on a tight schedule! Instead of running fast all the time, you just sprint, then sprint, then sprint, etc! Works like magic. No one burns out at all.
I don't know if you meant that in a sarcastic way, but this does touch on a pet peeve of mine with Scrum, the word "sprint" is, by definition, not a sustainable pace.
Well... yeah! if you get some other core parts of scrum right then nobody should be burning out. Time boxing and point estimation are about figuring out what your team's sustainable pace is and using that to avoid burnout. Scrum isn't about developing faster its about working toward more sustainable and predictable development. If your management doesn't understand that and respect it no methodology will fix your problem.
I admit as someone else mentioned that sprint was a poor choice of words. So say iteration instead. Problem solved.
Not quite. You sprint, then you take time to review and reflect on what you've done. Then you take time to plan what you're going to do next. Then you sprint again.
Change it to two days. When do you squeeze in your retrospective? Your presentation of the deliverable to stakholders? Negotiating next sprint commitments? Researching before you do estimation?
You can, however, strip it down even further and still be effective. Scrum encourages bundling stories into sets and delivering them all at once. I've been moving away from that, and continuously delivering discrete stories/features/changes/fixes/whatever as they are ready.
Decoupling incrementalism from iterations has been a huge change for me.
Different continuous delivery teams do it differently. I don't like having a dedicated QA team/department. QA is an effort, not a role.
The key part of continuous delivery is that the safest change to make to a stable system is the smallest change possible.
So instead of batching up lots and lots of stuff and throwing it over the wall to QA, you make one change, have humans and robots test it, and deploy that change. The mindset shifts from "features per release" to "releases per feature" so with truly friction-less automated deployments, you can release very small changes individually. You don't have to test everything in order to change anything.
As you may expect, multiple layers of test automation are necessary. Each change runs a gauntlet of different kinds of tests before release. A set of "safe to run in production" tests immediately after release. Rollbacks are trivial, but exceedingly rare.
Obviously, this only works in some contexts. If you're pressing things onto gold master DVDs and shipping them in boxes, the QA effort will be more traditional.
Your automatic (unit, functional, system) tests assure stuff doesn't break (too much), and manual QA happens after deploying. If something is broken, you can fix it very fast, since you are deploying continuously.
Stuff might sometimes be broken on production, but you could argue this makes people think twice before pushing to master.
Also, you can deploy to production with a delay (e.g. 1h) and deploy to a QA server first to give the QA people some time to check before stuff goes to production.
I've never done formal scrum, but I've worked on a lot of teams, and I just don't see how there is a single bare minimum you need to be effective. In my experience, even with excellent teams, this depends on the project and the talents of the contributors.
To me, the bare minimum for success in software development is clear direction, continuous communication, and continuous verification of the product. Scrum is a simple process to ensure that all three actually occur and aren't merely good intentions left up to individual discretion. I guess you could come up with alternatives, but it would be tough to make it much simpler and still cover all three.
I've done formal scrum before, and I can see where you're coming from, but my experience scrum didn't ensure continuous communication. The company where I worked actually actively prevented cross-team communication. They did this because the scrum masters and director of engineering claimed it would generate work that couldn't be captured by stories, so velocity couldn't be accurately tracked and people's time could be spent on the "wrong" things. I took as project managers not trusting the engineers to do their jobs.
Again, I don't think scrum is all bad, nor do I think it's hard to grok or follow. It's how people adhere to it, and in my experience, people really adhere to it in a way that's detrimental to productivity. For me, it's kind of like religion - I like some of the ideas, but I don't like the fan club.
Not sure I understand the communication policy you guys were dealing with. If a team is meeting briefly every day and sharing their progress, it ensures that there's at least that much communication. But the daily standup should be a floor on communicating, not a ceiling.
FTA: Scrum forces iterations, forces feedback, forces smaller iterations. These are all good things, which I loved about Scrum.
And yet the author spends most of the article denying that these aspects of scrum are useful at all. Planning sessions are "highly inefficient," a "quick meeting between the architect and the developer" is better. What if someone else has an important piece of information that the dev and the architect don't? Maybe another dev on the team has done something similar in the past, and could have warned that the estimate was low? He won't be in that meeting, to avoid being "bored to tears" with a story he isn't working on.
So how do you know if Scrum isn’t right for you? If it’s hard. If it’s easy, then it will work for you.
Obviously, if something is hard, there can't be any possible benefit to it. It's so much easier to get rid of all that process stuff and just churn out code as fast as you can. What could possibly go wrong?
The author has a point. Scrum is costly. Obviously it is more productive to silo specific knowledge to specific people, generally the expert (or more motivated) in that field.
At least it is in the beginning. People leave, experts become expert teams, silos widen and it soon become the good old planning nightmare we have all learned to "love" in enterprise development.
I would prefer Scrum can be costly... it will also remain costly if people don't actually do the inspect and adapt bits of scrum and aim to improve the process.
I say this as somebody who is actually not a huge fan of Scrum :-)
Obviously it is more productive to silo specific knowledge to specific people, generally the expert (or more motivated) in that field.
Actually - I often find that isn't true. If you silo knowledge then those people become bottlenecks in the process. Since their the only people everything has to flow through them that relates to that topic.
For example I find that teams improve if the "UX Expert" switches from being the person who does all of the UX work, to being the person who facilitates UX work among the whole team.
That way the easy stuff gets done by the whole team, and the UX person is freed up to focus on the tricky stuff and stops being a bottleneck for general progress on the UX front.
But it's not costing me much. My devs still need to be in on planning their own work, and if they're all on the same scrum there should be a lot of overlap. Listening in on the planning for work entirely unrelated to their own should be pretty rare.
> Iteration planning meetings are seriously expensive.
I completely agree on this one. I've worked in several corporate environments utilizing Srum and the planning meetings were always a huge waste of time. I would rather light my hair on fire than sit around a bunch of PM's trying to figure out what features to include/exclude.
Also, most of the people (PM's,Dev's,IA's) I talk to always say, "Nobody does Scrum/Agile right anyways." Which made me wonder if there is indeed a right and wrong way to do these.
In my experience most teams do planning completely wrong. The goals of the planning meeting are simply:
1. Do a relative-size estimate the top n stories in the backlog. (Where n is
some number slightly larger than the number of stories that usually fit
in an iteration.)
2. Pick the stories to complete in the iteration.
That's it.
I often see teams:
* doing one-by-one story estimation, and debating over how many points to assign.
(The statistical method completely fails when it's done this way.)
* getting into long discussions over the spec. (That's between the dev
and product owner, to be figured out during the iteration.)
* worrying too much about accurate estimates
* worrying too much about how much work to take on
I think the reason this happens is because no matter what people say, the idea that if you can't finish a story within a sprint it will simply slide into the next one is anathema.
People spend more time on estimation when the consequences of mistakes are higher. If you can't realize that a story is larger than you thought and reprioritize mid-sprint without it being equivalent to missing a deadline in your old model, it's not going to work. In my experience this is the key failure mode of scrum.
Do you really think one-by-one story estimation is that bad? At Kongregate it's about 8 people doing it, for 45 minutes or so every couple of weeks. It isn't the most fun thing in the world, but I do think it's helpful to spend between 30 seconds and a few minutes talking about how hard something's going to be. If it seems hard, easier ways are often suggested...
If you're not looking at them one by one, what are you really doing? Why not just say all stories are the same difficulty?
The planning meeting isn't the right place to review the implementation approach of every story. That's best left to another discussion among the technical team, probably in a design review.[1]
Discussion isn't necessary for estimation purposes when the team agrees on effort. It's only necessary when the team can't agree where to rank the story's effort in relation to other stories, both completed and upcoming. (You need completed stories in there to "anchor" the story points, otherwise the meaning of a point will drift from iteration to iteration.) Once the team has ranked most stories, the team can return to those that they can't rank, and discuss them a little further until they can fit them into the rankings.
[1] It could be that the team isn't communicating enough, and that the planning meeting is the only time they're forced to communicate.
Perhaps it is the environment or Product Owners that are causing this slow down? Product Owners (PMs, etc.) should stack rank items in their backlog before a sprint planning meeting. This should make it fairly easy to allocate items for a sprint and identify features which either need to be 1. clarified, 2. split/scoped down. My sprint planning sessions have typically always gone smoothly as long as everyone came prepared and ready to contribute.
Iteration planning meetings are seriously expensive.
Group discussion around design, group estimation, group
acceptance, all highly inefficient. [...] I remember just
getting bored to tears listening to discussions around
stories I wasn’t developing on to begin with.
That's quite team size dependent. In a scrum team with 4 people this isn't a problem - but when the team's twice as large it doubles both the amount of work to plan and the hourly cost to assemble the entire team, quadrupling planning costs.
If a team is structured in such a way that a developer knows they won't be working on a story, that seems like a logical line for splitting into two scrum teams.
Every time I come across "why scrum sucks" articles like these I can quickly point the problem: the ScrumMaster.
#1 - Iterations are less efficient than pull-based approaches: A good ScrumMaster keeps an eye on the burndown chart and negotiates with the stakeholders and team to either add or remove tasks from a sprint. My first sprint ever as ScrumMaster, we estimated a 3 months project, we did everything in 2 sprints (1 month)
#2 – Iteration planning meetings were wasteful: You are doing them wrong. A good scrum master keeps everybody focus on one user story at a time and keeps the meeting moving. I use a 3 min stopwatch in my phone. The whole meeting should not take more than 1 hr (I do 30-45 mins estimate new stories, the rest to plan and commit team to next sprint)
#3 – Scrum is highly disruptive in established organizations: A good scrum master servers as a bridge between traditional management and keeps them out of the team's backs. This one is the reason I don't like being ScrumMaster anymore. A good ScrumMaster needs great people skills, I rather write code.
Companies still do project management, and the project manager is a single point of failure. The reason the failure rate is high is that scrum is relatively new and companies still think they can get away without having a scrum master, while they know from long experience that they need good project managers.
Actually what the author describes is a natural path of evolution for that team. Scrum (as a process) contains the possibility of changing the scrum rules themselves - although it is strongly recommended one does that only after they get experienced (e.g. they actually manage to get shippable product each iteration).
When the focus is on the process itself and not on delivery there is something rotten in Amsterdam.
Scrum can be a micro-manager's dream (think of the visibility on who is doing what at almost hourly level) - case in which one can end up with focus on the process not on result.
Minor counterpoint to the bit about meetings being boring: As a QA person, it is incredibly valuable to us to all be together so we can discuss things with the devs that are otherwise getting overlooked in bugtracking software or even in our chat. It makes it so that those orphaned problems can find a home.
But our meetings are short. 5 or 10 minutes max. If you're getting bored than, to quote another commenter here, you're doing it wrong. Quick summaries, major problems, then get out the door.
You haven't really jumped the shark with scrum until you have in place a scrum of scrums, and a scrum of scrum of scrums taking up half the day for all the key players.
I work at Webs and we also recently abandoned scrum for a more kanban approach. While all points in the article resonated with our company, the biggest problem we had was not delivering projects on time.
We focused too much on fitting as much work into a sprint as possible for maximized throughput. The problem with that, especially when you have alot of projects going on at the same time, is that alot of work was being burned across the board, but the needle for each individual projects didn't move forward fast enough and we ended up missing deadlines.
Another problem with scrum is that it turns creative developers into code monkeys, and this in turn lowers code quality. Developers are constantly worried about trying to meet deadlines for the next two weeks rather than taking the time to do things correctly. This ultimately creates technical debts and hurts the team in the end.
(also, if you're a manager and you use the developer points burned in order to rate performance and distribute bonus, then fuck you)
I very much agree with the last point. Objective evaluation of a developer is much more than burned down points.
I worked at Amazon and could see evidently that Scrum was turning good developers into mediocre ones. But not many raised a finger against it as Scrum was seen as the norm. And there was no scientific way to establish this fact.
In my experience, Scrum / Agile / XP tend to be more about the process than the results. I find these methodologies to be particularly useful for contractors and consultants, primarily because the value proposition for a consultant is much different than it is for an employee.
A consultant comes in and typically some sort of statement of work or master services agreement is agreed to by both parties, which outlines roughly the work that will be performed over the course of the engagement. Once work begins, some Agile hoops will be jumped through (storyboarding, etc) in order to further establish and agree upon the work that will be performed. This way, at the end of the engagement, when the consultant has been paid for 3/6/9 months of work, they can point back to what was agreed upon each step of the way and say, "See, we're delivering what was agreed upon way back when."
Employees at most software companies, and certainly at early-staging companies, don't work like this, nor should they. As a product engineer, your job is, in a nutshell, to figure out through software how to make the business work. There might be a high-level strategy laid out for you, there might not be. Either way, you're engaged in an inherently creative activity in order to devise and implement a solution to make users happy, and hopefully make money. Whether or not the employee delivered upon what was agreed to three months ago, or whatever the timeframe, is irrelevant (at least it should be).
The question should be, "Is your work having a positive impact on the business?". There is an inherent necessity to quantify "positive impact" when working with consultants, partly because they cost a lot more in the short-term, and partly because the nature of their work is generally less creative and more controlled.
So, if you trust the people you work with, and the company communicates it's vision well, IMO Scrum and Agile are too much procedural overhead. Of course, you have to meet those two conditions :)
I read through the first bunch of these comments and scanned the rest...you guys, you guys...
I might have missed it but I didn't see anything about client delivery that is viable...or do you have other reasons for being in the software game? Who really cares what process you use? As a client I want to be involved, I want to see how you're doing on an on-going basis, I want stuff that works well, I want stuff I can use and I want to alter by vision as you deliver because my business can change...
The larger the team, the more overhead is needed, no matter what system you are using. The real problem is that scrum doesn't scale as efficiently as more structured management systems, so the overhead grows much faster than in most other systems as team size increases.
ADDED: Conversely, with small teams, the overhead of more formal methods doesn't scale down; that is where less structured methods like scrum are most efficient.
OP mentions larger teams, so a 20-40 person team nets you around 22-45 seconds per person in a 15 min scrum. If we give each person 3 min that is a 1-2 hour scrum.
> a 20-40 person team nets you around 22-45 seconds per person in a 15 min scrum
Which is just one reason why you do not have 20-40 person teams in scrum. The team size top out at around 12, and yes, at that size you have to keep what you say at stand-up short and to the point. If you find a 20-40 person team, for scrum you will have to break it up into sub-teams.
Was he doing some variation of scrum? Some kind of scrumbut? I won't claim that scrumbut always fails, but it's not hard to spot where this went wrong.
"Fewer than three Development Team members decreases interaction and results in smaller productivity gains...Having more than nine members requires too much coordination." - Scrum Guide, page 6
Several comments about the notion that at some point you outgrow Scrum. For those who have reached this point, I'm curious what you've switched to? Or has it been more of simply relaxing some of the constraints/procedures? Asking because I've recently started to wonder if/when we'll need to modify our mostly-Scrum process.
The most common (productive) change I've seen is a move to something that's closer to the pull/kanban/lean approaches.
For example a pattern I've seen a few times goes something like this:
* Teams get good at breaking down and estimating backlog items, they tend to all become the same "size" and need about the same amount of "work"
* Product Owners get good at prioritising the work so that the most valuable stories are at the top of the queue
* Dev team and product owner turn have a collaborative relationship rather than a boss-minions relationship.
* The combination of those three factors means that the planning meeting basically turns into "we do the next N stories" where N is the number of stories you get done every sprint. So the utility of this meeting disappears.
* The process of work flowing through the team starts resembling single-piece flow. Everybody works on the next most important thing.
* People start continually delivering, rather that just being able to deliver at the end of the sprint.
* The last two points mean the utility of breaking work into sprints kind of vanishes.
* Everybody notices that they're doing flow-ish things rather than batch sprint-ish things and starts looking to the lean / kanban world for ways to optimise the process further.
We started doing Scrum around a year ago and it has worked well for us. I feel some of the points described in the article about Scrum are not because of the framework itself but because there could have been a lack of a Scrum Master, which is an important piece in the puzzle, to ensure Scrum effectiveness.
We need to drop the idea that there is THE methodology to organize software development. I like the approach of this post, but I would had prefered a little more context on the type of projects he manages.
A professional software manager should be able to identify the key aspects of a project, and with that define the methodology (borrowing from different aproaches and using different tools). Some projects require centralized design with a top-down approach, and more of a "programming workforce" self-coordinated with some progress metric. Other projects require more sophisticated engineering design, technical expertise imbued in a creative enviroment by a relatively small team of engineers/developers.
In my opinion, iteration is all about exploration. Scrum basically discards the role of a "designer" for the systems. But sometimes you need a designer.
Iteration planning meetings are seriously expensive.
Group discussion around design, group estimation, group
acceptance, all highly inefficient. [...] I remember just
getting bored to tears listening to discussions around
stories I wasn’t developing on to begin with.
That's quite team size dependent. In a scrum team with 4 people this isn't a problem - but when the team's twice as large it doubles both the amount of work to plan and the hourly cost to assemble the entire team, quadrupling planning costs.
If a team is structured in such a way that a developer knows they won't be working on a story, that seems like a logical line for splitting into two scrum teams.
Interesting points, but I feel that the root cause of these process debates is one un-natural act: estimation. Personal opinion is that far too much energy is put into processes to generate predictability, which is only practical when you have done it before, repeatedly.
All this focus on estimation, points, timing -- it just doesn't create what is needed to both do a great job and go fast: clarity.
This is why I don't run my shop with deadlines. I have no experience that deadlines/sprints/iterations make things faster, or create better ideas -- the things I'm actually interested in.
Excellent observations based on actual experience.
A refreshing change from the usual "I don't understand what agile is but I did something I called agile and it sucked so I'm now blogging about how agile is broken".
The #1 point mentioned in the article was my experience as well. For a tight deadline project if we decided to do everything based on the complexity points and team velocity it would take 6 sprints and a total of 3 months. But we just decided to ditch it and sit around a table and finished the whole thing in 2 weeks straight.
So my experience is that if you are working with a dedicated team it is better to finish the work based on the best of your ability rather than time boxing into some artificial time limits.
How would Scrum turn a 2 week project into 3 months? Are you just saying you were terrible at estimation, or what? I don't understand what you ditched, specifically, and how that produced an improvement.
In timeboxed iterations, you have to be very careful that work doesn't expand to fill all available time. If you are a little conservative with your estimates, its easy to double the time the necessary aspects of development would take. Little, unnecessary tweaks becomes more important than putting four hours into the stretch goal that is going to spill into the next sprint.
Six times is a bit much, though. That sounds like they haven't worked out their estimations yet.
Having a dedicated team is definitely important. I had a similar experience to yours and I am not entirely sure why.
I think a big part of it is that once you dig into complexity points and time estimates and all that other stuff, people tend to be on the safe side and add a lot of buffer. But when the whole team is in the hacking mentality and just wants to get sh*t done, you don't need to have everything in sprints. You just need a highly motivated and a dedicated team.
Are you trying to say the overhead of SCRUM would increase the time to 3 months? SCRUM is a lightweight framework, so I am struggling to see how this could happen. Alternatively, do you think the estimation with points was the main problem and you couldn't get a correct feel for doing it without resulting in a conservative estimate?
The fundamental thing I've realized while looking for "the optimal end-state process" is that it doesn't actually exist.
Scrum is, for many development organizations, an incremental improvement over what they are doing now. The biggest problem that I have with Scrum (and all prescriptive methodologies) is that it's presented as a vision for the right end-state instead of a set of tools that you can use to help find the right process for your immediate context.
I so agree with this. If there was such a ting as "100% scrum compliant" it would be a bad goal to strive for. Not because it is bad in itself, but because the process should be adjusted to the situation.
There seems to be some very scrum-savvy people here. I have used it many times, but I am interested in your thoughts about how designers typically work within that framework. In my experience design and scrum don't play very nicely together. Thoughts?
There are a bunch of folk (me included) who spend a lot of time thinking about getting UX and Agile folk to play nice together. You can find some of my rantings via lanyrd http://lanyrd.com/profile/adrianh/.
There's a stack of stuff under https://pinboard.in/u:adrianh/t:agile/t:ux that you may find interesting. Some of it may need filtering through my brain before you see the agile/ux connection though :-)
The UX track at Agile 2012 had a bunch of great sessions around getting UX and agile running well together (bias warning - I produced the track :-) http://agile2012.sched.org/overview/type/user+experience - I think all the sessions have slides now. Nag me if not.
Personally I'm finding UX works better outside of an iteration context with a more lean/kanban approach. The stuff Janice Fraser is doing at LUXr for example http://www.slideshare.net/clevergirl/. Google around the "Lean UX" topic. Ignore the folk who talk about it as if it's just about less deliverables. It's more than that.
You can code, code well, and then discover that the feature you just implemented was something that the upper management actually didn’t consider to be very important, or that they wanted something completely different from what you thought they wanted. That’s the sort of failure mode that Scrum and other development methodologies are trying to protect you against.
I tend to think bringing in agile specialists and installing scrum process to save the project is a bit dogmatic. If you worked on a project for sometime and wrote/rewrote a lot, you probably know what's needed to be written. It's fairly unlikely the scrum process actually helps at that point. What keeps you going at it is probably "faith" you built through out the year since the onset of scrum installment... and, just a habit.
If you are afraid of writing unneeded, unimportant, and unpopular things enough to label them as a "failure", your focus may be to find needed and important things for your audiences.
Your focus may be to read the draft to a select sample audiences everyday, every week, continuously, and apply various analytical techniques to different statistical models you built from the feedbacks to overcome your fear of rejection, and "manage" direction, completion, and shipment of your writing.
Or just write. A lot. And read. A lot. You'll "get" trends. You'll "get" what works and what doesn't. Of course you need feedbacks. Of course you need plans and management especially if you are co-writing with many authors.
1) code is minor part of delivering software that customer is willing to pay for.
2) "code well" is such a broad affirmation as to include using Scrum/Agile/something else to ensure that the code we deliver, works, is what customer wanted, when they wanted it, and cost < revenue.
What people fail to realize is that Scrum is a specific process. There are actual guidelines on how it should be implemented and what the team make up should be. People think they can take Scrum and tweak it to meet their needs (even if it hurts the process) and have it still be effective.
People believe that they can "scale" Scrum to teams of 100s of people, in different locations, across time zones and with people who speak different languages and expect it to work the same. It wont and was not designed to.
Additionally, Scrum is not designed to handle unanticipated work. How many times will a team be working on a sprint when a fire happens, especially at a large company? The team needs to disrupt the sprint and handle whatever unplanned work it is, from a defect a major customer change request or whatever. The whole sprint gets thrown out of wack and what was defined as the ship requirements needs to be redefined on the fly. However, Scrum allows partially done work and if a new work item is injected at the end of sprint, the Q&A team may not be able to meet the new ship requirements of either the new work item or the rest of the sprint work.
With that said, Kanban was designed to not be a prescriptive process. Kanban is all about making small incremental improvements in WHATEVER YOU ARE DOING NOW. By visualizing work you are able to see where you are becoming overloaded and where blockages are occurring. By adding WIP limits and through pull instead of push you are helping to even out the flow of work and ensure that work is getting completed to 100% at a relatively constant speed. There are other aspects of Kanban that help, specifically metrics, the CFD, and swim lanes, but really with these two aspects, you can constantly visualize what is going on and figure out how to improve your work process on demand and in your own way.
While I am a big proponent of Kanban for countless reasons, many organizations cannot simply change overnight. Many organizations cannot grasp the concept of no time box and continuous deployment. Putting faith in the work ethic and self organizing capability of the developers doesn't jive with many companies (even though the studies show teams are much more productive when self-organizing). Other people, like the author, like the idea of iterations. In addition, many teams see great value in doing the retrospective. Lastly, the teams in the organization may have been trained in Scrum and been doing it for years. To all of a sudden change to something new can cause major disruptions in work and full on rejection and revolt.
For these types of organizations, I tell people to try Scrumban or Kanban with Iterations, whatever you want to call it. Teams can use Scrumban as a stepping stone to becoming more Lean or then can just use it going forward to improve and scale Scrum. Using Scrumban, teams can move slowly to self-organization and from estimating to prediction. They can handle injected work more easily and move to continuous deployment. Moreover, they reduce multi-tasking/ task switching and ensure a even flow of work.
For anyone wanting to learn about Scrumban, I send them to this video -> http://www.youtube.com/watch?v=0EIMxyFw9T8 It's an awesome video that is just over 6 min long. I don't know who these guys who made it are and am not promoting them but the video does the job well.
2 years later, it didn't work anymore. The team had matured, the organization itself had adapted to the leaner processes and mindset and, in time, the actual scrum process was too much. It was time to change again...
And that is something I think most agile advocates don't realize. Agile should be viewed as an organizational tool that has prescripted and prescribed rules that work in general, but maybe don't work in the specific. It is great if you need something forceful with books or documentation in the beginning, but in time, the organization should mature to the point where agile/scrum/whatever is actually too much.
One last thought. I highly recommend people look at agile for the times when you need a drop in process....but there is absolutely no subsitute for hiring quality people capable of making good decisions. Agile will get more out of bad developers, IMO, but having nothing and good developers you trust is always going to be more productive.