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.
Without the retrospective, it's just modified waterfall.
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.
(Not everything fits in two week blocks either)
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.
But yes, it's a people problem.
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.
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.
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?
I'd think by and large you would evalute remote workers by theit work output, not by estimating how much time they've spent.
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?
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.
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.
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.
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.
I've only been at ones that work. I don't see how you could ask these questions and have it be a time sink: https://www.scrumalliance.org/community/articles/2014/april/...
>> 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.
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.
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.
- A few people end up discussing some minor point only of interest to them while everyone else stares into space
- Every retrospective ends up being the same as the previous one: it's like someone recorded a meeting 2 years ago and plays it back every 8 weeks
- Things that went well are all internal; things that went badly are all other teams' fault (this can't always be true)
Yes, I realise those aren't really agile issues, just a symptom of having a relatively poorly defined meeting with lots of people.
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.
There fore no one talks.
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?