Arthur put together some slides 3 different team in foundation have gone through agile training and developed some process mobile, fundraising, i18n team

agile manifesto principles

value individuals and iteractions over processes and tools
working software over documentation
customer collaboration over contract negotiation
responding to change over plans
emphasis on left rather than right

working software measure of success frequent releases through dev cycle

responding to change most critical according to arthur good example- might think a feature is essential spend time developing that and then discover in fact it's not quite what the user wanted

dev cycle in foundation varies across teams - we don't do waterfall and we don't do agile - do something inbetween (chaos/no plan/no delivery dates) embraces idea of change but no way to manage that

chris mcmahon has a friend who helped write the agile manifesto also worked for thoughtsworks who have been training us - has deep background he has been impressed by wikimedia projects that the rollback tools are awesome. Reverting is easy in the foundation. Is that agile or not? That's the culture? Awjr: allows us to embrace change but doesn't allow us to do in a structure way / reactionary/dangerous

Big A vs little a - developers scared by process - seems very enterprise little a takes different approach embracing philosphy of agile but strives to work it out in your team Our teams implement agile differently. Constantly trying to improve the way we do it based on needs of teams to keep us happy but also be predictable and productive

Tools in an agile team:

daily standup / scrum - get everyone together to check in

what did you do yesterday, today, what's blocking you timeboxed and short

retrospective - end of iteration team comes together and moans.

(we all seem familiar so stop)

i18n team

https://mingle.corp.wikimedia.org/projects/internationalization/explore_mingle use release concept, choose focus areas over range of sprints -8/9 end release cycle with bug fixing sprint every sprint 2 weeks team completely geographically distributed - never in same place for a sprint (12.5 hrs spread between time zones = challenges in our process) sprints - european morning (no aloita), siebrand - BA, scrum master, product owner (BA least) sprint starts every second tuesday 7am europe - with retrospective (30/40 mins) then cleanup backlog (1hr) - making sure all stories have been delivered and moved to next sprint if not using mingle use bugzilla for some stuff but to mainly deal with outside reports tech days and all staff 21 point story :-) velocity 42

   chris points out abuse of stories "implement database structure", "refactoring", "bug fixing" - very     vague. No suggestion of velocity

very transparent progress - make video/slideshow start of every sprint - takes time but valuable tasks are part of a story every story connects to a scenario

burn down chart most valuable chart

fundraising

https://mingle.corp.wikimedia.org/projects/fundraiser_2012/explore_mingle don't use story cards - tasks and defects estimated out by points - hours suck sprint velocity all over the place - reflecting losing/gaining team members velocity 35ish burn up rather than down track "ready to deploy" use a MoSCoW grid (must have, nice to have, won't have) - move stuff between lanes

general comment that velocity good and only way to measure cannot force velocity higher without bringing in new people increases predictability peter/katie product owners peter playing business owner role too katie has an awesome bot that publishes to irc mingle stuff

mobile

https://mingle.corp.wikimedia.org/projects/mobile/explore_mingle

mobagile newly adopted for WLM isanely difficult - new process and ideas whilst also trying to move quickly for WLM planning meetings inside a one week challenging however what allowed us to release a polished app in 6 weeks very very quickly respond to change and needs of community whilst pushing out new revisions no useful graphs (yet :)) increased satisfaction and productivity 1 week sprints going to switch to 2 for next project

siebrand: these methodologies allow us to focus. product owners constantly prioritise so developers know what to do and how urgent it is to do

agile distributes decision making effectively secondly a ritual/framework that calming influence on team no silos going forward agile hybrid form seems the way forward

swallings team disliked mingle = didn't get value from stories, couldn't customise system to requirements - doesn't work on a small team of 2 developers