Note that there are some explanatory texts on larger screens.

plurals
  1. POHow to adapt agile to different companies? An MBA thesis
    text
    copied!<p>My master's thesis is to look at how to apply agile. </p> <p>There is an awful lot of corporate selling of agile - lots of management consultants selling their brand as 'best'. </p> <p>I'm not interested whether <a href="http://en.wikipedia.org/wiki/Extreme_Programming" rel="nofollow noreferrer">XP</a>, <a href="http://en.wikipedia.org/wiki/Scrum" rel="nofollow noreferrer">Scrum</a>, <a href="http://www.agilekiwi.com/crystal_clear.htm" rel="nofollow noreferrer">Crystal Clear</a>, <a href="http://www.agilemanagement.net/Articles/Papers/StretchingAgiletoFitCMMIL.html" rel="nofollow noreferrer">Agile-CMMI</a>, <a href="http://en.wikipedia.org/wiki/Six_Sigma" rel="nofollow noreferrer">Six Sigma</a> or any other brand/variant is best. I'm interested in what real, active developers (i.e. you guys) actually apply as agile.</p> <p>What I've investigated is how to tailor agile to different organisational requirements.</p> <p>From research into how different organisations apply agile I've developed the following guidelines - a recipe for what agile variations should be applied in what situations:</p> <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> <p>These factors change when applied in an organisation with existing traditional (i.e. <a href="http://en.wikipedia.org/wiki/Big_Design_Up_Front" rel="nofollow noreferrer">BDUF</a> or <a href="http://en.wikipedia.org/wiki/Waterfall_development" rel="nofollow noreferrer">waterfall</a>) models, where agile teams must either coexist with or be adapted from teams using non-agile methods:</p> <ul> <li>Process documentation with sign off and structured steps will help other teams track the project.</li> <li>Statistical indicators (like velocity) can help reassure non-agile teams that the process is under control. </li> <li>Fixed iterations will help co-ordination across teams.</li> </ul> <p>These additional guidelines will help agile co-exist with traditional models, but they provide additional overhead and restrictions.</p> <p>What I want to know is what you - the people who write software, not agile consultants - think of this framework. </p> <p>What do you think is accurate? What do you think is wrong? What would you change? What have I missed?</p> <p>Most importantly: why? </p> <hr> <p>I've added a bounty to this to offer an extra incentive to answer what is a rather long question. The bounty will go to whoever gets the most votes from the SO community - I realise that there's no single right answer, but I'm interested in what's closest to the community's consensus.</p>
 

Querying!

 
Guidance

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