Scaling Lean & Agile: Large, Multisite or Offshore Delivery
Recorded at:
- Share
-
- |
Read later
My Reading List
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.
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.
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Query
by
Ajay Kumar
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
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
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"?
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think