Category Archives: Agile

Bowling Kata “solution”

Posted on by
2

One of the most famous katas (excercises) for TDD (test-driven development) is the Bowling Kata. There are some sites that describe the Kata, which has the following “stories” as input:

  • A bowling machine want to report the number of pins the player strikes down for every roll the player does
  • A bowling player want to see the resulting score of a completed game

It is actually a rather simple Kata, but never the less allows for demonstration and training of some TDD tasks and strategies. But of course you need to know the bowling rules…

We have used the Bowling Kata for our Coder’s Dojos, and have learned a lot from it. The following is a recording of one of my solution to it :

CHAOS or not?

Posted on by
Reply

The CHAOS reports from the Standish Group has become infamous, so much so that Sean Hanly made us promise to never quote the figures as evidence against the traditional models. However I recently found an interview that Deborah Hartmann at InfoQ did with the Standish Groups founder and chairman Jim Johnson. In the interview Deborah asks some really interesting questions and Jim’s answers seems straightforward and honest. The relatively fresh statistics presented is interesting, but most interesting of all is the list of success factors, where it is obvious that the Agile values and methods addresses most of the top 10 with concrete techniques.

What is “Agile” all about? Really?

Posted on by
1

This is actually post that I did over at forum.agilesoftwaredevelopment.org in a tread with the above name. Finally I was prompted to articulate some of my thinking around this “popular” issue.

Ursprugligen inlagt av RonJeffries

Originally posted by red2
Wouldn’t you also say that Agile was a framework for enabling intuition to be quantified within an environment which prefers more empirical measurements? After all Agile would seem to be about divesting control from procedure to people.

I would certainly agree that agile is about moving the center of control away from procedure and toward people working together.

I would also say that partof what Agile does is enable “intuition” to be applied.

However, I’d want to be careful with the term “intuition”. It’s a weak, and perhaps dismissive term when we use it to describe the combined experience of a group of people, brought to bear on some problem, when they are freed from their cubes and are enabled to work together.

Who am I to disagree with one of the original signatories ;-) but I am not sure that I agree that the “agile is about moving control away from procedure”. I think is actually an effect of the fact that most procedures used currently does not make it easy to become “agile” enough.

What I mean is that since most current procedures are stipulatory, rigid and founded in other values than the “true agile values” (which I’ll come to in a second), they will not be possible to follow to achieve true agility. But there is no inherent conflict in procedure and agility, just look at XP. It is full of procedures, but achieves high degree of agility. Daily stand-ups is certainly procedure!

Agile is not about techniques either. Techniques are, as procedures, just a tool to get to the result, so we must look beyond both to find the “true agile values”.

*I* belive that the true values of agile is what it delivers to the stakeholders of the activities. E.g. delivering software that is usable for purpose, delivering business values or whatever the primary stakeholders require.

The techniques, and tools and procedures, that we apply are only secondary. However, there are some techniques, tools and procedures that we agile people think *must* be applied to deliver on that stakeholder interest, which are different than what we previously have thought, and been taught. Namely, an intense closed feedback loop! To optimize this feedback loop we find that it does not work to do big design upfront, waterfall projects, etc. etc.

Instead, to tighten this loop, we communicate directly with customers and users, develop a single feature at a time, get concrete feedback, and so on. The more we can tighten this loop the more efficient we are able to deliver the best result possible to our stakeholders.

Agile is not about a fuzzy feeling of people getting together. It is based on hard, cold evidence that tight feedback loops are the best way to deliver in this world of constant changing requirements, “I know it when I see it!”, and developing features no one can imagine the full impact of. One of the most important factor in tightening this loop is to get people to talk to each other, but that is not an agile value. It is a necessity to deliver on the true agile value: best possible working software/system/product with the given resources!

Would agile have developed if Waterfall would have worked? I would say no. Agile has evolved because previous thinking did not perform to our satisfaction!

“Pairing with Thomas”

Posted on by
Reply

I came across Ron Jeffries book Extreme Programming Adventures in C# on Agile Alliance members page, a book which he thinks should be called “Pairing with Ron”. It’s about the development of a small XML editing tool he did. But it describes every little test, refactoring and other anecdotes that are relevant.

I thought this to be fairly interesting, and since I have just started on a similar journey I though I’d start some kind of log of it here. Of course I have already done some basic things so I try to make this log catch up quickly.

I am trying to build an Object Application Modeller. The basic functionallity is to be able to define classes with attributes, relations and views. I have seen many applications where this is actually the basic functionallity, so maybe this tool exists already but since it’s a journey the goal is not the value, the journey in itself is.

The trick is to be able to “generate” an application from these definitions, with support for persistence of the instances of the classes and relations of course. *AND* with the possibility to upgrade, which will introduce the need to refactor the persistent storage (a.k.a database) on upgrade.

I’m sorry that I will not be able to remember all the steps I have already taken, but here are the initial list of User Stories:

  • Define and Delete a Class
  • Save an Application Definition and Restore it
  • Add a (String/Integer type) attribute to a Class and Delete it
  • Create instances of the defined classes (implies deploying the Application)
  • Display instances as a table with attibutes
  • Select which attributes to show
  • Sort and filter data according to specific column
  • Define Relations with attributes between specified Classes
  • Show instances with attributes in a tree using a specific relation showing attributes
  • Show instances with all relations
  • Deploy an updated Application Definition to an existing Application

So I started with a test that creates a Dictionary, adds a Class to it and then looks up that same Class. No problems there, implemented the Dictionary as an ArrayList which took Class.

Then save and restore, almost as straight forward. Decided to use a simple text file with one line per Class.

Then, GUI! Since many have talked about thin GUI:s I first decided to use the Eclipse Visual Class editor to just add a simple GUI on top of the functions. That was just somewhat successful. And it felt bad. Why couldn’t I do TDD on the GUI?

Having introduced Automatic Testing of the webapplication in my current project I knew there where a multitude of GUI testers, but I surely did not want to go down the path that lead us to Mercury Quicktest Professional!!

But I found Abbot, “A Better Bot”! It drives and inspects Java GUI, and JUnit functionallity to boot! So I added some tests to drive my GUI components, and of course I had to refactor those a bit to make the testing easier.

So now I could add tests to drive adding attributes. And since I implemented those as ArrayLists too I refactored out an ItemList to hold Items which became a super class to Class and Attribute.

I have just added a test to drive adding attributes from the GUI. The first test is to select a Class, press the Edit button and ensure that an “Edit Attributes for Class” window appears. And that’s where I am now.

To be continued…

Back from the Agile Business Conference

Posted on by
Reply

Well, we’re back. We participated in the Agile Project Leadership Network Summit as well as the actual ABC. Being three of us we managed to cover most of the presentations. Of particular interest was the British Telecom decision to transfer their 14000 persons IS/IT business to Agile. There where some ups and some downs, perhaps I’ll transform my notes into a blog entry in the near future.

Coder’s Dojo Sweden is open!

Posted on by
Reply

Yesterday Andreas Larsson and myself hosted the first ever Coder’s Dojo in Sweden. If you have never heard about it before you can visit its home page and explore more.

It was an interesting experience. Having run through the Bowling Kata a number of times, both together and by ourselves, we still found that discussing with people was a learning experience since many of the attendees did not have the experience we did. And as always, talking about something forces you to be clear in a way you don’t need to otherwise.

My personal insight with the Kata the way we played it out (inspired by Uncle Bob’s presentation of it) was how strong the urge to create new classes is in all of us. Andreas and I fell into that same hole when we did the Kata in Oulu the night before XP2006.

I also discovered that I had insights that I where not aware of with regards to the brittleness of testcases; that you should be careful to test the intended behaviour, and not the design. E.g. when doing the first test case for the Bowling Kata, don’t test that the score of the created (presumed empty) game is zero. That’s implementation! The required behaviour (and the only thing that should be tested) is that calculating the score, after all the rolls of the game, should give the correct result.

And of course, you can find a lot of thinking on the BDD (Behaviour Driven Development) on the web.

Development is Investment

Posted on by
Reply

One irritating circumstance in the world around development is the fact that customers and company managment tend to view the voyage of development as something that has to be calculated like any other investment. Or at least I thought it was irritating until last week.

This investment calculus that has to take place upfront drives big design upfront, detailed planning and everything bad that goes with a model with “upfront” in it.

But last week I had a discussion with my two collegues about how to draw a curve illustrating the fact that we need to get early payback from any development project or activities. I suppose you have all experienced the fact that given multiple checkpoints a long the way, as opposed to only a single at the end you are much more likely to hit the target (after all that is what being agile is all about).

We started talking about how to visualize the fact that worked hours (the most common tracking parameter for development projects in the world, it seems) is not a good way to measure, and consequently show in a follow-up diagram, project progress. Instead it is the value of the current development result that should be put on the y-axis. This is actually nothing new (what is?), already function points and earned value are classical methods to do something this.

But the real insight here is that if we just could turn this earned value (which in agile terms of course is working functions delivered) into money we would be in a position to argue all the benefits of agile thinking to management and into the contract problem area.

Why? Because to a company executive it is easy to understand that the value returned did not come from exactly what we planned but we could still cash in the same value. Dollars for dollars, as it where. This opens up a possibility to work agile in rigidly contracted environments also, if only we can formulate the contract in terms of investment and return on investment.

So how would we estimate progress in terms of ROI? Well, I guess that anyone that can guess the ROI on a completed product, given some essential functions and properties, could also do a fairly good job of estimating partial value of same. So, do an earned value estimate on each function (or story or UseCase according to your preferences), follow up on that, and handle any change in features also as a change in the earned values. Then trade one earned value for another and, if they are comfortable with the estimated values, they will have no objections to whatever changes your agile project uncovers or requires.

A Vaccum Cleaner and an Aircraft

Posted on by
Reply

What is the similarity between an aircraft and a vaccum cleaner? Often product developing companies get stuck in old thinking. No surprise there, but what I mean this time is their thinking about what is their primary competence and as a consequence of this, how they need to think about their product development.

Apart from the pure software products there is a large number of products being developed out there, which, some decades ago where hardware only, but now also includes software, often increasingly so.

Since the company has successfully developed products according to rules and conditions which are valid for a hardware only product, it is often difficult to make managers on all levels to understand that once you introduce software in a product, you are in a completely different ballpark.

Software has completely different characteristics, different minimal lead times, different complexity properties which must be taken into account when organising product development. This is is not only a difference, it is also a set of opportunities to exploit. One of the more obvious opportunities is the the short lead times possible, which, if done correctly, could mean shorter time to delivery, shipment and return on investment. This means, of course, becoming more agile, but it doesn’t stop with the development - project, product and company management must embrace the agile principles and change their thinking.

If you cross a vaccum cleaner with a computer you get a computer, and if you cross an aircraft with a computer you also get a computer!

One you introduce software in your product you are stuck with new values, characteristics and opportunities. Too many developing companies fail to exploit these opportunities for rapid return on investment and improved quality.