I've been in a lot of programming shops in my days, some fostered an agile mindset, some less so.
One feature which aids agile development is having something which gives the team visible feedback to the overall state of the project. One major real-time status item is the state of the continuous integration testing.
You are doing continuous integration testing aren't you? There are good lightweight tools and services which make this easy, I use run>run>run to test my open source projects like RiCal every time I commit to its publicly visible repository on github. Run>run>run provides free service for public open source projects, and range of paid plans to suit just about any budget.
And that's just one option, it just happens to be the one I use.
The continuous "integration" testing mindset can also be seen fractally. In between commits, something like autotest out of the ZenTest gem, or the autospec variation which is part of RSpec, can keep a continuous eye on the state of your code as you change it.
Thinking back on some of those programming shops, a couple of them had something I really liked, they had adapted real traffic lights to show build test status. Google for traffic light and you'll find that you can get them for fairly reasonable prices.
Or you could build your own. For a smaller scale version, consider this miniature traffic light built by a maker for his kids using typical maker supplies like, an Altoids tin, a cigar box, some L.E.D.s and a minimal microcontroller. When I saw this yesterday, I immediately thought how cool it would be to hook this up to a computer for C.I. feedback.
A small "confession." Until recently, I had a green-red status light for RiCal in the sidebar of this blog, using Glenn Vanderburg's runcoderun-badges but had to turn it off temporarily when someone told me that the UI for commenting to the blog was no longer working.
It turns out that the badge (which uses JQuery), was fighting with the Prototype flavored Javascript. I'm sure it wouldn't be that hard to fix using JQuery's noConflict function, I just need to find the time to try it and test it. For the time being it was more pragmatic just to remove the badge.
Of course the downside is that I once again have blogspam comments showing up for moderation, I'd been wondering where they went!
Last night there was a very interesting extra meeting of the local AgileRTP group. Johanna Rothman was in town and Jared Richardson arranged an extra meeting so that she could present some of the issues which arise in adopting agile methods, and how to deal with them. Johanna is very knowledgeable and gave an interesting and thought provoking thought.
One of the issues she talked about was "distributed" agility. This is a hot button as many companies are outsourcing some development to "offshore" locations. Johanna talked about the issues in following agile practices, and I'm vastly oversimplifying here, pointed at time zones as the major issue.
Someone in the audience, who works in a distributed team with members across the US, questioned her on this. As the discussion unfolded, other issues came up, such as dealing with a team in China which had one person fluent enough in English who acted as the "email-translator", as well as cultural differences affecting communication.
Language and cultural differences certainly can inhibit the free exchange of information which is the coin of the realm in Agile practices, but I had to observe that these are not really geographical or time zone issues. I've seen similar difficulties with co-located teams.
Distributed development using agile methods can indeed work, I've seen it. OTI was quite good at it. We did timeboxed projects with development spread across the globe. A given project might comprise team members in Ottawa, Zurich, Sydney, Raleigh, and Vancouver. Large projects might use a "team of teams" but smaller ones had individual members who were geographically dispersed. There was lots of communication by phone and email, and it worked quite well.
OTI had one "stand-up" meeting every year, usually in February in the balmy clime of Quebec, an annual Tech Conference where everyone in the company got together at a sort of internal "OOPSLA" to talk about what they were doing and to exchange interesting ideas, and just get to know each other better.
Now the main thing that made this work was that we shared a common culture when it came to development. Although not everyone at OTI was a native English speaker, all were fluent.
"Big Dave" had a tendency to hire good people wherever he found them. Often such a person would seed a new multi-person laboratory, but sometimes a "lab" would be a single person.
So distributed development can work, and work well, given the right people.
Some agility advocates stress the need for co-location, a notable exception is Kent Beck, the founder of eXtreme Programming, who now spends most of his time based a his farm in southern Oregon, and does remote pair-programming using VNC and Skype, with programmers around the world.
And Kent is currently auctioning off a two-hour pairing session this is a good opportunity to sample distributed agility at a high level.
I wish I could afford to bid, the current bid is at $200, which is cheap. I've learned a lot every time I interacted with Kent personally in the past. Someone is going to get a deal, whatever the winning bid turns out to be.
In my thirty-two year career at IBM, I can’t begin to count how many times I was bothered by
the IBM software development process.
When I started, in 1974, I found myself trying to swim under the waterfall. Everything
hinged on “Requirements Documents,” “Initial Functional Specs,” “Design Reviews,” etc.
Managers were constantly wanting line of code estimates. Far more effort was wasted on
process rather than progress. Sometimes the process overhead was fatal. My first project at
IBM was part of IBMs major initiative in the 1970s to replace the IBM/370 with a new system
called “FS”. One of my heroes at the time was John Sowa who worked in the architecture
department and whose role seemed to be the resident iconoclast. In one of his memorable
memos available on his web site,
John made the observation that the system architecture specification comprised fifteen
registered IBM confidential documents, each with an individual need to know. A fact which
effectively prevented anyone in the company from understanding the system
and its problems.
So, it should be no surprise that I came to an appreciation of what are now called
agile methods, early on in my career, and fought for the processes and technologies which
enable agility inside IBM, and evangelized such approaches to IBM customers.
Fred George was one of my allies during part of this struggle. Fred was a middle-level IBM
manager who came to the IBM lab in Cary, NC about the time we started using Smalltalk, and
I was developing a prototype application development tool which morphed into VisualAge.
I worked in Fred’s organization and claim influencing him on dynamic OO technology, and agile
methods.
Fred now works for ThoughtWorks, and blogs about agile methods. Recently he has been
writing about how to push back against bean-counting. I get the sense that Fred shared
many of my frustrations with the old IBM process.