New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Chris Sims on Nov 03, 2008
Ade Miller , development manager for Microsoft’s patterns & practices group, has published a paper on distributed agile development, highlighting the challenges of trying to do distributed agile development, along with recommendations for addressing these challenges based primarily on the experiences of teams within the Patterns and Practices group at Microsoft.
Microsoft’s patterns & practices group has been following an agile, distributed development approach for the past five years. During this time teams within the group have experimented extensively with different approaches to best address the challenges of distributed agile development. This paper outlines the challenges faced by geographically distributed agile teams and details some proven practices to address these issues and build successful distributed teams.
The paper starts and ends with warnings that a distributed team is likely to be less effective and more dysfunctional that one that is colocated, and thus a recommendation to prefer colocation to distribution whenever possible. It then goes on to identify areas that the patterns and practices group has focused on, in order to make their distributed teams as effective as possible. The article includes this list of Dos and Don'ts, based on their experience:
Do work to maximize the available communication bandwidth available to your team. Provide communications tools—like conference phone, Web cams, and hands free headsets—for your team and help them adapt their existing practices to distribution.
Don’t continually reorganize your teams for each new project. Building teams takes time, building distributed teams takes even longer. Maximize your investments in team building by minimizing churn on teams.
Do plan to travel, especially at the project’s pivotal points. Bring everyone together for the first couple of iterations, periodically during the project, and right before final release.
Don’t distribute the work by system components, focus on user stories. Avoid organizing distributed teams by function—for example, the offshore test team. Both these approaches create knowledge silos within the team.
Do provide tools to augment or replace those that only work within a team room—like a work item tracking system to replace sticky notes on whiteboards.
Don’t let remote team members be forgotten in team meetings. Pair them up with a buddy and try putting everyone on the same footing by having all members call into conference calls at least occasionally.
Do evolve the team’s practices as they identify better ways to deal with the challenges of geographic dispersion. Frequent retrospectives are the key to getting a team to consider how to improve.
Don’t forget to include everyone in frequent team retrospectives to identify what does and does not work for the team.
Do focus on coaching. Make sure everyone understands why agile practices need to be adapted for distributed development.
Are you working on a distributed agile team? Leave a comment and share some of the challenges you face and some of the ways that you are addressing them.
Transforming Software Delivery: An IBM Rational Case Study
Case Study: IBM's Agile Transformation
SCM best practices for multiple processes, releases & distributed teams
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
No comments
Watch Thread Reply