Words to live (work) by

Martin Fowler tweeted a bliki retread to his article about RigorousAgile today.  My favourite line is this one:

...agile methods fundamentally expect teams to decide what process to follow and furthermore expect teams to actively and regularly change their process.

I found it to be a very concise description of agile methods that hits those key points perfectly. It's all about continuously improving and I have yet to find an environment as rewarding to work in as being part of a team that has that outlook.

Teacup Programming

Teacup Programming is a variation on pair programming.

Why teacups? While sitting around a round table during a team retrospective where we had mentioned pair programming the conversation drifted a little when someone said it felt like we were sitting in a teacup ride or something.  Naturally, this led to combining the two ideas and teacup programming was born.

The idea is based on amusement park rides where the rider spins a wheel in the centre of the ride to increase the spinning velocity of the rider's individual car.  The most widely known example of this is the Teacup ride at Disneyland.


Requirements

• An even number of programmers 
• a table (round is preferred but not necessary and a rotating table is even better)
• one computer for every two programmers

Steps

1. Sit the programmers around the table with a computer in front of every other programmer.

table setup

2. Each programmer with a computer begins working with the programmer on his or her right.

pairs with person to the right

3. After a designated period of time, say 30 minutes, the pairs switch.  This is done by either rotating the table one spot to the right or having everyone move left one spot so the programmer on the right from each previous pair is now sitting in front of a computer.

rotate the table one spot

after rotation

4. Again, each programmer with a computer then begins pairing with the programmer on their right (this is a consistent rule for creating pairs) and the timer is reset for another 30 minutes.

again pair with person to the right

5. Goto 3.

The key point in this rotation system is to always have the one programmer from a previous pair remain working on the same computer and thus on the same problem to help reduce lost time due to context switching.  Also, everyone at the table gets a look at each problem which means more eyes looking at the code.  The drawback is that one programmer only ever works with two others at most.

Variant

programmers "leap-frog"

A variation to increase the number of pairing combinations is to have the person relinquishing control of a computer get up and "leap frog" positions one direction or another.  This adds more complication to the rotations but allows an individual to pair with more people in the group.

We have yet to actually try this out and so cannot say whether it is a viable technique or not but I think it does have some merit and there may even be some specific situations where it might be best applied such as at a hack-a-thon where there is a long list of problems or bugs trying to be solved none of which are too lengthy or difficult or for practicing for a programming contest where people are just trying to solve as many problems as possible.

If anyone gets around to actually attempting this please post a comment with the results.

Switching to PivotalTracker

For our SCRUM development we have used a variety of tools to plan and track our work.

Mingle
We used Mingle for a long time but found that because it is so customizable it makes it very easy to overcomplicate your project and process.  We also spent a large amount of time configuring, setting up and tweaking mingle to create the ideal project template.  Mingle is also very slow and seems to require a server with a huge amount of resources to run smoothly.

Scrum Ninja
Scrum Ninja has a lot of nice features and seems to be going in the right direction but it was very glitchy and we even lost some data at one point.  We were able to get most of it back through their support but it was definitely a hassle.  Searching didn't work very well and although the card wall view is a nice idea it can be hard to read.  The export format is relatively useless leaving out important data like dates.  It wasn't even worth trying to parse the exported text with a script to extract what we wanted.

Pivotal Tracker
Pivotal has done a very nice job with their Tracker product.  We first tried at the same time as ScrumNinja and first impressions left us feeling it was more restricted or had fewer features in some areas.  We gave it another go and now realize it has a much simpler interface that we've found frees us up to just work on the project rather than spending time setting it up in the tool.  It has several integrations with other projects and an open API for custom integrations.  We've also made suggestions and bug reports and had very quick responses and fixes.  It also uses csv as an export format.  All in all we're very happy with Tracker so far.  Plus, it's free.

Is the industry moving away from Agile?

I don't think so.

I'm writing this in response to a link to this article on slashdot that a friend sent me asking the question which I've used as the title for this post. (The slashdot article references this blog post which is a good and informative read in itself and I found I agreed with many of his points. What starts as an emotional rant turns into a very well presented article.)

There isn't just one way of doing development or just one way of doing agile; hence the name agile. I thought the first poster on slashdot hit it on the head especially with his comments about having the right people and making adaptations to your business.

The author leads into the article complaining about agile but later talks about how many other methodologies can also be successful. The important thing in my mind is picking the right approach for the job (or team even; some methodologies only work with a certain type of people) and also understanding that methodology properly. In fact, the understanding must come first to be sure that you do pick the right approach for your team/project.

The author made a good point about how some people use the words "agile" and "scrum" interchangeably. It is my opinion that these are the teams that fail at agile. It could be that some see agile as being less structured and as a result end up thinking there are fewer rules and less accountability. An agile approach may give the developers more leeway and freedom but with that comes more responsibility. My experience has shown that a junior team usually cannot succeed in these circumstances. They typically will not have the experience required to make the design and implementation decisions that are usually made by someone else in a different model. It's been a challenge to overcome with some of our teams.

We use SCRUM outwardly but also take the XP approach mentioned by Kent Beck in "Extreme Programming Explained" and implement changes slowly. We reflect each week in our sprint retrospective on how those changes helped/hindered us and we also talk about new ideas and ways to improve our process. Yes, we follow a scrum model but one that we have adapted to our needs. We also know that it is more than just doing this list of things and then we'll have it right. We know that the business needs change, the business itself changes and that we need to be able to change and adapt in order to keep pace. I feel that with the right mix of people and support from management agile can be very effective.

Although we don't do game development where I work, I had previously found this pdf about lessons learned implementing SCRUM at Bioware and one of the key things I took from that was that they also ended up adapting SCRUM to their own needs. I think this is key to success with any methodology; being able to take what works and adapt where you need to.

Are You Invested?

We use Scrum and have weekly sprints. I had someone asking me about a piece of the application that had been developed in a sprint a couple weeks prior. The developer asking the question had not worked on that piece during that previous sprint and was now working on something that involved refactoring a portion of that code. During the discussion, when asked about how certain pieces of it worked, the developer brought up the fact that the piece of code was not written by him, as if to say, "Well, that's not MY piece of code". I was more than a little surprised by this comment and not only because in Agile development there is collective code ownership but also because it shows a lack of investment in the project. These obviously go hand in hand. The more invested a developer feels in a project the greater his sense of ownership.

Even so, the concept of collective code ownership means that all team members are responsible for the code that is developed. That doesn't mean that you have to know every detail about the application or about what your team members are working on but it does mean that you should at least know what they are working on and how it impacts the rest of the application. If they are applying a new technology you should at the very least have an idea of some of the issues that can come up while doing so simply from the daily stand up meetings. The point of collective code ownership is that any member of the team can work on any piece of it. A single piece of the code is not dependant on a single developer. This is also a benefit of occasional pair programming and having other team members test your code/tasks because it allows for another pair of eyes to look at the problem even if it is done as more of an overview.

So if a developer comes across a task that requires them to work on a piece of the code that they haven't worked on before they should be doing all they can to learn what they can about this piece of code. Whether they turn around and talk to the developer who first wrote it, read through the code (which would probably be my first step) or start researching on their own by looking online, in books or other documentation, they should be invested enough that the fact that they did not write it in the first place should never even come up.

Code Slinging

I've thought for a while that I should start a development related blog where I can drop bits of development related goodness. The name Code Slinging came to me while reading the Contrasted with "cowboy coding" section in the wikipedia article on Agile Software Development. It was the first time I'd heard the term but thought it very apt and it prompted me to go ahead with creating this blog.

The interesting thing is that anyone who has ever written code would more or less have had experience with the Cowboy Coding methodology, if we can really call it a methodology since it lacks structured methods and procedures.

Like I said, it was the first time I had heard the term but as I read it's definition it all seemed very reminiscent of anything I had done on my own or even most group work while at university. The initial reaction is that it has a negative connotation (especially after having worked on an agile team for the past year and on a modified RUP team previous to that) but on further thought I can see merit in actually choosing it as a development methodology in certain circumstances. These circumstance, rare as they may be, would require a small, skilled team of individuals who trust one another and their abilities and who have near complete autonomy in the decision making process. However, I think these circumstances are so rare and the conditions for successful execution so difficult to achieve that it renders Cowboy Coding a viable option only when the decision maker is the sole developer on a project. Basically one man jobs or personal projects.

Cowboy Coding can in many cases very much resemble agile methods because they both have working software as a measure of success, they are both adaptive methods and they both require trust between developers (to be successful). However, without a focus on some integral agile principles (like specific timeblocks that are in themselves complete development cycles) it cannot be classified as such.