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 Deborah Hartmann Preuss on Aug 06, 2009
A small 2008 study, showing that Agile teams were more performant than traditional teams, noted that: "Because it is based on numerous contributing and personnel elements, productivity is often the most difficult measure for organizations to improve." Tathagat Varma, general manager with a large provider of IT performance management solutions, wondered whether Agile's productivity improvements could be linked to how it improves teamwork, so he did an analysis of Agile values and practices ,mapping them against Patrick Lencioni's The Five Dysfunctions of a Team - A Leadership Fable. This article could prove useful for discussing the benefits of Agile with managers who have found Lencioni's books useful.
Lencioni's book uses a model of 5 dysfunctions (Lencioni's pyramid is inverted here to show how trust is the most basic dysfunction, and the other dysfunctions build upon in it)
Varma notes that:
... while Agile practices are explicitly aimed at ‘uncovering better ways of developing software', it also addresses the aspect of team dysfunctions subtly. Without directly asking people to change their behavior, Agile practices help overcome some of the most common team dysfunctions thereby creating a strong foundation for a team to perform upon. When the lower-level team dysfunctions have been eliminated, there is a strong foundation of mutual trust and an ownership and accountability of team commitments that helps the team stay focused on collective results without people promoting their personal agenda in the game.
Here is a summary of just a few of Varma's findings:
Trust: Beyond the obvious trust-building practices (Agile recommends face-to-face conversation, daily updates, retrospection), Agile teams are also small, so team members do not compete but generally have complementary skills and assignments.
Conflict: Agile teams engage together in activities like committing to work, decision making, customer demos and retrospectives. While so much "togetherness" could potentially increase strife, the Agile approach encourages what Lencioni calls "productive conflict" - such teams have lively, interesting meetings, extract and exploit the ideas of all team members and minimize politics.
Commitment: Agile's strongest point is that everything is driven and owned by the team - and progress and success is solely measured by team commitments that have been met.
Accountability: In addition to Agile's emphasis on clear commitments and frequent accountability, Agile teams are small and work closely together; every team members' performance is visible, creating personal accountability (through teamwork, not through pressure).
Results: Agile's short and frequent delivery of working software includes transparency about progress and value delievered, this helps minimize chances of grand failures; especially since, after each iteration, the team's progress is measured in terms of business value delivered.
Transforming Software Delivery: An IBM Rational Case Study
Case Study: IBM's Agile Transformation
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!
This article is right on the money. In my experience agile retrospectives provide an opportunity for the team to voice their concerns and reflect back on an iteration. Over time, agile helped the team I was part of improve in several ways - increased our effectiveness and level of trust and slowly got us all buying into the idea of jointly owning each other's code. Practices such as code reviews and continuous integration help team effectiveness as well - we got early warning about integration issues and improved the quality of our codebase iteratively. Finally, agile practices also help systematic reuse efforts that require strong teamwork.
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.
1 comment
Watch Thread Reply