Most of the agile problems I've seen have been organizations cargo-culting things they've read, rather than trying to actually be dexterous. Big-A agile versus, well, "agile".
Scrum has been the largest offender - squashing discussion in standups, allowing scrum to erode QA process, rote meetings that take 50% of the week, story points and refusing to discuss timetables in hours when absolutely needed, reporting status multiple times, having others estimate tasks who are not doing those tasks, etc.
These organizations that have done so have been some of the least agile, and waterfall-esque organizations can even be better. (They planned up front well, they changed a few minor things in the middle maybe, but cut out the overhead).
Scrum has the particularly noxious side effect of driving underground any sort of drive to improve and to learn new things. An engineer in a Scrum team is an engineer, has his or her lane, and is largely expected to stay in it. Learning? Branching out? No, get your promised tickets done this week. That concerns me; while it's possible for a Scrum-based shop to invest in its people, it's not part of Scrum to really do so. And the people are what matter, at the end of the day, so I find it rather dehumanizing.
(This is a big part of why I'm moving towards consulting--so I can invest in me more often.)
Scrum's pre-committed units of work across the team promotes this; its one of the reasons that many groups prefer flow-based methods (which can support regularly-timed releases simply by shipping the features that are ready at the time of the release cutoff) rather than Scrum's cycle-based method.
I don't see how this is true. If you're building slack into your cycle there should be regular investment time available that a pure flow-based system wouldn't have.
If there's no slack in your sprint schedule, well there's your problem.
In my experience, Scrum's work-unit factorization encourages thinking of developers as spherical cows that need no personal development, with slack as a concession to reality that patches the damage Scrum itself causes. And Slack is generally considered to be for technical investment, though, not personal investment.
A good manager could think past that, for sure, but I've never encountered a good manager that felt Scrum was good or necessary for their teams.
I think most teams that implement/try to implement agile/scrum/xp and end up disliking it / failing at it completely miss the point of the retrospective step - and thus, skip that step.
Without the retrospective, it's just modified waterfall.
We had them in about half of the scrum shops. The retrospective, in my experience, was yet another meeting where things didn't get done either. "We are having too many meetings" was usually not popular either. Don't get me wrong, I like good meetings that result in actionable decisions.
My personal view on scrum is it attempts to trick a software team into micro-managing itself, and it usually results in feeling like kindergarten as a result.
The better shops have been "agile", but not "Agile", and just did what worked, and made changes when they needed to.
I don't think a retrospective is essentially required, but the ability to change and throw out things that don't work -- and have only the right amount of meetings and to talk about the things that matter rather than a template - is.
When a retrospective is to make the team feel they have a voice to make changes, and in reality, nothing changes, that makes the retrospective itself rather soul-crushing theatre, so everybody just says nice things and hopefully nobody gets thrown under the bus when "what could have gone better" is discussed - but often, that still happens.
Scrum is, to me, something people pick when managers don't want to manage.
I like release-early release-often, MVP (in small doses), see http://michaeldehaan.net/post/118860078737/the-rock-paper-sc..., and many of those concepts. But I also don't like the idea that requirements constantly shift - which means architecture can't plan ahead.
I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. If you have a PM that doesn't allow time for such things, it can be rough.
> Scrum is, to me, something people pick when managers don't want to manage.
This is a really good observation, I think, and lines up with my own experiences--every incapable manager I've ever had thought Scrum was a great idea. The ones I've known have been very linear thinkers with a tendency towards restricted domains of thinking, and Scrum reminds me a little bit of Orwell's "if you can't say it, you can't think it" idea. Scrum gives you a vocabulary that, if you hide in it, requires you to confront many fewer things and make fewer choices.
They're almost all the wrong choices, I think, but there are strains of manager that find choices anathema in the first place and so I can see the appeal.
>>I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc.
Sounds like your teams were underestimating task effort.
>>If you have a PM that doesn't allow time for such things, it can be rough.
Anything's rough with a shitty PM, which is what you've described.
I think one problem is that Agile gives a numerical value to how much work has been done: story points.
Management get addicted to getting more story points, and any push back from developers that would lower the number in the short term is ignored. Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
> I think one problem is that Agile gives a numerical value to how much work has been done: story points.
Agile does not. Even a number of the defined methodologies sold as "Agile" do not (Scrum, for instance, does not mention either user stories or story points -- it does indicate that backlog items will have estimates that are less-specific when the item is farther out in the tail of the work queue and more refined when it is near the head of the queue, but doesn't specify the terms in which those estimates should be gathered.)
> Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
If it is fairly stable (which should also be measured if it is going to be used), it is a meaningful number for planning what items are within capacity for a sprint. It may not be meaningful for other purposes even then.
That's a problem with management. All of the agile/scrum resources I've read exclaim, in big bold letters, 'THESE ARE NOT METRICS TO EVALUATE PERFORMANCE; THEY ARE FOR ESTIMATION OF EFFORT'
I've seen average story points reported that way too -- but I think it's just that people don't know not to report all the decimal places that Excel gives them.
> Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
Ok, explain this to me. Why is this not a meaningful number?
Story points are essentially hours and generally in the shops I worked in, they are converted to hours. If something takes longer, the hours are adjusted.
So really, that's a metric for maximum hours worked ... why is that not a good metric?
If someone is on a remote team and they're expected to work 40 hours a week, why is measuring the maximum hours they were on the job a bad metric?
What? No. Glad I don't work for you.
Nearly all developers I know estimate time (and storypoints) by some (often linear) function of volume and complexity. Volume estimation is usually not very difficult, but complexity is very tricky (and dynamic too). Estimating developer work hours by any proxy that depends on complexity will introduce a margin of uncertainty so large as fo render the number meaningless.
I'd think by and large you would evalute remote workers by theit work output, not by estimating how much time they've spent.
> I'd think by and large you would evalute remote workers by theit work output
Which is what? Lines of code? I think that's even worse.
How do you determine how much work to assign someone if estimates are meaningless? How do you determine if someone is productive or is doing one hour's work per week?
Aside from insults, I don't really see any answers. Have you ever been in a PM role?
Again, if you adjust estimates as you're doing the work ... as in, it's more complex than you thought, so you adjust the estimate ... why are estimates a bad metric and what metric (something that can be quantified) would you recommend?
Uhm, I think you're reading my post a bit uncharitably. I don't think I insulted you, for instance.
I never said that estimates were meaningless, but they are tools for planning with high intrinsic uncertainty, and translating that uncertainty to evaluations gives unfairness. People are very sensitive to (perceived) unfairness and the idea that they will be treated so will give rise to resentment, not to mention incentives to game the system and overestimate. Hence endless bickering about points.
If agile failed for any reason it was misunderstanding human psychology.
Personally I don't think human performance in creative professions is well suited to quantified analysis, especially when team efforts are involved. So I don't really have an answer there.
Nope, the features always won in priority because the project manager / scrumlords would keep it that way, and didn't value the technical plumbing that would actually increase velocity and reduce churn and improve code quality.
> Don't get me wrong, I like good meetings that result in actionable decisions.
Which is what a retrospective _should_ be! "what went wrong, what went right, how can we change our process to keep those wrong things from happening again?" It doesn't necessarily need to be a meeting. The introspection needs to happen, though. No matter what type of process you have - if it's not being constantly reevaluated for efficacy, it's just cargo cult.
Very true, it's not the format but the goal of adapting that matters. If you can discuss and fix your problem in a stand-up, do it. If you need to sit down for half an hour, take time for it. If you need 1/2 day to really understand what is happening and get a shared view to decide what to do, plan it. But make sure that you take action.
And I think that, in turn, might be a symptom of how large organizations often implement scrum. Scrum's meant to be an alternative to - even an inversion of - the traditional way of running software projects. But as it passes through the kaleidoscope of corporate culture, it's all too easy for scrum to just become a layer of makeup on top of the traditional approach.
For example, Scrum has a "scrum master" role that is most certainly NOT that of being a project manager. But usually a project manager gets placed in that role, and is naturally going to interpret the role by finding and then exaggerating analogies between it and the stuff they learned in PMP class. In the more traditional structure that the "project manager" role comes from, the PM owns and dictates a lot of the processes that the team follows, including daily meetings and suchlike.
This is in direct conflict with the idea that the entire scrum team owns and collaboratively determines the processes that they follow. And that idea is fundamental to the inspect/adapt process that the sprint retrospective is supposed to facilitate.
Retrospective has, in my experience, been a candidate for biggest 'agile' time-sink and a great example of how agile 'evangelists' and scrum masters are so inward-looking and process-focussed that they get in the way of work.
The problem is that in many large organizations, the retrospective is a political game where the objective is to find and blame a person (or persons) who caused the team to underdeliver on the sprint. That mindset is an anathema to the sorts of honest constructive discussions that are required to meaningfully improve process. Instead the meeting turns into a toxic political mess that ends up disadvantaging the most talented developers on the team.
You clearly haven't worked with people who like the sound of their own voices quite so much as I have.
>> What went well during the sprint cycle?
>> What went wrong during the sprint cycle?
>> What could we do differently to improve?
I have had Agile Evangelists, who are supposed to be good at making this stuff streamlined, turn around and say "Everyone needs to come up with five things in each category, then we'll go through and discuss them all, deciding on the most important things to change at the end"
In a team that was already too large (15ish people) I watched that eat an entire afternoon and produce no useful output on more than one occasion. In the team I was on (four, five?) it still seemed to take hours.
I know, I know, they were probably doing it all wrong, this is just my experience of one workplace.
I'm not saying it can't be done right, just that it doesn't seem to be a magic bullet and can devolve into navel-gazing.
From my limited experience, scrum can work (defining 'work' as 'make people more productive'), and even in the classic situations that give rise to the flaccid variety (I work for a blue-chip media corporation which is just in the last couple of years trying to build a modern engineering culture basically from scratch, and it happens to work).
A pretty important point for making scrum work, however, is aggressive timeboxing of everything. If you don't want retros to become a 4 hour developer-kvetch about somebody else's team, start by ruthlessly clipping it to 45 minutes.
I understand that this is not always an option in malfunctioning corporate environments; but Kanban/XP/programming motherfkerism wouldn't fly either in those situations.
>> If you don't want retros to become a 4 hour developer-kvetch about somebody else's team, start by ruthlessly clipping it to 45 minutes.
When I rule the world, as they say, every meeting will contain only the people it needs to, "I don't feel this is relevant to my work or that I can contribute" will be the best reason not to attend and time limits will be aspirational in as much as everyone will aspire to beat them by as much as they can.
Unfortunately, as a contractor, I can suggest these things but not mandate them.
In that case, part of the retrospective should probably be 'these meetings aren't actually solving anything, are actively getting in the way of getting things done. how can we do this meeting differently?' ;)
>>A few people end up discussing some minor point only of interest to them while everyone else stares into space
Mostly the manager's minions and pets talk, generally in a softer tone more towards appreciation bordering sycophancy. The remaining fear to give any genuine feedback, fearing retribution. If some one does speak they are taken as non team players who will be handled appropriately the next raise/promotion cycle.
The scrum master or even "team lead" is supposed to catalyze things a little bit in those situations. A lot of times there's a culture of "everyone knows about it, but nobody will say anything about it because they're afraid of the axe," where "it" is the thing that's horribly wrong.
These are clear symptoms of not having retrospectives facilitated in a proper Wat. A good facilitator uses different exercises, has people focused on a fixed scope or time period to catch learning points, supports a team in coming up with actions that they can do immediately and that are small enough to finish on a short notice.
>>Without the retrospective, it's just modified waterfall.
This is true. But retrospectives will never work in any reasonably sized team, the reason is middle managers don't like being told or like being talked about their work in front of everybody, or being told to change something. Ego plays a big role in these things and they don't like being given feedback or advice, especially because these managers tend to think themselves as people in authority as all knowing and in complete control.
This is human psychology, developed over thousands of years. Masters never took feedback from slaves, so why should the modern incarnation of the older masters take advice from the current day slaves?
It takes a different mindset to make changes happen (agile or not). If people resists changing their mindset, nothing will happen and we keep struggling. That's a choice I'd rather not do.
I've never seen an agile article recommend rote meetings taking 50% of the week. Anyone even remotely interested in agility would call that an anti-pattern. I don't think it's a case of organizations blindly cargo-culting, but rather an inability to embrace agile.
Nobody who has any kind of interest in selling or implementing Agile anywhere would. That doesn't mean that the reality of the situation doesn't cause it to happen.
No, that's one of the really good things it's done. Half the time I'm not involved in any way in those discussions, so moving them out of the status meeting means I don't have to stand around listening to stuff that doesn't concern me.
Scrum has been the largest offender - squashing discussion in standups, allowing scrum to erode QA process, rote meetings that take 50% of the week, story points and refusing to discuss timetables in hours when absolutely needed, reporting status multiple times, having others estimate tasks who are not doing those tasks, etc.
These organizations that have done so have been some of the least agile, and waterfall-esque organizations can even be better. (They planned up front well, they changed a few minor things in the middle maybe, but cut out the overhead).