User:Stuart/Scratchpad

So What's Wrong?

I guess the main thing to point out is that I don't believe in one-size-fits-all solutions to everything. If they work for everything (and I'm unconvinced that such a solution exists at all), they would require such concessions in their target environments that it ends up being a race to the middle. The championing of mediocrity. That's one of my main problems with Agile and especially with the cult-esque fervour of its proponents - the belief that it holds the solution to every development problem; that it is suitable for all software projects, regardless of the nature of those projects.

With that in mind... my gripes with Scrum, or at least our implementation of it:

No Technical Oversight

We really need someone who acts as the tech lead for the product. Someone who has final say over any contentious issues - decisions about the inclusion of third party products, overall product architecture, the speccing & priority of devops work, class and file structures, scripts and tools, even decisions about programming styles.

I just think 2 or 3 teams can't independently decide, for example, to use a third party tool when it affects the other teams working in the same product. Or to allow a coding style orthogonal to the rest of the code. Or to reorganise the files into a structure that they prefer. You need someone outside the teams to own that, document it, manage it.

And just having someone who has a clear understanding of everything that is going on at a technical level is such a boon. A person who can keep track of all the developments and is aware when one piece of work is going to an impact on another without having to cross your fingers and hope that that comes out in a 'scrum of scrums' meeting where people say things other than "well, nothing's really changed since the last meeting. Next!".

I also think that they (in concert with other developers) would need to have some say about prioritisation - there are architectural or other largely technical issues which are ignored, simply because they don't have any user-facing aspects. The only outlet we have for that is the occasional Kaizen day - and if the work doesn't fit into a single day of work, then it will just never get done. Basically, they should look after the technical issues that would largely go over the product owners' heads.

"Smart" Transparency

I'm a strong believer in transparency - everything being done in the open where anyone can give their tuppen'orth on something. It's why I favour the wiki for... well, anything development related. It's open, everyone can see it, everyone can monitor it, everyone can have a conversation about something on there. If there's some process around it, then we don't have to guess which of the many many places we might document something houses the thing they're looking for.

Compartmentalisation is something that started happening in BP product team a few years ago and it's as alive as it ever was. There's lots of stuff in Yodiz which as far as I'm concerned is hidden because it means having to use Yodiz. There's lots of stuff in Word documents that fly about in limited mailboxes; far far too much stuff only exists in peoples' memories of a meeting - "I'm sure I didn't say that", "Well, I remember it clearly - you did" sort of stuff.

Stand-ups

Any team working together should not need to down tools for half a man day every day in order to give a presentation on their last day's work.

If the team don't know what other people are doing from the general buzz of 'working together' then they are not 'working together'.

It's a nonsense - everyone kinda tunes out since everyone knows what everyone else did yesterday anyway. We all look at the same work items, see their status, we all get notifications when things occur - either via email or #robots. There's a near-constant hum of activity in the #teamX and #dev channels; it might be a bit harder keeping track of what everyone in the department is working on, but you should be able to keep up with what the half a dozen or so people that you're ostensibly working closely with are doing.

Requirements

I've long maintained that we have a problem with requirements. We're appalling at it - this isn't a Scrum/Agile thing; it's something we've never done well.

It's come up a few times in retros - "Poor Acceptance Criteria" or similar. After a few iterations (heh) when nothing really happened, it just never got mentioned again. It's pointless banging on about something if it's clearly just not going to be addressed.

UIAutomation is a pretty good example of this. The requirements for the whole thing was, basically, "we want UI Automation in the product". There were no specifications; no lists of desired elements, desired actions; no minimum functionality; no analysis whatsoever. Just "we want UI Automation in the product". Trying to get answers was like pulling teeth - decisions were all "well, what's our precedence for this? If none, what do the team think? No answer there? Let's ask PS / CS" - ie. the very opposite of decisions. We ended up having a 2.5 hour phone call at the end of the work where the developers decided on the requirements. Being able to cope with 'changing requirements' like what Agile says we should presupposes that there are requirements there to change.

Sprints

The notion of 'sprints' is so bizarre to me. A arbitrarily limited time period in which a set of pre-digested tasks are fixed in place. Myopic and limited - the big picture is notably absent; developers are made to focus on the immediate with no thought given to future proofing and longer term considerations. I still don't know why we can't just have a plan for the next two weeks, and not this "what we've committed to" and "velocity" nonsense that really doesn't matter.

Just "here's all the things we need to do; here's the plan for the next two weeks. Let's go"

Retro/Planning

I actually think a fortnightly 'progress meeting' is fine; I think raising issues in those meetings is fine, with a review meeting at the end of a large piece of work highlighting things that we tried that worked well, things that didn't, things that really hampered us, lessons learned, etc. is fine too, but to have that every 2 weeks is just a waste of time. Just "what do we need to fix in the next two weeks" would be enough, saving the larger self-examination for when we have something worth examining.

Conversely, the 'release retrospective' is a complete waste of time given how far apart our release are; we can't remember the whole release development - it spans months.

The 'Happy'/'Sad' paradigm occasionally, seemingly accidentally, spits out things that are worth a discussion, but the actual worthwhile discussions are almost always not Happy/Sad, but are in the middle and labelled just "I want to discuss this".

Design

3 months ago, I would have argued that there is no design... we've actually improved at that a bit recently, with a few 'spike'/'r&d'/'some other name' pieces of work which were basically designs. We're obsessing a bit with what we call them (something I think is entirely unimportant), but at least we're doing them now. We still don't do anything smart like have a formal process for design; even where the design is documented (if it is documented) is entirely dependent on who's doing it (Yodiz / Word document floating around selected inboxes / Wiki).

One of the agile principles is "Continuous attention to technical excellence and good design enhances agility". "Good design" implies "design", so actually formalising what we expect out of a design and specifying what manner of project would require a formal design would be beneficial.

This really needs to be peer reviewed as well. Again, we're getting better at that, but that should be formalised too. Again, how the review / discussions work is entirely dependent on who's doing it. I see this as being something which should be cross-team - we need to harness all of the expertise of the team at this crucial stage - so perhaps this should fall under the bailiwick of the tech lead that I posit above.

Fragmented Development

This bothered me right from the start.

A project passes through several committees before developers get to see the 'stories' designed by the product owners. These stories then get split further into unnecessarily small subcomponents all of which are almost designed to cause developers to start stepping on each others' toes - there is no technical oversight here either, because this is a quasi-democratic system - all developers are created equal.

Jobs are disseminated largely by virtue of timing - ie. who is available to do the work at a given time. Priority is out of our hands - product owner decides the order in which we do things and, in doing so, is largely responsible, albeith unintentionally, for who's doing them - again, not choosing based on ability or knowledge, but on who's free.

Since there is only a vague notion of an overall development, there's nobody in charge of such a thing - the enforced myopia of the sprint and the random possibility that any of the developers might not be available for dev work for a 2 week period in the project development means that we all end up focusing entirely on our immediate needs and giving no thought to the wider picture.

It just makes everything so unnecessarily complicated; the splitting of stories solely to make management easier at the expense of development. Which is really my fundamental issue with development as we practise it.

Production Line

It's a related point to Fragmented Development; the splitting into loads of tinytiny pieces of work just makes it feel like you're on a production line doing one tiny insignificant thing at a time, ostensibly hoping that it will all come together to make something worthwhile in the end, but really the complete lack of vision just leaves you uncaring about the bigger picture.

Terminology

I really hate management buzzwordy bullshit terminology, and Agile is full of it. My teeth grind every time I'm asked to use a daft name for something which sounds like it comes straight out of a marketing executive's dream diary.

I appear to be the only one bothered by this, however, so maybe that's just me.

Yodiz

I mean, really. Do I need to say anything else?

So What's Right?

It's not all bad.

I've made no secret of my problems with the imposition of this new way of working on us, and I've also been forthright in admitting that all was not honey and sweetness before either. So I do think there are some things that have actually improved on what we had before.

Regular Meetings

I've mentioned them up in the 'Sad' section, because I don't think the meetings we have are all they could be... but at least we're having them. Back in the olden days, our meetings got further and further apart, to the point where you could conceive and deliver a baby in between them.

When they actually occurred, the 'group' bit was a presentation about the future of... something (BP going public and the 'pods' notion for development were the last two, iirc) and then we split and had a series of 1:1 chats which could easily have occurred over pidgin or something.

Other People's Opinions

So... I'm going to go through some of the background reading I've been doing over the last couple of years - largely trying to identify my problems with Agile, and specifically with Scrum, the flavour of Agile that we're currently aligned to.

Why Agile and especially Scrum are terrible

This old chestnut was the first one that I found myself nodding along to as I was reading. I've read around some more of the author's stuff, and it's fair to say that I don't agree with him 100%, but this presents an awful lot of the problems that I see in this way of working, and with a lot of the arguments supporting Scrum that he's come up against. Usually the "anti-waterfall" notion - as if that's the only other option.

Some snippets which present the problems I have with scrum:

Like a failed communist state that equalizes by spreading poverty, Scrum in its purest form puts all of engineering at the same low level: not a clearly spelled-out one, but clearly below all the business people who are given full authority to decide what gets worked on.

Ultimately, Agile (as practiced) and Waterfall both are forms of business-driven engineering, and that’s why neither is any good at producing quality software or happy employees.

...individual engineers are rewarded or punished solely based on the optics of the current two-week "sprint", meaning that no one looks out five "sprints" ahead. Agile is just one mindless, near-sighted "sprint" after another: no progress, no improvement, just ticket after ticket after ticket.

"Agile" and Scrum glorify emergency. That’s the first problem with them. They’re a reinvention of what the video game industry calls "crunch time". It’s not sustainable to work that way. An aggressive focus on individual performance, a lack of concern for people’s career objectives in work allocation, and a mandate that people work only on the stated top priority, all of these provide a lot of value in a short-term emergency, but become toxic and demoralizing in the long run. People will tolerate short-term losses of autonomy, but only if there’s a clear point ahead when they’ll get their autonomy back.

This article is a few years old now - I include it really to demonstrate where my head was... oh, I don't know 18 months ago or thereabouts.

Why Scrum is the Wrong Way to Build Software

This is more recent and was flagged up to me by a friend. I actually think that, while there are some good points raised here, the author's disregard for estimates and marketing is... well, at best, unrealistic. He does have a few alternatives

Status meetings are the scourge

There may be a few more coming from signal v noise - they're the 'blog' output of basecamp, the project management software company, and I really like a lot of their ideas.

How we structure our work and teams at Basecamp

I really like this