774 reputation
415
bio website greenrd.org
location London, United Kingdom
age 35
visits member for 4 years, 1 month
seen Nov 7 at 11:57

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


Nov
7
comment Product backlog acceptance criteria
Yes, so am I. I accept that sometimes it is necessary to make such assumptions because stakeholders are unavailable, but that is not an ideal situation which should be avoided whenever it is feasible to avoid it.
Oct
17
awarded  Notable Question
Sep
26
comment Contracting out software development; deliver user stories or business requirements?
@ThomasOwens This is inaccurate - some companies specifically do not supply their independent contractors with computers, in order to avoid creating the impression of "disguised employment" when tax inspectors come calling. Instead they bring their own laptops.
Sep
26
awarded  Excavator
Sep
26
revised Product backlog acceptance criteria
formatting, corrected English
Sep
26
suggested approved edit on Product backlog acceptance criteria
Sep
26
comment Product backlog acceptance criteria
Acceptance criteria should be driven by business requirements, not developer assumptions. If you cannot find out business requirements this just creates waste where you guess something that might be wrong, so you should try to do something else instead for which you do already know the requirements.
Sep
26
comment Product backlog acceptance criteria
If you don't know what you're being asked to develop, how can you estimate it? The acceptance criteria could cover all kinds of complexities, and you can't just negotiate away business requirements.
Sep
26
comment Agile User Stories and acceptance criteria
This is not a user story, this is an Epic, or maybe even just a product idea. It needs to be refined into multiple user stories, possibly clustered into multiple epics. By saying "just capture the main points" the client (or whoever said that) is making a classic requirements elicitation mistake, namely that the developer doesn't know what is required or nice-to-have unless he or she actually asks the client! As a developer, you should manage the requirements gathering process, not the client, and definitely not a non-technical person, because it is you who will be blamed if you missed a bit.
Sep
26
comment What is the difference between requirements and acceptance criteria?
I disagree that this answer makes the difference clear. It's not clear at all to me from this answer.
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...