StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <ul> <li>Larger and more distributed or more flexible teams need stricter coding and testing standards, small teams can (and should) use less. </li> <li>Process documentation should be minimal, real-time and current. </li> <li>Detailed statistical control indicators are an unnecessary overhead: early release of incomplete software is a better indication of progress. </li> <li>Ideally developers should be close to the customer with no specialised intermediate roles. Additional roles should only be used if customers are specialised in a way that stops developers from also being users. </li> <li>Iterations should be flexible unless it benefits coordination of releases with other departments or other processes. </li> <li>Developers should be able to easily and regularly communicate but meetings should be infrequent (monthly and weekly, rather than daily). </li> <li>Pair programming should only be used for training and investigational tasks. </li> <li>These guidelines are a starting point only: continuous improvement should be used to further tailor the agile variant to the exact circumstances. </li> </ul> </blockquote> <p>Coding / Testing standards IMO need to be implemented regardless of the size and distribution of the team. Having coding / testing standards leads to more managable / stable code.</p> <p>I agree with documentation. By using some Clean Code practices such as meaningfull comments and intent revealing naming conventions in your code then you remove some of the need for documentation of the code itself. Documentation should be at the business level and I prefer it to be in the form of Acceptance Tests.</p> <p>While having developers close to the customer improves with the iteration process, you need to protect the developer from the business circomventing the process by coming directly to the developer for additions/changes/scope creep. The Business still needs to follow the process through backlog grooming/prioritization etc.</p> <p>By using release iterations along with development iterations you can maintain a flexible schedule of your iterations that works for the team. Currently we work on 1 week sprint iterations with a release sprint every 3 to 4 weeks.</p> <p>The type of the meeting should dictate the frequency of the meeting. Daily standups need to be daily. They provide accountablity and transparency to the team which is vital in having a successful team. Retrospectives need to happen at the end of each iteration and that frequency is dictated by the size of your iteration. Other meetings such as code reviews, demo's should never be dictated on time but rather on need and completion.</p> <p>Pair programming should never be nailed down to specific types. We do pair programming with our QA Testers, our BA team so that both sides have a better understanding of the UAT's and Stories. We also do pair programming for knowledge share, prototyping, investigational tasks etc. In our environment pair programming has become second nature.</p> <p>Continuous improvement in Agile will become second hand nature as you learn to modify the practices of Agile to your business needs. So long as you don't stray from the Manifesto your Agile should be successful.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload