Jon Archer is a software professional with over 15 years experience who is lucky enough to work out of his mountain retreat high above Denver in the Colorado Rockies. He has worked as a software engineer with various technologies during the course of his career as well as a couple of diversions managing teams. These days he is the scrum master for a challengingly distributed team with members in Massachusetts, Colorado and Hyderabad India. He is a passionate believer in agile principles and is a key advocate thereof for his current employer Perceptive Informatics. He blogs at http://www.jonarcher.com/ and tweets as @9200feet Jon is a DZone MVB and is not an employee of DZone and has posted 19 posts at DZone. View Full User Profile
This is a slightly longer than usual, rambling somewhat whimsical post.
Sorry about that. There is some good stuff toward the end though. Well I
think so anyway.
Last Thursday I attended the inaugural Mile High Agile conference put on by Agile Denver.
The day commenced at an unnaturally early hour with me hurtling down
the mountain to Golden and then doing battle with I-70 and I-25. Perhaps
due to the early travel time the traffic was lighter than the nightmare
I had envisaged and well worth it compared to my regular commute (from
bedroom to basement via kitchen) for what I got out of the day.
What follows are my thoughts on what I got out of the conference, not all of them directly related to agile.
Earlier in the year when I first heard about Mile High Agile I
volunteered to help with a couple of items – setting up the website
along with another volunteer and the corresponding registration and
payment system. It’d been a while since I’d done any kind of web content
creation but we elected to make things really simple by just using WordPress
with a suitable theme. Although this obviously meant there were quite a
number of restrictions (especially since we weren’t hosting the
WordPress blog ourselves) it did mean we could get going easily and
quickly. Given the chance to do it again I’d almost certainly stick with
WordPress considering the simplicity of our needs, but hosting it
ourselves would be well worthwhile. That would likely let us get around
the problems we faced by using plug-ins which you cannot do when hosting
For the registration and payment side of things we used EventBrite.
This was a service I hadn’t used before (at least not in the role of a
conference organizer) and I have to say it’s a pretty impressive
offering. While our needs were simple (a handful of ticket types, a few
dozen discount codes, simple reporting and so on) EventBrite just seemed
to work without effort. Everything we ever wanted to do (bar one thing)
seemed to have already been anticipated and worked well. In addition, I
had occasion to use their support services twice which are very good
and incredibly quick to respond.
In the couple months leading up to the conference last week I really
enjoyed working with the folks that brought this together. My
contribution was pretty small compared to others, but it was fun to be
part of it and work with people really intent (passionate is so
overused, no?) on making this happen. It was a real joy to see folks
pitching in no matter their role offering useful ideas and commentary as
things unfolded. I wish I could work with more people like that more
At the beginning it was unclear how many sponsors we would secure or how
many tickets we could hope to sell. Due to a truly outstanding effort
on the part of several people we exceeded all expectations. Just check the number of sponsor logos
up on the site and note that we sold nearly 500 tickets. Not bad for
such an incredibly tight timeframe and the first ever Mile High Agile
conference! If you build it they will come. So long as you get the word out and market it hard too.
There were a few things that struck after the day of the conference
which were nothing to do with agile but interesting insights to me. I’ve
been working from home for quite some time. Although I thought I had
quite a rich interaction with people on my team via phone, email and IM
etc. it was nice to suddenly be in the fray of lots of tech people and
talking with them. I was part of the gang that stood behind the
registration desk which was insanely busy for an hour or so as the best
part of 500 people arrived to check in. It reminded me of a part-time
job I had way back in time as a teenager, working in a home computer
store on Saturdays which were always insanely busy. I loved it.
Definitely makes me hanker for more local, in-person interaction.
Another thing that was weird was that driving into Denver didn’t seem
too bad. I’ve always found it less than desirable in the past, but after
a series of trips into the city over the last year perhaps I’ve finally
got a decent sense of how its all connected up in my head and feel more
at ease with it. For some reason I’m feeling the urge to visit Denver
more and more.
The final odd little insight was how nice it was to be surrounded by
people who were enthusiastic about various facets of agile software
development. Although you might have different views and experiences
from others on details, there was this common thread of “getting it”
(“it” being agile) and wanting to “get it more.” Perhaps meeting people
whose viewpoint reinforces many of your own beliefs is nothing but an
ego stroke, but it made me think how cool it would be to work with more
people like that.
Turning to the sessions I was able to attend three, all of which were in
the technical track. I really enjoyed them. I wish there was more –
it’d be great if next year were a multi-day conference :-) It also made
me think it would have been nice to present. I’m not entirely certain
what on, but I feel like I’ve learned a lot over the last couple of
years and it’d be fun to share some of that beyond just writing about it
on my blog. Maybe next year.
The first session I attended was Agile the Pivotal Way given by Mike Gehard of Pivotal Labs. I confess I hadn’t really realized that Pivotal Labs did anything other than make Pivotal Tracker.
Turns out that really their business is building software for people,
often startups, and they seem to really approach work in a way that
makes a lot of sense to me.
Mike mentioned that they pair program everything. This reminded me how
much I miss pair programming. I’ve had two serious periods of pairing in
the past and I’m pretty sure it’s the best approach for a lot of
software development work. The first time we didn’t call it pair
programming because it was just my 12 year old self and my friend
hacking away on a Commodore Vic 20 writing games in BASIC, PEEKing and POKEing
the screen to make games that rivaled Pac Man. Almost. But it was
great. The other time was much more recent. It’s how I learned Java
courtesy of a colleague pairing extensively with me. It’s also how the
first release of one third of our product suite got built incredibly
quickly, by just me and that other guy. If I’m going to be programming
in the future I hope it’s pair programming.
Mike also mentioned how their “teams” were small, and unless their
clients insisted there were no independent QA or tester roles and no
PMs. They (the pairs of developers) did this stuff themselves. Thinking
back again, the best software I’ve ever written was when I was
completely immersed with clients and talking to them directly and I had
to make sure it worked as it should. No middle man (or woman)
interpreting customer needs and nobody else to leave finding bugs to,
and since I don’t like my things to fail I sure as heck tested the heck
out of my work.
All in all, I wish I knew a lot more about Ruby and Rails because they
sound like a totally cool place to work. I’m not sure if Mike’s talk was
meant to be a stealth recruitment exercise, but it could certainly work
The second presentation I attended was from Chris Powers of Obtiva. He was talking about test driving front end code,
years since I’ve dabbled with JS and probably don’t have any dabbling in
the near future, but it was still interesting and credit is definitely
deserved for live demo and coding activities. The tool Chris showed was Jasmine,
and while I have nothing else to compare it to it seemed pretty neat,
and I definitely liked the BDD-esque feel and the ability to express
both feature and unit tests. If I were to be doing any JS in the future I
think I’d be checking it out.
The third and final session I attended was given by Paul Rayner and was entitled Strategic Design using DDD. There was some though provoking stuff in this. First of all there was the Purpose Alignment Model by Niel Nickolaisen. It’s a simple idea whereby you can map out work onto a graph with four quadrants like so:
Of particular interest here is the notion that those things which fall
into the top right quadrant are the ones you want to put your best
effort into – you want to get the best people working on this and you
want to really pay attention to the design of this stuff. By contrast,
those items that fall into the lower left quadrant do not merit that
kind of effort.
If I understood Paul correctly, he was advocating the use of the above
to think through just how much effort you put into the design of various
components of a system. That seems like a good idea. But what also
struck about this from an agile and scrum perspective was how such a
simple thing could be used to facilitate feature prioritization in
product development. Now I’ve seen before the idea of having the stories
(or themes or features or what have you) up on post its on a white
board, and allowing people to move them around placing those the see as
highest priority at one end and lowest priority at the other. But this
would overlay a slightly more rigorous evaluation of things. If, when
using the open whiteboard technique, someone places an item over on the
high priority side I am not immediately sure why. If the whiteboard was
divided into four quadrants like the above I would immediately see if
they thought it was mission critical, a market differentiator or both. I
think that could be powerful.
The second thing I got out of this session (actually a little afterwards, after Paul had blogged on the topic)
was that the popular idea of “emergent design” is great if you can do
it well. But how many teams really have the design and refactoring
skills to pull this off? How many can spot good and bad directions to
emerge to. Having a framework to first identify what components of a
system merit more well-crafted design than others along with a set of
good design skills to apply would indeed help I think.
The third thing Paul talked about which stuck in my mind was his
"billboard test." The idea here is that if you take something you're
working hard on and imagine it up on a billboard is it really the
message you want conveyed? Consider his example: "Our logging framework
kicks butt!" Frankly, unless your company actually sells logging
frameworks realizing that you're putting this much effort into logging
ought to give you pause for thought. Like say for example "Our test
automation framework kicks butt." Or whatever. (Inside joke)
And that’s it. The trip home was quicker than I thought it would be too.
Was very ready for the highway to have turned into parking lot but
things zipped along nicely.
Published at DZone with permission of Jon Archer, author and DZone MVB. (source)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)