Agile Software Development

It is sometimes hard to start implementing new feature (or fix a bug) by writing an unit test even for a very agile and experienced developer, that's for sure. But it pays off and it usually turns out to be the easiest and the most efficient way. Besides this, developers have to decide what to test. "You should test everything!" some of you may say, but what does it mean?

Should I test all my JavaBeans (as Java is the language I mostly use I will give examples in this technology)? Should I test all my Data Access Objects? Should I test all toString(), equals(), hashCode(), etc. methods? Or maybe I should test only stuff where I "integrate" all those "low-level" components/classes?

I'll try to answer the question of what level of abstraction should be tested by your unit tests and why some unit tests may be considered a waste in this post.

As a Scrum Coach, I often take on the role of Evangelist. Monday afternoon, I explained Scrum to the Swiss Java User Group[1]. Although not my first such talk, I had to completely rewrite the presentation. When this was 80% done, the realization hit me: How will I know if the “users” are getting what they need? Why am I not writing user stories?

If you are seeing this message we have just upgraded AgileSoftwareDevelopment.com. Not all the functionality has been ported to the new version of the platform yet (some might even no be ported at all) and there might be some elves running here and there, but the basic upgrade is done. You want see any immediate benefits, but it means quite a lot on the administration side - with the new version of the platform it will be way easier to customize the site, make it look nicer and more useful.

There is no single, authoritative perspective or definition of creativity. At least 60 different definitions of creativity can be found in psychological literature. However, a widespread conception of creativity is that it manifests itself in the production of things that are both original and useful. (from: Wikipedia)

Original
The basic idea of writing software is to produce code that has not been produced before. Techniques like object-orientation, component-based design, service-oriented architecture, and refactoring are all there to help you in making each line of code unique. Ultimately, software developers think that, in a perfect world, each piece of code exists only once. And in searching for this utopia, trying to prevent any repetition of work, software developers have far more possibilities than, say, writers, painters, architects, and hairdressers. None of these other creative people have a similar array of techniques for abstraction and indirection. (In fact, they probably don't even know what that is.)

Productivity is often confused with velocity. They're related, but they're very different things.

Velocity is the amount of work that you/your team can do in an iteration. In economics terms, productivity is defined as "the ratio of what is produced to what is required to produce" (source: Wikipedia). So, a person who can carve ten statues out of a lump of granite is more productive than a person who can only carve eight statues out of an equal size lump of granite.

At this point it's understood that we can't measure productivity when it comes to building software because there's no good, consistent, accurate way to measure output.

However, while we can't measure our productivity, we can often improve it. Without measurement we won't know how much of an improvement we've gained (or how much we've regressed), but we can measure improvements in velocity, which can indicate corresponding productivity improvements.

I used to publish weekly links on what was published on the web during a week. It happened to be quite difficult. What was sometimes particularly difficult was to figure out whether the article was fresh or not. I decided to continue publishing interesting links related to Agile. I will still try concentrating on fresh articles and publish link sets weekly, but won't commit to it. Most of the time the links will be published weekly and will concentrate on fresh content, but will also include links to older content that caught my attention during the week.

Top writing that caught my attention this week:

Title of this post is a paraphrase of great quotation, namely "Don't bring me problems, bring me solutions" which is or rather should be sometimes used by project leaders and product owners (also referred as managers later in this post). However bringing problems to Scrum Master is a very good idea - some problems are out of your control, especially those managerial ones (but this is a subject for separate post).

We, engineers, are taught to solve problems and we do it right. We are creative and intelligent people, hungry for non-trivial puzzles to solve. We should receive problem as an input and give solution as an output - that's it (of course we need a lot of communication in between, clarifications, details, etc.).

Why managers/leaders/product owners sometimes treat developers as machines to write the code? Why they don't trust developers and don't believe they really have knowledge and skills to solve many business and technical problems and turn them into working software? Why don't they accept the fact that when development team encounters any problem they will try to solve it and if they fail they will let them know.

Of course, it's not fair to say that every manager and leader has such mental problems I described above (I was lucky for most of my professional life) but let's focus on guys that really think they know everything and thus kill team's creativity.

As Scrum, XP and Agile mature, Teams and ScrumMasters are increasingly confronted with the problem of handling multiple distributed teams, telecommuters or nomadic team members who aren't able to just co-locate. For instance, a recent project for the Dutch Railways[1] involved 3 teams with a total of 15 developers and testers from Holland and India. This constellation presents many special challenges in addressing impediments, assuring communication and collaboration despite language and time zone differences, and picking tools and technology.... Given these challenges, how does a distributed team perform the Daily Scrum?

Each project is different and has its own special needs and requirements. Is there a common language? If not, then how can communication over the language barrier be assured? Are there multiple teams at multiple locations or one team with scattered members? Project management is about the art of the possible, so how the Team(s) should organize itself/themselves will depend on their actual situation.

Last week the entry on risks on solo programming attracted a number of comments debating the value and costs of pair programming (PP). My personal observations and discussions do support the claim of better quality and faster development, when pair programming is done the right way and learned under the coaching of experienced mentor. However, these are just my personal observations and I was rarely focused on measuring and "average" team, most of my observations were based on teams who did want to pursue the path of continuous improvement and were interested in learning how to do the practices the right way.

Gathering data

Anyway, I promised to gather a bit of scientific evidence and here it is. This is not an in-depth scientific review, but rather a result of couple of hours spent on browsing Google Scholar and IEEE Xplore and skimming through the top articles related to "pair programming defect rate" and "pair programming quality". Most of the articles happened to be about the students doing pair programming.  Taking into account the industrial context of original discussion, I decided to ignore most of the articles that involved only students. Note, that for purity I was trying to examine solely the effect of pair programming on quality, defect rate and corresponding costs.

Full disclosure: On Agile 2008, I was asking Pyxis Technologies about the possible sponsorship of this site. It didn't proceed further but at some point I am going to get back to the topic.

Lately I discovered that since last time I paid close attention to Agile methods related tools they did improve much. On Agile 2008 I visited many if not all of the tool vendors booths and in the coming weeks we will probably publish a number of reviews. Before I left for the conference one of the AgileUkraine group members asked me to have a look at the GreenHopper software. This post is exactly a result of the quick look I was asked for. It is no in-depth review, just my impressions after the demo made on the conference and after the extensive interrogation of a Pyxis representative who demoed the tool for me.