Mike Cohn and others present their case to why you should consider structuring your teams around software "features" rather than software "components".
IBM Rational and InfoQ preent an eBook, Scaling Agile with C/ALM, "dedicated to all of the functional and dysfunctional organizations that are eager to break down the organizational and cultural silos, and become a finely tuned software delivery machine." The eBook explores the barriers to team integration and scaling and then shows, in detail, how to overcome these obstacles.
IBM announces three new ways for businesses to utilize cloud computing: standardized services on the IBM cloud, private cloud services behind the firewall (managed by the business or IBM) and Cloud burst a way to seamless incorporate secure public clouds to accommodate "overflow" demand for services.
Promoting, sustaining, and evolving agile practices in an organization requires expertise and experience. Initially, many companies bring in outside experts to help get things started. Laura Moore has described a model, based on the Blue Angels, which companies can use to develop and deploy internal experts.
There have been a lot of discussions and debates about the optimal team size for maximum productivity. While most Agilists agree that smaller teams are more functional and productive as compared to larger teams, however defining the optimal team size is still a challenge.
Scrum has proven effective at promoting communication between members of a development team. The question of how to scale this high-bandwidth communication across teams, especially in large organizations, remains an area of active exploration and debate. Will Read has proposed a mesh-network inspired alternative to the popular Scrum-of-Scrums meeting for achieving this goal.
The Scrum of Scrums meeting "is an important technique in scaling Scrum to large project teams. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration." Allan Shalloway asked for people's experience "on Scrum-of-Scrums for coordinating teams vs scaling Scrum to the enterprise" he sees problems in with large groups (350 people).
The recent release of Clover 2.4 highlights a new "Test Optimization" feature that offers to speed up CI builds and allow developers to spend less time waiting for their tests to run. The feature leverages "per-test" coverage data to selectively run only the tests impacted by your code changes.
Despite increased adoption, many of the SOA projects are still failing Things are often getting so bad that in a recent SOA was called "Dead on Arrival". One of the ways to improve this situation is proper SOA governance.
Most Scrum adopters have their first doubt in terms of its scalability. Tobias Mayer suggests that before looking into quick solutions for complex problems, adopters should focus on understanding the principles of Scrum. Once the foundation is correctly laid, Scrum will take care of scaling itself.
Greg Smith offers an in-depth practical perspective on making your agile transition just as much about culture change as it is about process change.
MomentumSI released yesterday its SOA Framework -Harmony. It contains 5 perspectives which include Lifecycle, Governance, Technology, Maturity Model and Information Model. A SOA Framework is typically used to structure the organization, processes, activities, metadata... deployed for service construction.
What is an iteration in the Agile world? How is it different than previous ways the software community has performed iterations? Are there different types of iterations, and does it matter? The ScrumDevelopment list has been recently discussing type A, B, and C sprints (sprint = iteration in Scrum terminology) as defined by Jeff Sutherland and the ideas are relevant the the wider Agile community.
Carrying on from last year's survey, Scott Ambler published the 2007 Agile Adoption survey this month. InfoQ provides some analysis of his findings and asks readers how they would approach getting a single view of Agile trends from across the community.
Using Agile methods with large teams is a reality - the old Agile = Small Team equation is no longer valid. Nonetheless, team size is still an issue. How important is team size and what, if anything, should we do about it?