jm + agile   6

David Jeske's answer to Why do some developers at strong companies like Google consider Agile development to be nonsense? - Quora
Wow, this is a great answer. As he notes, the Scrum-style process is flawed for big backend projects:

"This style of short-term planning, direct customer contact, and continuous iteration is well suited to software with a simple core and lots of customer visible features that are incrementally useful. It is not so well suited to software which has a very simple interface and tons of hidden internal complexity, software which isn’t useful until it’s fairly complete, or leapfrog solutions the customer can’t imagine."

And he goes on to come up with something which works better for Google-style projects:

Our highest priority is to increase customer (and programmer) productivity and access to information. Work on the biggest, most frequently used problems you can find, and create the largest net impact. Don’t give the customer what they ask for; understand them, and revolutionize their world.

Developers should create a Google Design Document (a fairly minimal, but structured design doc), explaining the project, what goals it hopes to achieve, and explains why it can’t be done in other ways. This document should be circulated with stakeholders, to get early feedback before the project gets underway. The written record is essential, as it assures there is a clear and agreed understanding of when the project is a success and how it aims to get there.
At all phases of the project, critical design elements for larger components should be concisely explained and captured in a design document.

Innovate in leapfrogs. It’s more important to finish and deploy a leapfrog than to attempt perfection. There is no perfection. Instead be flexible, and plan to constantly reinvent at every level of the stack.

Deliver working software as soon as is reasonably possible, and no sooner. “Dogfood” projects internally before they are shipped externally. Make sure products meet high quality standards before shipping. The quality of the product is more important than the time it takes to achieve it.
agile  architecture  google  scrum  development  coding  projects  project-management  design 
14 days ago by jm
Don’t get stuck
Good description of Etsy's take on continuous deployment, committing directly to trunk, hidden with feature-flags, from Rafe Colburn
continuous-deployment  coding  agile  deployment  devops  etsy  rafe-colburn 
january 2014 by jm
Kanban for MDN development
Mozilla's experience with Kanban. We've had good results in Amazon, too. good intro links in this post -- might start talking about it in Swrve...
kanban  scheduling  team  agile  mozilla 
may 2013 by jm
The best "why estimation is hard" parable I've read this week
'A tense silence falls between us. The phone call goes unmade. I'll call tomorrow once my comrade regains his senses and is willing to commit to something reasonable.'
agile  development  management  programming  teams  estimation  tasks  software 
february 2012 by jm
Andrew Tridgell's pair programming experience
Pair-programming with another SAMBA developer over the course of a year, using a SIP server and a VNC-shared desktop. very positive review indeed
pair-programming  xp  tridge  coding  collaboration  agile  vnc  sip  from delicious
december 2010 by jm

Copy this bookmark:



description:


tags: