759 reputation
314
bio website greenrd.org
location London, United Kingdom
age 35
visits member for 3 years, 8 months
seen 2 days ago

Java and Scala developer. In a previous life I was a Haskell developer.


Mar
13
awarded  Popular Question
Jan
5
awarded  Suffrage
Jan
5
comment Scrum decision making versus maintainability and development time?
My question is, is Scrum wrong to say that the development team should always make technical decisions? Is this an unrealistic requirement for adopting Scrum?
Jan
5
comment Scrum decision making versus maintainability and development time?
@Euphoric I'm positing that they have no motivation to do their job properly unless a traditional command-and-control hierarchy tells them to do so. I think I'm right in saying there exists projects that have been delivered successfully without using Agile...
Jan
5
comment Scrum decision making versus maintainability and development time?
I don't think my scenarios are correctly described as straw men. A straw man argument would be if I misrepresented the principles of Scrum. Are you seriously arguing that such teams don't exist?
Jan
5
comment Scrum decision making versus maintainability and development time?
@JamieClayton It was more of a general question, not about any particular project per se. Obviously I hoped to get useful insights out of asking it but I wanted to ask quite a broad question about the tension between Scrum and the organisation's need to control things.
Jan
5
answered Scrum decision making versus maintainability and development time?
Jan
5
revised Scrum decision making versus maintainability and development time?
didn't mean to impugn all government IT projects
Jan
5
comment Advantages of Scrum for the developers themselves?
I think that is a bit unintentionally overselling it! "What will be done during the next sprint" has to be decided with reference to the product backlog and the priority of the items on it. Of course, "how much will be done during the next sprint" is definitely decided by the team.
Jan
5
comment What are the common mistakes in 'tailored Scrum approaches'?
If there is a need for two or more full-time people to do the job of product owner, either the main product owner is too busy doing other stuff in addition to their product owner responsibilities, or the team is too large and should be split up. A "scrum of scrums" can be used for coordination between teams. Or, you know, email, talking to people...
Jan
5
comment What are the common mistakes in 'tailored Scrum approaches'?
Um, timesheets are a very important requirement in many organisations. Scrum cannot remove legal/contractual requirements from your processes, obviously! That said, timesheets do not need to be focused on tracking progress within a sprint.
Jan
5
comment Scrum decision making versus maintainability and development time?
I have rarely if ever seen mention of "hardening sprints" before. Thanks for that idea!
Jan
5
comment Does Scrum turn active developers into passive developers?
@WarrenP Yes, boilerplate can be a pain, whether it comes in the form of boilerplate code or boilerplate requirements. I think the key point is that all of those 3 elements should be either stated or understood, but more importantly, it should be clear to everyone what is really wanted, and boilerplate templated requirements can actually hinder that. Especially if developers start to think that filling in a few short words into that template is always sufficient.
Jan
5
comment Does Scrum turn active developers into passive developers?
I totally disagree with the thrust of this answer. I think some kind of "mini-waterfall" can be very beneficial, especially for inexperienced but clever developers, who are liable to do 5 different things at once and not finish any of them. In fact the person who trained me in Scrum said that you can still do "mini-waterfalls" in Scrum if you want, but ideally, they should be over a period of days or even hours. I thought, hours is too short. You can't always design->implement->test a story in a few hours. And splitting stories so that you can is not always optimal either.
Jan
5
asked Scrum decision making versus maintainability and development time?
Jan
4
comment If another team haven't done a requested task, are we supposed to mention it in every Daily Scrum as an Impediment until they do?
OK, good point, but it is not always this simple. Two examples: (a) "We NEED this feature by the end of the sprint, so the dependency must be implemented by the other team simultaneously"; (b) a dependency is thought to be complete already, but actually has a serious bug, that means the story depending on it can't be considered done until that bug is fixed.
Jan
3
asked If another team haven't done a requested task, are we supposed to mention it in every Daily Scrum as an Impediment until they do?
Dec
29
awarded  Autobiographer
Dec
22
comment How many user stories per person should be completed per sprint?
It's not a daft question because you can split (or even merge) stories if you think it's a good idea to try to target an average number of user stories per team member per sprint. I'm not saying that's necessarily a good idea - I don't know, I haven't tried it - but in principle it wouldn't go against any scrum principle to do it, as long as it didn't bias the estimation process.
Dec
22
comment How many user stories per person should be completed per sprint?
If your user stories are very complex, you should be breaking them into smaller stories. OK, admittedly, if you do this, they may no longer all be user stories - some of them may become implementation-only stories. But I think it's almost always possible to split user stories into smaller user stories.