First They Ignore You
A well-meaning dev sets up the wiki on a spare server. It contains some important information about the network that nobody else understands, a very terse guide to application architecture, a page about local bars and restaurants that is, somehow, already out of date.
Then They Like You
Very gradually, through dint of a handful of well-meaning devs continually suggesting people add things to it, it grows. Useful information about how to set up environments is added, as well as how to debug more complex problems.
At some point it reaches a tipping point of usefulness and becomes the defacto place for documentation. Reams of notes from meeting, observations from research spikes, and ideas from brainstorming sessions are added, large parts duplicated and contradictory. It is chaotic but a goldmine. The page on local restaurants and bars is never updated. Only one of the bars is still in business.
Then They Ignore You Again
Eventually the wiki comes to the attention of upper management. Maybe Support. Maybe Sales. Maybe Ops. Somebody sees it, sees that it is good, sees that it is a democratic nirvana to which everybody can contribute and nobody has overall control, and decides it should be theirs.
They institute a Wiki Transformation Project, which despite being a glorified database migration somehow takes six months to complete. When finally complete it is introduced with a company-wide powerpoint presentation (attendance mandatory).
The new wiki is on some more intimidating platform: Confluence maybe, or Sharepoint if you are really unlucky. Half the users do not have permission to edit pages they wrote themselves. All of the formatting is screwed up and several important diagrams and flow charts have been lost completely. The page about local bars and restaurants has been quietly deleted along with, it becomes apparent only later, a number of other pages people relied upon. Only a handful of well-meaning devs ever add anything new to it again.
Wednesday 22 March 2017
Thursday 9 March 2017
Scrum is dumb
Agile, as I never tire of telling people, is a broad set of pretty uncontroversial principles while Scrum is something invented by management consultants to make money. Nowhere in the agile manifesto does it mention stand-ups, story points, or sprints. You can be agile without doing any of those things.
In seventeen years I've never been a part of a team building a thing for a customer who was remotely interested in getting updates every fortnight. About 90% of the time I've been in teams where we all worked on different parts of the same massive mature application (or family of applications). Most <air quotes>projects</air quotes> were coded by only a single developer, very few indeed by more than three. Most could only be released with a great deal of difficulty (sometimes having to navigate the audit processes of customers, and the limited resources therein) and were rarely done so more than once a quarter at the absolute most.
The one time I can recall building a new piece of software as a collaborative team, the customer was represented in the sprint reviews by our own support analyst and, when it came time to hand over some money, declined having never once seen what we produced. Far more often than not there simply was no customer beyond a products guy with an idea they had long since lost interest in.
Scrum, then, has always felt like a solution in search of a problem.
Of the three aspects mentioned above, daily stand-ups I am generally in favour of. They are short so even if unproductive not very harmful, and they do provide a degree of team coherence, when everybody is -as usual- working on different things.
Anecdote: Once upon a time, long before I'd ever heard of a sprint, teams would send out weekly progress emails detailing what each member had achieved last week and was planning for the new week. One poor sod in a different team became a running joke for having the same 'finish N-Patch' status for well over six months. In the end he left the company without ever finishing it. At the time I thought he was just an idiot but now I tend to view the whole episode as a failure of pastoral care. He wasn't getting on with the people he was living with and obviously wasn't coping with his work. I suspect he was probably a bit depressed. He needed support and he didn't get enough of it. If the team had done daily stand-ups then the work issues would have been obvious and, hopefully, they would have stepped in (where his manager did not) long before everything got so bad. At the very least it would have made the problem much harder to ignore.
Until recently I was kind-of okay with story-points and burn-downs and velocity and all the rest. Accept that estimations are wrong, I thought, instead measure your actual progress toward a finished product and do not get snared by the beguiling false certainty of man-hours. But too many interminable estimation meetings have beaten it out of me, too many questions of the form: "but how much is a story point really?"
In any case I don't think I've ever had a burn-down that actually burnt down, never had a velocity that didn't hover about zero for sprint after sprint after sprint. We couldn't book the points till the story has passed QA and QA were always trying to catch up with something more urgent. By the time our work became urgent nobody cared anymore. It was only urgent because it was being released anyway.
Stories that fit in a sprint are rare beasts too. As a user I want to do X we would write, and then realise this was a months work at least and our velocity was going to be zero-zero-zero-one hundred! Gamely we would try and split it up but rarely ended up with anything better than As a user I want an X button, and As a user I want X to happen when I press the X button. And sure enough our velocity would transform into half-zero-zero-one hundred!
In the end we started writing stories from the point of view of the components. As a thingabob widget I want the doohicky service to support Z in order that I know what to prepare in order to begin X. And the whole thing became meaningless.
I guess it comes down to why do sprints at all? To deliver frequently make sense, but who are you delivering to? If it's QA then who cares? Certainly they don't. If it's a metaphor, delivering kind-of-atomic chunks of work to a golden master version, then adopting git-flow will give you all this without four hours of mandatory meetings every fortnight. If it's to check you're going in the right direction with a product owner, why only every two weeks. I've never worked anywhere where I wouldn't frequently wander over to the product owner, be she architect or saleswoman, and ask her to clarify what she wanted.
I've sometimes said that I've drunk the TDD Kool-Aid. It works. I've seen it work. I'm convinced. My attitude to Scrum has always been more circumspect. I bought the principles, was optimistic, but had never seen it really work. Now I'm embroiled in a second attempt to "Go Agile," at a second company attempting it, and I see all the same failings all over again, I'm forced to confront the possibility that the whole thing is snake-oil.
In seventeen years I've never been a part of a team building a thing for a customer who was remotely interested in getting updates every fortnight. About 90% of the time I've been in teams where we all worked on different parts of the same massive mature application (or family of applications). Most <air quotes>projects</air quotes> were coded by only a single developer, very few indeed by more than three. Most could only be released with a great deal of difficulty (sometimes having to navigate the audit processes of customers, and the limited resources therein) and were rarely done so more than once a quarter at the absolute most.
The one time I can recall building a new piece of software as a collaborative team, the customer was represented in the sprint reviews by our own support analyst and, when it came time to hand over some money, declined having never once seen what we produced. Far more often than not there simply was no customer beyond a products guy with an idea they had long since lost interest in.
Scrum, then, has always felt like a solution in search of a problem.
Of the three aspects mentioned above, daily stand-ups I am generally in favour of. They are short so even if unproductive not very harmful, and they do provide a degree of team coherence, when everybody is -as usual- working on different things.
Anecdote: Once upon a time, long before I'd ever heard of a sprint, teams would send out weekly progress emails detailing what each member had achieved last week and was planning for the new week. One poor sod in a different team became a running joke for having the same 'finish N-Patch' status for well over six months. In the end he left the company without ever finishing it. At the time I thought he was just an idiot but now I tend to view the whole episode as a failure of pastoral care. He wasn't getting on with the people he was living with and obviously wasn't coping with his work. I suspect he was probably a bit depressed. He needed support and he didn't get enough of it. If the team had done daily stand-ups then the work issues would have been obvious and, hopefully, they would have stepped in (where his manager did not) long before everything got so bad. At the very least it would have made the problem much harder to ignore.
Until recently I was kind-of okay with story-points and burn-downs and velocity and all the rest. Accept that estimations are wrong, I thought, instead measure your actual progress toward a finished product and do not get snared by the beguiling false certainty of man-hours. But too many interminable estimation meetings have beaten it out of me, too many questions of the form: "but how much is a story point really?"
In any case I don't think I've ever had a burn-down that actually burnt down, never had a velocity that didn't hover about zero for sprint after sprint after sprint. We couldn't book the points till the story has passed QA and QA were always trying to catch up with something more urgent. By the time our work became urgent nobody cared anymore. It was only urgent because it was being released anyway.
Stories that fit in a sprint are rare beasts too. As a user I want to do X we would write, and then realise this was a months work at least and our velocity was going to be zero-zero-zero-one hundred! Gamely we would try and split it up but rarely ended up with anything better than As a user I want an X button, and As a user I want X to happen when I press the X button. And sure enough our velocity would transform into half-zero-zero-one hundred!
In the end we started writing stories from the point of view of the components. As a thingabob widget I want the doohicky service to support Z in order that I know what to prepare in order to begin X. And the whole thing became meaningless.
I guess it comes down to why do sprints at all? To deliver frequently make sense, but who are you delivering to? If it's QA then who cares? Certainly they don't. If it's a metaphor, delivering kind-of-atomic chunks of work to a golden master version, then adopting git-flow will give you all this without four hours of mandatory meetings every fortnight. If it's to check you're going in the right direction with a product owner, why only every two weeks. I've never worked anywhere where I wouldn't frequently wander over to the product owner, be she architect or saleswoman, and ask her to clarify what she wanted.
I've sometimes said that I've drunk the TDD Kool-Aid. It works. I've seen it work. I'm convinced. My attitude to Scrum has always been more circumspect. I bought the principles, was optimistic, but had never seen it really work. Now I'm embroiled in a second attempt to "Go Agile," at a second company attempting it, and I see all the same failings all over again, I'm forced to confront the possibility that the whole thing is snake-oil.
Subscribe to:
Posts (Atom)