Search type Search syntax
Tags [tag]
Exact "words here"
Author user:1234
user:me (yours)
Score score:3 (3+)
score:0 (none)
Answers answers:3 (3+)
answers:0 (none)
isaccepted:yes
hasaccepted:no
inquestion:1234
Views views:250
Sections title:apples
body:"apples oranges"
URL url:"*.example.com"
Favorites infavorites:mine
infavorites:1234
Status closed:yes
duplicate:no
migrated:no
wiki:no
Types is:question
is:answer
Exclude -[tag]
-apples
For more details on advanced search visit our help page
Results tagged with Search options user 12828

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

4
votes
It is Agile, in that it conforms to the Agile manifesto. It is not Scrum, in that Scrum suggests you should use complexity points to estimate everything. But neither of these things are that … important. In fact, I argue that strict adherence to Scrum, despite all evidence that you shouldn't be, is not Agile. Here's the question you should be asking: is it useful to you? How does it improve the …
answered Sep 14 '11 by pdr
5
votes
People at all levels of the business who truly and utterly believe in the Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this … Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. And when I say believe in the Agile Manifesto, I mean …
answered Apr 26 '12 by pdr
3
votes
Prioritisation should be done by a single product owner with input from the various stakeholders, including a senior developer who is a stakeholder for the code and as responsible for non-functional r …
answered Sep 19 '11 by pdr
2
votes
Do your code reviews only ever turn up UI/UX changes? I would argue that's not a code review, it's a usability test. Code reviews are much more about turning up the problems that the users/testers/bus …
answered May 19 '11 by pdr
6
votes
An incomplete feature should come out. But if this can be done without removing the code (feature flags, just removing the wiring, etc.) then that's fine -- preferable, in fact. Why? Because it limits …
answered Sep 24 '11 by pdr
3
votes
In my experience ... Pros: It gives developers a warm feeling that they're not the only ones expected to be transparent. It does help the Product Owner understand the process. Cons: It gives Pr …
answered Aug 3 '12 by pdr
10
votes
First, let's not confuse Scrum and Agile. Scrum is an Agile process, but it does not equate to Agile. What you're describing is Scrum. Whether Scrum is based on the daily reporting that you describe …
answered May 13 '11 by pdr
10
votes
It's your definition of Agile that's wrong. Agile is valuing Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration … points ... UML is an optional tool Yes. Most things are when being Agile. Task boards are mandatory in Scrum, which is an Agile methodology, but they're not mandatory to BE Agile. test is …
answered May 22 '13 by pdr
3
votes
There certainly doesn't have to be any correlation unless one team is working both projects in parallel. Then there must be, or the business cannot choose the priority work. If two teams are working …
answered Nov 3 '11 by pdr
23
votes
Don't fight them on a systemic level. What they are doing is what Scrum means to them, so using the word Scrum to mean anything but what they're doing will not make any sense to them. Don't even figh …
answered Jan 21 '14 by pdr
32
votes
Stop code ownership. Make it equally likely for anyone in a team to work on any given task. There will almost certainly be some kick-back on that, because developers get comfortable with a specific a …
answered Feb 10 '14 by pdr
5
votes
Estimates do become out of date. We gather more information and learn new things, and some jobs will seem easier than they did a week ago and some will seem harder. Why do you think that's a problem? …
answered Feb 11 '14 by pdr
2
votes
sprint, and for QA to know when they expect jobs to be delivered). I have also worked on a team of two who used Agile estimation techniques and who kept a task board up to date, which is both useful …
answered May 4 '12 by pdr
14
votes
Oh, I do feel your pain. There are some serious changes you need to make to the QA team for this to work. My advice is to split the team into three teams: Feature testing - Fast turn-around on testi …
answered Jul 28 '11 by pdr
5
votes
(cause one thing I've learned is that if you lose the faith of the business, Agile gets exponentially harder to implement), get straight onto the long-term plan. Buy a copy of Jez Humble's Continuous … release and b) it'll improve your ability to respond to problems for them and c) it will buy them more velocity later. It's a rare company that doesn't want these things. It's certainly not an Agile
answered Jan 16 '13 by pdr

15 30 50 per page