Why I'm done with Scrum
lostechies.com
lostechies.com
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.
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.
"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.
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.
I'm sure if you keep that condescending and conceited attitude everyone will come around ...
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.
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.
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.
For certain kind of organisations yes. Take a look at the research Alistair Cockburn did and his various Crystal [colourname] methodologies. http://alistair.cockburn.us/Crystal+methodologies
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 :-)
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.
Well, that's kind of true: http://agilemanifesto.org/
You are mixing scrum and agile.
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 don't feel sufficiently informed to judge wether it is onerous in theory or practice but weighing the description is the wrong test.
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.
If you're still learning how to do things, then how-tos, recipes and best practices like Scrum will help.
But work better when they follow a checklist!
"The Checklist Manifesto: How to Get Things Right"
http://www.npr.org/templates/story/story.php?storyId=1222261...
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)
It is (or should be).
For example:
* 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 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.
Once the team is functioning well, you can usefully relax a lot of the aspects of Scrum.
Ir's insidious because it tricks devs into thinking it's for them.
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.
I've done a bunch of reading about Scrum
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.
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.
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.
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.
* - whatever will give you 6 +/- 3 months
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.
No technique will allow you to reliably and efficiently solve a problem until the problem is well enough defined.
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?
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.
The company probably would have worked just fine using the waterfall method if the management had bothered to work at all, I guess.
It improved not because of your manager took scrum classes, but because your manager took any classes.
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'.
YMMV
> 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.
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).
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...).
Erm. There is an explicit commitment by the Scrum team to complete the stories selected to produce the next increment in the sprint. To quote from http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scru...
"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.
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.
DISCLAIMER: I'm working on https://www.blossom.io which is a lightweight kanban board.
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.
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.
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.
Scrum - done well - should be a tool to let the team figure out the best way to deliver.
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.
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.
I admit as someone else mentioned that sprint was a poor choice of words. So say iteration instead. Problem solved.
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.
Decoupling incrementalism from iterations has been a huge change for me.
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.
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.
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.
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?
That isn't good enough justification. You are too much erring on the side of caution.
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.
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.
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.
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 onPeople 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.
I had a manager that would pretty much go through the board and ask who did what card so he compare the estimates to the actual time.
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?
> talking about how hard something's going to be.
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.
Me too. Good thing neither activity has anything to do with sprint planning.
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.
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.
#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.
And we're still recommending companies adopt this, when the failure rates are both known to be high, and catastrophic when they occur?
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.
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.
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 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.
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 :)
What? Was your 15-minute stand-up 2 hours long? If so, are you sure you were doing it right?
Were you scrum-master, and doing 2 hours of admin per day?
What were you doing for the rest of the working day?
I'm not really sure what you are describing here.
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.
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.
Source: http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scru...
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.
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.
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.
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.
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".
Six times is a bit much, though. That sounds like they haven't worked out their estimations yet.
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.
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.
You'll likely find Jeff Patton's work of interest - this might be a good starting point http://agileproductdesign.com/blog/emerging_best_agile_ux_pr....
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.
There are also the sessions from Agile UX NYC earlier this year http://agileuxnyc.com/presentations/
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.
Finally the agile usability mailing list http://tech.groups.yahoo.com/group/agile-usability/ is a useful place to chat about this sort of stuff.
If the customer didn't order it, it doesn't matter how well you coded.
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.
But my focus is still to write.
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.
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.