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 Oct 27, 2008
A recent discussion thread on the Scrum Development Yahoo Group examined the value of process checklist tests such as the Nokia Test or the Joel Test. Some see these tests as the starting point for a rich agile maturity model, others worry that this could lead to prescriptive approaches to agile, which would miss the whole point of inspect-and-adapt entirely.
Bas Vodde is generally credited with creating what Jeff Sutherland later named "The Nokia Test." Bas described the history this way:
The "you are not agile when" slide was created about four years ago within Nokia Networks (now Nokia Siemens Networks). The purpose was, for the Agile coaches (!!) to quickly evaluate whether a product is actually serious in its move to Scrum. It was the minimum bar, if a product is not even passing these points (we do Agile, our iterations are 2 months long) then it might not be worth to put effort in coaching them (yet).
...
The simple list ... ended up in a presentation I gave about Nokia Networks, which made it public. Jeff found it a useful simple list, took it, and called it "the Nokia test" (it was simply called "you are not doing iterative development when...").
Overtime it got "improved" into something different, but the name always kept the same.
Peter Stevens shared his experience tweaking the Joel Test for use in his own practice.
My goal on modernizing the Joel test was to get a tool to help me as I start coaching a project which is struggling to be agile. But I discovered quickly that the questions are not that helpful. The real problems become obvious very quickly as I watched the team do its sprint retrospective and sprint planning. Reacting to what I see is more important than doing an academic evaluation.
Tathagat Varma suggested that instead of asking "Are we doing these practices?" that organizations should examine the results of their practices in areas such as: employee motivation, team productivity, and customer satisfaction. At this point Ron Jeffries joined the discussion, pointing out that examining results won't tell you if a give approach is agile.
I mean that not all means of going after results are compatible with Agile values. The Agile values and principles can be found in the manifesto. Anything substantially different from those might be good, but it would not be properly called Agile.
All of this begs the question, "What is the point of the test?", or more specifically, "What do you hope to learn from applying it?" Bas, the originator of the "Nokia Test" shared this these thoughts.
Related to the original questions, are these tests useful? It depends very much on what you use them for and to make sure that the people who use it actually understands what it means (as it was only 5 questions...). In general, I do not find "agile maturity model", "Agile assessment models" or "agile tests" useful since they tend to be a simplified view on a complex subject.
It would seem that the 'Nokia Test' served its original purpose, to help the agile coaches at Nokia determine which teams might be ready to benefit from coaching. Can it be adapted to other purposes? While the answer is almost certainly yes, many caution against applying it without carefully examining, and possibly adapting it first. Jim Brosseau had these insight's back in December of 2007:
First off, I think that if you are not Nokia and you have decided to use this test as your golden standard, you have already missed the point about agility. No single defined approach will ever be optimal for all your projects in your organization.
Jim then went on to disassemble the Nokia test, separating general concepts, which might be more valuable, from situation-specific details which might not be appropriate in other environments.
In the end, what can be learned from all of this discussion? Simple checklists can provide a useful quick-and-dirty assessment. They won't tell you if the practices are actually delivering results. In the end, a checklist is no substitute for an understanding of the agile principals and practices along with insight into how they might be effectively applied in a given situation. This, combined with a culture of inspect-and-adapt (continuous improvement) is likely the real key to a high performance agile implementation.
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!
In fact I've started the discussion with this post
Are we agile yet? Grrrrr...
I've also touched in this-
agile-commentary.blogspot.com/2008/10/how-do-i-...
IMHO The real value of this or any other set of measurements is to start a conversation. As a coach I use a larger version of this test to give me an idea where teams are at. It's not the be all and end all but it can be a great starting point - i.e. here are the areas that bear closer examination. Example: In a team of seven every team member but two say the team is doing TDD. Hmmm, what's going on. Ask more questions.
On the other hand if you actually look and care about the numerical value then you've missed the whole point.
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.
3 comments
Watch Thread Reply