We solved this by creating an "Agile Business Analyst" the communicates with the Customer (mostly) and the Iteration Manger (therefore the devs as well - oooh happy families!) and helps them generate appropriately sized stories for the Dev's to estimate.
This is amazingly powerful as the customer then feels a lot more secure that they're 'doing things the right way', they catch on quickly and after a while only really need tweaking and you get well defined, well sized stories with decent acceptance criteria.
You're only truly an Agile developer if you can get into the office whilst nimbly avoiding Defect Story Cards (which may be on fire) and Changing Requirements Stories (that could be mined) hurled at you by angry testers and HCI people without getting blown up/having to do more work....
Agile helps a good team become excellent, it doesn't fix the problems in a dysfunctional team.That's true, however it can help a dysfunctional team become a functioning, good team through standard Agile Review Practices and exercises. Everything in Agile is about the team and communication which means that if you were doing agile properly, you wouldn't actually get to coding anything until your team dynamic has been sorted out.
your team can't say yes to nearly all of the points on the Joel testSteps 8 and 9 hurt though:
8 Do programmers have quiet working conditions?
9 Do you use the best tools money can buy?
Quiet working conditions only in that there are no jackhammers near by and you're not in the flight path of the local airport. Co-location and the ability to overhear you co-pairs is an important part of a functioning agile team.
And it's definitely NOT all about the best tools money can buy - it's all about the right tools. Simplest thing that makes sense - and if that is an open source tool then all the better (in my view). More money for Cake and Beer during your iteration planning meetings...
Slashdot Mirror
>Analyse, Design, Implement, Verify, Deploy, Maintain, Repeat.
You've just completely left out the TDD-ness of Agile here then. Also the refactoring that makes your design Emergent. That would make it:
Analyse, (reafctor if Needed), Design, Test (unit), Implement, Verify (test!), Refactor, Test (functional, integration), Deploy, Refactor, Maintain (Automate), Repeat.
So, testing and refactoring all the way then? mmmm Agile.....
We solved this by creating an "Agile Business Analyst" the communicates with the Customer (mostly) and the Iteration Manger (therefore the devs as well - oooh happy families!) and helps them generate appropriately sized stories for the Dev's to estimate.
This is amazingly powerful as the customer then feels a lot more secure that they're 'doing things the right way', they catch on quickly and after a while only really need tweaking and you get well defined, well sized stories with decent acceptance criteria.
That's not Agile! That's suppleness!
You're only truly an Agile developer if you can get into the office whilst nimbly avoiding Defect Story Cards (which may be on fire) and Changing Requirements Stories (that could be mined) hurled at you by angry testers and HCI people without getting blown up/having to do more work....
Agile helps a good team become excellent, it doesn't fix the problems in a dysfunctional team.That's true, however it can help a dysfunctional team become a functioning, good team through standard Agile Review Practices and exercises. Everything in Agile is about the team and communication which means that if you were doing agile properly, you wouldn't actually get to coding anything until your team dynamic has been sorted out.
your team can't say yes to nearly all of the points on the Joel testSteps 8 and 9 hurt though: 8 Do programmers have quiet working conditions?
9 Do you use the best tools money can buy?
Quiet working conditions only in that there are no jackhammers near by and you're not in the flight path of the local airport. Co-location and the ability to overhear you co-pairs is an important part of a functioning agile team.
And it's definitely NOT all about the best tools money can buy - it's all about the right tools. Simplest thing that makes sense - and if that is an open source tool then all the better (in my view). More money for Cake and Beer during your iteration planning meetings...
Ahem