Originally posted by RasputinDude
View Post
Agile's major goals include good, readable, well tested, well reviewed code (refactored to achieve these properties if necessary), written with adequate communication and stakeholder engagement.
It seeks to achieve this by breaking down the work involved in delivering a project into small, possible to estimate, achievable units that have a verifiable outcome (such as what counts as "done" for a unit of work - "done" could mean your code passing a set of test cases written beforehand).
While the recommended meetings like daily stand-ups, sprint planning and retrospective might be part of it, an equally if not more important component is effective use of agile engineering tools (things like test tools - preferably automated unit/integration testing, continuous integration, issue trackers, wikis, proper source control).
The stories and tasks need to build into a coherent architecture and not be made up as they go along
religion.
It has its holy book, its priests, evangalists and rituals.
It has its holy book, its priests, evangalists and rituals.
I have worked with some truly, truly, awful agile coaches and scrum masters.
But those ones tend to have come from a software engineering background and are pragmatic about finding real solutions rather than committed to a particular mindset.
Comment