Agile2010, AgileAustralia2010, AgileCertification, AgileHandover, AgileImposition, AgileManifestoMeeting, AgileVersusLean, AlphaGeek, AssertionFreeTesting, BigScreen, Buildix, C3, CannotMeasureProductivity, CodeAsDocumentation, CodeOwnership, ConversationalStories, CustomerAffinity, DatabaseAndBuildTime, DecreedStories, EarlyPain, EstimatedInterest, EvolutionarySOA, FaultyTechniqueDichotomy, FeatureDevotion, FivePoundBag, FixedPrice, FixedScopeMirage, FlaccidScrum, FunctionalStaffOrganization, HistoryOfIterativeDevelopment, ImprovementRavine, IncrementalMigration, IsAgileForAll, LargeAgileProjects, MeasuringProductivity, MetaphoricQuestioning, ObjectsAndIteration, ObservedRequirement, OnsiteCustomer, OpenSpace, PairProgrammingMisconceptions, PendingHead, PeopleOriented, PleasingTheCustomer, PreferDesignSkills, PreferFunctionalStaffOrganization, PrinciplesOfXP, RigorousAgile, RollerSkateImplementation, SchoolsOfSoftwareDevelopment, ScopeLimbering, Semat, ShiftingToCodeOwnership, ShuHaRi, SpecificationByExample, SpreadingIncrementalism, StandardStoryPoints, StickyTimeline, Swebok, TeamRoom, TechnicalStaffOrganization, TestingLanguage, ThrownEstimate, ToyotaFailings, UPod, UtilityVsStrategicDichotomy, VeryLowDefectProject, WhatIsFailure, XpVelocity, YesterdaysWeather
||27 September 2010
Scattered impressions from my recent trip to Australia for the Agile Australia conference.
||16 August 2010
Last week I attended the Agile 2010 conference in Orlando. Agile
20xx is the major US agile-oriented conference whose roots go back
to XP Universe and the Agile Development Conference. I've not been a
regular attender of the main agile conferences, but I did go last
year as well. Rather than make an attempt at a consolidated description, here
are a few scattered impressions.
Elizabeth Hendrickson (aka testobsessed)
- Attendance was 1400, more than 2009, but around the same as
2008. So although it has been hit by the Great Recession it's
weathered it reasonably well.
- I was delighted to see Elizabeth Hendrickson and Liz Keogh win
the Gordon Pask award.
- My sense was that most people were relatively new to agile,
which is in line with my sense in 2009.
- There was a much higher proportion of women than I usually see
at software conferences.
- There were lots of talks going on, which felt overwhelming to
me: 16 stages (tracks) with 214 talks.
- I was pleased to see the tutorial on Continuous Delivery
that Jez Humble gave with me seemed well-received. (We currently have it booked again for QCon
- Most of the emphasis was on team collaboration and soft
skills. This led to some criticism from people on the programming side.
- My unscientific sample of talks I attended showed a higher
proportion of badly presented talks than I would like.
- It seems there's a movement to re-create XP Universe for next year.
- I prefer a conference in a real city to one in a holiday
- This year marks ten years from the first agile-oriented conference.
- The conference went smoothly - which is a testament to the hard
work of all the organizers. This is particularly so since they had
to deal with moving the conference after the flooding in
Nashville. Thank You.
Liz Keogh (aka lunivore)
I have mixed feelings about the complaints on the lack of
programming topics. Certainly programming plays a central role in
software development and attempts to marginalize it correlate well
with dead-ends. But programming is part of a very interconnected
system which involves lots of pieces - and making these
interconnections work requires exactly these kinds of "soft and
woolly" skills. There is a real tendency for programmers to look
inward and obsess on technical issues rather than engaging with
those outside programming. One of the things I like about XP is
that it recognizes this: blending technical excellence with
I would hate to see programming detached from the agilexx
conference with programmers going to different events. There's a
need for places where the intermingling can occur. The JAOO and QCon conferences seem to do a very
good job of this - as well as having a better quality control over
the talks themselves. Their format isn't universal, and there's room
for more options. Our crucial task is to engage in excellence in the
programming side without cutting off the essential
||29 July 2010
One of the steady themes I've seen throughout my career is that
of the nature and importance of software development. Recently a
prospect told one of our salespeople that "software is like sewage
pipes, I want it to work reliably and I don't want to know about the
details". This is the kind of approach that Nicholas Carr talked
about in IT Doesn't
On a contrasting note we've done work for many businesses where IT
has been a clearer strategic enabler to their business, allowing
them to enter new markets or significantly increase their market
share. So is IT a utility, like sewage pipes, or a strategic
I take that the view is that it can be either, depending on the
system. A classic example of a utility IT project is payroll,
everyone needs it, but it's something that most people want to 'just
So what is the distinguishing factor between utility and
strategic projects? To my mind it's all about whether the underlying
business function is a differentiator or not. If how you do this
function is a crucial part of what makes you better than the
competition, then the software that supports this function needs to
be as good as you can make it. Note that this distinction isn't
about the software, but the business function. As Ross Pettit puts
it "This is not a separation of IT by the nature of the
technology, but into what technology does for the host
The most important point about this dichotomy is to realize that
there are two kinds of software projects and they need to be treated
entirely differently. The way you staff, run, and budget a
strategic project is entirely different to how you do a utility
project. Too often people assume that what is good for one is good
for the other - and trouble inevitably follows.
Another consequence is that only a few projects are
strategic. The 80/20 rule applies, except it may be more like
95/5. While certainly it's most common for people to not recognize
the dichotomy at all, it's also common for people to think that too
many projects are strategic.
One of the most important ways in which these efforts differ is
where the risks lie. For utility projects the biggest risk is some
kind of catastrophic error - you don't want the sewage pipe to
break, or to miss payroll. So you need enough attention to make sure
that doesn't happen, but other than that you want costs to be as low
as possible. However with strategic projects, the biggest risk is
not doing something before your competitors do. So you need to be
able to react quickly. Cost is much less of an issue because the
opportunity cost of not doing something is far greater than costs of
software development itself.
This is not a static dichotomy. Business
activities that are strategic can become a utility as time
passes. Less often, a utility can become strategic if a company
figures out how to make that activity a differentiator. (Apple did
something like this with the design of personal computers.)
One way this dichotomy helps is in deciding between building
custom software and installing a package. Since the definition of
utility is that there's no differentiator, the obvious thing is to
go with the package. For a strategic function you don't want the
same software as your competitors because that would cripple your
ability to differentiate.
Often people realize this and buy a package for a utility
project, but then spend huge amounts of money customizing this -
which is just as wasteful. My view is that for a utility function
you buy the package and adjust your business process to match the
software. Usually this is politically infeasible, so the workaround
is to put a low grade software team to work on it. Provide enough
care to avoid catastrophe, but otherwise you don't need a high-grade
Another way the dichotomy makes its influence felt is the role of
agile methods. Most agilists tend to come from a strategic mindset,
and the flexibility and rapid time-to-market that characterizes
agile is crucial for strategic projects. For utility projects,
however, the advantages of agile don't matter that much. I'm not
sure whether using an agile approach for a utility project would be
the wrong choice, but I am sure that it doesn't matter that much.
Like many classifications, there's a lot of grey in between. Yet
this is one of those rare cases where I think there's a strong
argument to turn up the contrast and force more binary thinking. As
Ross commented in a discussion of a draft of this post: "'shades of
grey' give license to pile things into the wrong category; things
that are really utility will be given an inflated importance, rather
than dispositioned as the utilities they really are." Forcing a
binary decision, tilted to minimize what's in the strategic bucket,
would help provide the focus that's often lacking in IT initiatives.
Ross goes so far as to argue that there
shouldn't be a single IT department that's responsible for both
utility and strategic work. The mindset and management attitudes
that are needed for the two are just too different. It's like
expecting the same people who design warehouses to design an arts
To explore more...
||14 June 2010
A common thing you find in agile projects is that the development
team sits in a single open team room. It was advocated early on in
Extreme Programming and called out as one of primary practices in
the second edition. Agilists favor a open team room as it promotes
lots of informal and deep communication between people on the
Software development is an intense exercise in
collaboration. An open space encourages regular conversations and
interactions between people. You can see what everyone's doing and
easily ask for help when you need to. Often you get serendipitous
communication, where you overhear something that's really useful.
Hearing this, some people are concerned about noise, and would
prefer private offices. In practice I find that teams don't find
noise to be a serious issue. There's usually a hum of conversation
going on, after all pair programming often accompanies this style
of development. But the conversation isn't usually that
distracting, particularly as you're focused on the conversation with
your pair. I suspect the reason it's not that distracting is
because the team has a common purpose around a collaborative
activity. It isn't comparable to an open-plan office where
everyone is doing something different.
Tips for a good Team Room
First make sure it is the right size for the team. While a team
room should be open within itself, it should be closed to everyone
else. In an ideal world you'd like flexible walls that can
insulate one team from another, so an office consists of pods of
teams. This is hard to do in practice. Our offices tend to be
completely open, with little barriers between teams. This seems to
work well-enough, although there are some complaints about the
Pay attention to natural light. Humans are used to seeing the
outside world, and all sorts of natural rhythms work off of
light. So it's no surprise that people get very cranky if there
isn't enough light about. I've spent plenty of days in enclosed
conference rooms, and it certainly wears down my energy.
Provide enough space: about 50 square feet per person (4.5
square meters for those on metric).
With the right kind of space the next key thing is to ensure
that the team has control over that space. An important part of
agile thinking is that the team is responsible for how it works,
and how it organizes its space is part of that. Ideally you want a
team to have complete control over their space, with freedom to
configure it how they like and reconfigure it at will. Things
should be done so it's easy to move things around, because during
the project the team will need to change things as the project
The purpose-built tables in our Beijing office have
handy baskets for power and other cables.
An immediate consequence of this is to ditch any kind of
modular furniture that requires a facilities group to move more than
an inch. Most teams I see use simple tables, and you can certainly
go cheap here.
The biggest hassle is wires - primarily for power and network
access. Ideally you want these underfloor or overhead so that
people can easily route wires to the tables, wherever the tables
happen to be.
The place to spend money on furniture is for good quality
chairs. Programmers spend a lot of time sitting, and any physical
damage due to poor posture will have a direct effect on the team's
productivity - so don't stint here. It may be that some people
will want strange chairs, such as balls or kneeling chairs. Do
your best to accommodate them.
Some people are big fans of tables that can be adjusted between
a sitting and standing height, as they find that standing for a
while helps with back pain. These are harder to find, but worth
looking into if your team members need it. Back pain is a common
issue, but everyone's pain (and treatment) is different.
You'll need lots of wall space, as agilists love their information
radiators. You want plenty of room for story walls,
architectural diagrams, whatever people want to stick on the
wall. A good bit of this wall space should be whiteboards so
people can draw something whenever the mood takes them. Include
some wheeled whiteboards. Make sure there's a digital camera
around so people can easily record what's on the board. Now that
displays are so cheap, consider getting some just for wall
displays - this is particularly handy for dynamic displays such as
build status. I've seen one team have projectors trained on a wall
with various kinds of information displays.
The traditional layout is to have people working around clumps
of desks. This gives you regular eye contact with the rest of your
team. However I've heard many people sing the praises of the
People will occasionally need some private space, so ensure
there are one or two small conference rooms available, with
telephones. These can be used for privacy or when there's a
concern about distraction. A large meeting room that the team can
gather in for meetings away from the working space is also
I've always been a big proponent of lots of monitor
space. Clever software with multiple virtual workspaces is a great
feature, but nothing is faster than just moving your eyes. Every
workstation should have a couple of 20 inch monitors as a bare
minimum. My desk has a pair of 20 inch monitors for my Ubuntu
machine and a 25 inch for my mac laptop. I don't think that's at
Software development is inherently creative, so expect to see
lots of baubly distractions. Toys are commonly found around our
teams (as Neal Ford says: "every team needs a plastic
kangaroo"). There are good cognitive reasons why this is valuable,
it's all about keeping the brain stimulated and creative.
Similarly do provide easy access to snacks and drinks. This
helps support informal, conversational breaks in the team
area. It's hard to be creative when you have to pay for awful
If you're working with remote workers, make it easy to set up a
video link. Indeed many teams like having permanent video links to
any remote workers so you can always maintain that casual video
My thanks to my ThoughtWorks colleagues for helping compile
Translations: | Portuguese |
||16 April 2010
SEMAT (Software Engineering Method and Theory) is
an effort initiated by Ivar Jacobson, Bertrand Meyer, and Richard
Soley. Its stated aim is to "refound software engineering based on a
solid theory, proven principles and best practices". Like many
notorious people in the software world I was invited to
participate. Thus far I've declined and feel the need to explain why.
The call for action seemed
somewhat vague to me. Although it derided fads and fashions, it
seemed very much like a fashion statement itself. To better
understand what was going on I took a further look at some of the
initial publications in Dr Dobb's Journal. From here I got the
distinct impression that the central thrust of the initiative is to
create a software meta-method-kernel - essentially a set of common
process elements for software developments that you can rigorously
compose into a method for your own project.
At this point I lost interest. I spent a fair bit of time in the
80's and 90's mucking around with this idea. In the end I decided
that it was too hard and of limited value. Why this is so was
primarily crystallized for me by Alistair Cockburn who explained
that since people are the central element in software development,
and people are inherently non-linear and unpredictable - such an
effort is fundamentally doomed. Or at least it is until people
become predictable agents that can be described with tractable
mathematics - for which event I'm not holding my breath.
My views have since gone along the lines that software process is
a much more multi-faceted thing than what a meta-method-kernel would
usefully describe. Alistair's work on describing methods strikes me
as a much more realistic approach.
Alistair actually did get involved in SEMAT and attended their
inaugural meeting. His decision to withdraw further
reinforces my lack of interest to participate myself.
||2 March 2010
One of the arguments used to support the adoption of lean
techniques in software is the success of Toyota. So do Toyota's recent quality
failings undermine the case for lean software
One answer for this is to take a sense of proportion. Lean
manufacturing techniques were the underpinning of Toyota's rise from
an insignificant company in the 1950's to a global giant in the
2000's. By the 1990's other car companies, and many other
manufacturers, were busily copying Toyota's techniques. The general
sense is that copying these techniques did much to raise the overall
quality of cars in the last decade or so. I would be very surprised if
the recent problems at Toyota are enough negate that half-century of
But a better answer is to remember that Lean manufacturing is about
manufacturing not software. The application of lean ideas to software
development is a consequence of MetaphoricQuestioning. Lean
ideas can help us come up with better ideas for software development,
and as such are valuable. But in the end their usefulness lies with
how they are used in software and they should be judged on their
record here. Their history in manufacturing, both
good and bad, is another industry.