This article is based on Chapter 6 of Becoming Agile by Gregory S. Smith. It discusses the feature of a good pilot project when you transition to Agile.

This article is taken from the book The Art of Unit Testing. As part of a chapter on the pillars of good tests, this segment shows how to remove duplication from unit tests.

Confessions of a serial product owner is a short guide to a business person aiming for becoming an excellent product owner. Based on the personal experience of Anna Forss.

CMMI is the successor of the Capability Maturity Model (CMM) or Software CMM. The CMM was developed from November 1986 until 1997 as part of the software process maturity framework project. Then the CMMI, where “I” stands for Integration, replaced the CMM. This is certainly not currently a hyped concept. You will find no CMMI category on dzone.com or infoq.com and the CMMI channel on reddit.com has two subscribers. A recent Methods & Tools poll examined at what stage is the CMMI approach adoption in software development organizations. I was therefore surprised to see that the adoption, ignorance or rejection rates for the CMMI were very close to the results achieved by a similar survey on Agile approaches ended at the beginning of 2008.

This article is taken from the book The Art of Unit Testing. As part of a chapter on integrating unit testing into your current organization, this segment answers one of the key questions involving unit testing.  

A description of the approach used by Yahoo International in its transition to agile software development.

Ruby on Rails is probably the most talked about and most controversial Web framework since the Internet was invented. After reading this gentle introduction, you will finally know what people all over the world are raving about!

My friend Steve is an exceptional classical guitarist. Watching him perform is inspiring – he has a rare mastery over the instrument and has spent years developing his craft. Steve can also explain the techniques he is using while he is playing, to teach and demonstrate how a student can learn and improve their own skills. Steve can make a guitar sing, and says that music is about tension and resolution. If music is all tension, you get uncomfortable as a listener. If it only resolves, it is boring, tedious repetition. Steve extends this concept to the actual physical actions that a guitarist employs to create certain sounds. For example, if you play with a lot of tension, you will limit your ability to do certain tasks. To make music, you need to find a balance between tension and resolution, and to find this balance, you need a mix of knowledge, skill and creativity.

Like Steve, my friend James Bach is also exceptionally skilled. James isn’t a guitarist, he is a software tester. James is also inspiring to watch while he practices his craft. He is a master of skilled exploratory testing: simultaneous test design, execution and learning [1]. James can also explain the testing techniques he uses while he is testing, to instruct testing students. The first time I saw him test software, I was reminded of my friend Steve. This time the tension and resolution wasn’t related to music composition or the execution of techniques on a musical instrument. Instead, the tension and resolution revolved around ideas. James would simultaneously design and execute tests based on his curiosity about the application. He would get feedback on a test, learn from it and design a new test. The tension was generated by the questioning nature of his tests, and the resolution emerged from the results of those tests. There was something almost musical in this interplay between the mind of the tester and the application being tested. This shouldn’t be surprising; as a software tester, James has a well-developed mix of knowledge, skill and creativity.

We are transitioning from a period where agile adoption may have been underestimated to another where it could be overestimated. Previously, some developers would not define their practices openly as agile or extreme programming because manager would have considered it a "cow-boy process". Today, some companies will pretend that they are agile, but without implementing the essence of the approach. Comparing the 2008 and 2005 results, we could notice that the level of ignorance of the agile movement has decreased, as only 13% of the organizations are ignorant of it. Full deployment numbers have doubled in the recent years to reach 17% and total rate of various adoption levels is now 56% compared to 41% in 2005.

By not segregating customers and users from the designers and developers, but rather enabling them to work together in a single team, it is possible to use the agile approaches such as DSDM, Turboprototyping, SCRUM to achieve perceptible results. Multidisciplinary teamwork is based on being able to find suitable team members, doing work in workshops and visualising requirements, ideas and decisions with lo-tech tools. This formula has enabled successful teamwork in a number of IS projects in recent years.

During recent years, my colleagues and I have had to adopt new approaches in most of our IS projects. Two of the contributing factors have been the influence of dot.com boom and the increased focus on a well-designed user experience. Having alternated between traditional and agile methodological approaches, I have ensconced myself in the agile camp. So most of my recent experiences are from agile processes and projects using either the DSDM project framework or TurboPrototyping, a teamwork-based approach we pioneered (Ghosh 1999).