InfoQ Homepage Presentations Scaling Lean & Agile: Large, Multisite or Offshore Delivery
Scaling Lean & Agile: Large, Multisite or Offshore Delivery
58:14
Summary
Craig Larman presents practices and tips related to adoption, structure, requirements, contracts, architecture and design, offshore, multisite development, and coordination with large Scrum teams.
Bio
Craig Larman is a management and organizational-design consultant for enterprise adoptions and large-scale product delivery with Lean principles and large-scale Scrum. He is the co-author of Scaling Lean & Agile Development: Thinking & Organizational Tools, and Practices for Scaling Lean & Agile Development: Large, Multisite, & Offshore Product Development with Large-Scale Scrum.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Apr 20, 2011
-
Related Sponsored Content
-
Related Sponsor
/filters:no_upscale()/sponsorship/topic/c1372aee-0449-48ce-bab0-1b645fe8025e/QConLonndonLogoRSB-1667564544484.png)
Community comments
Query
by Ajay Kumar,
Great talk!
by Andreas Meyer,
Feature teams scale
by Andreas Meyer,
great stuff
by suba bose,
Query
by Ajay Kumar,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Craig,
I was able to understand your perspective on large scale software development model. One point which I am not convinced that if we do not set architectural constrains before starting development there are chances where each team can go in different direction to implement same common component. Example could be exception handling guideline or may be some common component. I have given two features to two development team and both the team may come up with different approach and different component for exception handling. This will not solve purpose of reuse of same component.
Thanks,
Ajay
Great talk!
by Andreas Meyer,
Your message is awaiting moderation. Thank you for participating in the discussion.
Well, found this talk very impressive and I feel impressed by the framework 1 and 2 and how this scales to such great number of teams around the world. I imagine how great it would be to work in such environment.
Ajay, I understand your point, but I think this is a high level view and in daily practise there arise so much problems and complicated situations, which are not shown here. Your architectural question is one of them, but there are a couple of more, like adressing the "right" feature team, and let them come/work together to solve the problems.
I'll believe architectural issues are demistified while designing sessions if the teams are addressed and dive into the problem domain. The architecture documentation past release is great :-)
I do fully agree with the crossfunctional teams, the role of architecture (and architects, no powerpoint architects) in agile development.
It sounds to me more KANBAN than SCRUM though some SCRUM ceremonies are manifested.
Great job, Craig. I ordered the books immediately to dive more into the details and get more tips.
Feature teams scale
by Andreas Meyer,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Craig,
most interesting is that feature teams scale and component orientated teams did not. You are assuming bigger components that only one teams owns, right?
Are multiple fine grained components in some requirements area that "owns" a team similiar to your what you have called "feature teams"?
great stuff
by suba bose,
Your message is awaiting moderation. Thank you for participating in the discussion.
key takeway: component teams lead to waterfall.