Skip to content

Category: XPSyndicate content

State of Agile

October 9, 2009 by Jack Milunsky


Seems like there's lots going on in the agile world right now. Lots of talk about Lean and it's impact on Agile. Lots of attacks going on at the CSM certification. Kanban is all over the news these days. And just last week, I read about a new Agile methodology called Stride.

So how do we make sense of this all?

My opinion is that there is value in each of the methodologies (for the purposes of this blog I'll refer to them all as methodologies even though some of you might not think of them as such). It's real important to read about them all so that you are armed with enough knowledge to know what's out there. I see this as a toolset from which you can choose for your specific situation.

Agile Certification: Love it or hate it, but deal with it!

April 8, 2009 by Peter Stevens

Recently, Scrum and the Certified Scrum Master program in particular have come in the crosshairs of non-Scrum Agilistas and been condemned as a Bad Thing. Martin Fowler wrote about Flaccid Scrum. James Shore, author of The Art of Agile Development explained why he doesn't do agile certification. Certification is about mediocrity and agile is about striving for greatness.

If we believe that agile is eventually going to become the mainstream software development strategy — and I do — then this attitude misses the mark. In a time when every office worker gets told 'A Microsoft Office certification is good for your career,' it is clear that certification is part of the game. We may not like it, but we ignore this reality at our peril.


March 31, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

Extreme Programming postulates, that courage is one of the fundamentally important virtues of an agile developer. I would augment this postulate and claim that it is, together with talent, THE most important one.

Why? Simple. Courage lets you overcome any and all obstacles that may stand in a way of developing a fine piece of software.

For example, I have seen a lot of cases where a programmer would shy away from an interesting project, because thay claim that thay lacked knowledge and expertise in the particular area. Or – the subject matter seemed too hard. They felt not „worthy” to try. Let me be a bit controversial and say: lack of knowledge does not matter. The courage to learn new stuff does.

Scrum and XP from the Trenches: Russian Edition

December 6, 2008 by Artem Marchenko

English summary below.

Scrum и XP: заметки с передовой" – это книга подробно рассказывающая о том, как одна конкретная компания использует Scrum и XP в своей работе. Хенрик Книберг, шведский консультант по Agile и Java, делится опытом применения Agile в своей компании, описывает подход к планированию, тестированию, координации нескольких команд в рамках одного проекта и многое другое.

В течение последних четырёх месяцев группа украинских энтузиастов организованная Алексеем Солнцевым переводила и перевела книгу на русский язык. Ваша покорный слуга принимал минимальное участвие в редактуре, однако тоже был удостоен упоминания в предисловии к русской версии. Скачать книгу можно здесь (ссылка на pdf).

Customer Team Member - a way to winning together

November 13, 2008 by Przemysław Bielicki

Used by permission.
Copyright by Paweł Niewiadomski

One of the core XP practices is having a Customer Team Member. It means that development teams have access to the newest information from the customer's side and they know about all changes in the requirements very quickly. Having on-site customer (or customer proxy for commercial products with lots of potential customers) ensures that requests change informally, the process becomes flexible, and saves the cost of formal overhead.

In this post I would like to take another look at this practice. I would like to share with you my thoughts why having a Customer Team Member can help the development team win together with their customer. And I would like to take a "social" view on this practice.

Can unit testing be a waste?

August 28, 2008 by Przemysław Bielicki

Picture courtesy of Kecko@flickr

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.

Vacation Reading

July 30, 2008 by Peter Stevens

Twas the night before my vacation
and all through the house
not a creature was stirring,
not even a mouse....
Oops, wrong season. But given that the scrumdevelopment list is preoccupied with profound issues like 'Why are we still allowing the term 'Agile Project Manager' (75 Postings) and 'Appropriate Postings' (62 Postings and counting), it is clear that the time has come to stop and recharge our collective batteries. For me that means reading, doing Sodokus, and spending time on the beach with my family. So here is look inside my backpack, as I head off to Rügen...

XP Practice: Pair programming

April 18, 2008 by Artem Marchenko

Pair programming is one of the most known Extreme Programming practices. In essence it means creating the code in pairs trying to get multiple perspectives on the code created. One of the participants, called driver, types the code and thinks about the low level details. Another one, called navigator, thinks about what the typed code is for. The participants periodically switch roles. The definition of "low level" depends on the skills of the concrete pair and their experience in the subject area. For example, when using test-driven development the driver might be focused on the writing the production code, while the navigator could be thinking about how the next unit test should look like in order to change the system architecture in the desired direction.

XP Practice: Incremental Design

March 28, 2008 by Artem Marchenko

In traditional software development the design phase happens in the beginning of the project, takes quite a long no-coding or little-coding time. At the end of the phase, the design is considered being more-or less frozen. It might sound logical to plan ahead in a detail, however, in the case of software only the final source code is the real design - any diagrams or descriptions can at best be the higher level design abstractions. Therefore attempts to fix the design well in advance often lead to the wrong assumption and sub-optimal solutions.

XP Practice: Test-First Programming

February 18, 2008 by Artem Marchenko

Test-First Programming (TFP) and its sometimes more known related practice Test-Driven Development(TDD)  are not very usual for the traditional software development cycle. Test-driven development simply means creating tests before writing the code they are supposed to test. A canonical test-driven cycle is as follows:

  1. Write a test for the functionality you are going to implement
  2. Write as little code as possible to make the test compile. Make sure that at this step the test fails
  3. Write minimal or almost minimal code needed to make the test pass
  4. Once the test passes, refactor the code to make it better, prettier or simpler. The test and other existing tests will guard against accidental functionality breaks during the refactoring process

Best of