

Ask HN: Agile development at big companies - mcantor

I work at a big company with dozens of websites driving our business.  There are almost 100 developers split up into system-based teams (Architecture, Billing, Content, etc.), almost as many QA testers, and hundreds of content managers, business analysts and other non-dev roles.<p>My team, Content Services, develops and maintains core APIs for the front-end developers; and we develop, maintain &#38; support a web app Content Management System used by our non-dev creatives, content managers and business owners.  We have 10 very skilled developers and a slim but effective support team for our CMS.<p>In terms of process, we are lightyears ahead of where we were even 3 years ago.  Since then, we have gone from opaque 6-month waterfall "iterations" to bonafide 2-week agile iterations.<p>However, agile methodologies were not developed by  teams at big companies, and in many ways, we are struggling to "own" the agile approach.<p>I am coming to you all for help: Does anyone have experience with this?  Given the context I've written and the pain points I'll detail here, can you see any quick wins or necessary process/cultural shifts?<p>- Our business owners don't write our user stories.  Generally our dev team analysts write the user stories after meeting with the users.  We have an enormous backlog of over 500 stories--remember, we're serving dozens of business owners working with different sites and types of content (everything from ecards to custom printable mugs).<p>- We have too many "epics".  Implementing a story and doing it "right" often involves so many layers of changes--from db schema to CMS interface to framework updates to API support to documentation to test cases to validation scripts--that fitting it into 2 weeks requires herculean effort and brain-bending cross-team planning.<p>- We now involve our stakeholders in daily standups and planning, which is GREAT!  But we have a lot of trouble with confusing them by talking about tech stuff.  There's just no reason for our content managers to know that CouchDB is having stability issues because our custom serialization module isn't handling unicode conversion properly.  But switching from "tech mode" to "business mode" is difficult, and many developers just aren't interested or capable of it.  Nor should they be, necessarily--a certain amount of specialization is necessary.  In a company of almost 500, you can't have everybody know everything.<p>What do?
======
gvb
Dennis Stevens gave an interesting talk on adapting agile techniques to big
companies (with big projects). The slides and audio can be seen here:
[http://www.screencast.com/users/SoftwareGR/folders/Software%...](http://www.screencast.com/users/SoftwareGR/folders/Software%20GR%20Meeting%20Recordings/media/f592aca5-4513-47b7-abd5-45b7c007d11e)

A short commentary on the talk is here:
[http://spin.atomicobject.com/2010/12/15/dennis-stevens-on-
th...](http://spin.atomicobject.com/2010/12/15/dennis-stevens-on-the-hardest-
problems-of-enterprise-software)

------
bartonfink
I've worked at a place that did a 'tiered' scrum, where developers would meet
at 9:30 and report, and then at 9:45 the tech leads would meet with business
analysts, project managers, etc. and report their group's progress. It seemed
to keep everybody on the same page, and it avoided the "tech to business"
switch you talked about for most developers. Further, the understanding was
that if you needed to talk to someone on the business side you could just do
it - there was very little separation.

The problem that place was trying to solve was that the standup meetings
simply got too big to handle - not everybody could give a meaningful status
update in 15 minutes. It's not "pure" but it did work, and you might be able
to take something from that approach.

