Steven "Doc" List, Agile Novice

I Know and You Don't

slist — Wed, 13 Feb 2008 20:03:21 GMT

Today I gave a luncheon talk to a local networking group. The topic was Full Circle Electronic Marketing^tm.

While I do have some expertise in this area, what struck me was the attendees' perception of my expertise. What set us apart is that I know and they don't.

I don't mean that to sound arrogant or obnoxious. Just a statement of fact.

Is this a key aspect of "expertise" - something that I know that you don't?

How should this idea inform our work?

We build CRM software. Our customers provide expertise to their customers. Their customers expect them to have knowledge and skills that those customers need.

Should this idea inform our design and implementation decisions?

I think it should. My experience is that people are frequently unhappy about having to ask for help, about having to depend on someone else. If we can find ways to make that less so - make it pleasant, maybe even enjoyable - I believe that we will achieve ongoing success.

Endings and Beginnings

slist — Mon, 11 Feb 2008 21:55:00 GMT

From Teamwork Is an Individual Skill by Christopher Avery:

I won't pretend we can do much to avoid endings. They are as inevitable as beginnings. But I have observed that we can improve the quality of endings by avoiding three things:

Burning bridges

Harming reputations

Being inhumane to oneself and others

Reading this took me back to the first time I was an owner of a company. I had a partner, Duane Roberts, who is 12 years older than me. Our company was what would be called an outsource software developer these days, based in Silicon Valley. We had one customer who was becoming very troublesome and obnoxious.

I wanted to just cut them off and tell them what I thought of them.

Duane said "don't burn your bridges - you never know when it'll come back to bite you."

Wise man, Duane.

It's so easy to leave the intimacy of a team, relationship, environment and figure you're just done. "Ah, hell, I'm gone - I don't have to worry about being nice anymore!"

Not so. You never know when someone you used to work with will be in a position to make a difference in your life or career.

The golden rule: treat others as you would like to be treated (my phrasing).

The platinum rule: treat others as they would like to be treated (also my phrasing).

I don't know of any rules that say "treat others like crap."

Looking for an Agile Architect

slist — Wed, 06 Feb 2008 20:49:00 GMT

Job posting is below. Here are some of our references for this position:

http://www.agilearchitect.org/agile/index.asp

http://www.agiledata.org/essays/enterpriseArchitecture.html

Agile Application Architect

Are you experienced with enterprise applications, tiered architecture, agile development, and Ruby on Rails?

Do you communicate well, work well in a team, and get satisfaction from both architecture AND hands-on development?

Are you able to translate business requirements and product vision into application architecture?

If so, maybe you are just the person we’re looking for at Dovetail Software.

Send us a cover note telling us why you’re the person we need, and include your resume.

Agile Software Development

Dovetail software is a leading company in Customer Support & Service and Case Management systems

As an architect at Dovetail Software you will be expected to:

Define Customization, Extensibility and Integration API's.
Talk to the business to understand business and technical requirements.
Translate business requirements and product vision into application architecture.
Communicate technical constraints and decisions to the business.
Define technical infrastructure.
Contribute as a hands-on developer.
Be able to clearly convey technical ideas to the development team.

Work for one of the most progressive development shops in the US, building a new software product line with pioneering technologies.

Experience in the following is a must:

Application Architecture using enterprise technologies
Test-driven development
Domain-driven design
Ruby on Rails
Familiar with multiple programming paradigms

Experience in the following tools and technologies is a plus:

Continuous integration
Watir
HTML, CSS, JavaScript
CruiseControl.rb
Subversion
Mingle
Capistrano / deployment tools

Who we’re looking for || Dovetail Software is enhancing our team for an innovative software project. We’re looking for someone with a deep understanding of software architecture and design to work in our agile development lab in Austin, TX. We take these truths to be self-evident:

You are already versed in patterns
You write tests
You believe that learning is a primary responsibility
You understand that code is for communicating with other people rather than a compiler
You understand that an application architect holds the vision of the product, jointly with the product manager and the business
You are driven to translate the product vision into a product that exceeds all expectations

We’re hiring motivated people for a terrific opportunity with a team of recognized agile community leaders.

Our development methodology || We are a Scrum/XP shop. We work in one-week iterations and hold daily stand-ups. We have a collaborative relationship with our customers and a full-time, in-team product manager. We write tests before we write functional code to clarify our design intentions. We keep the build clean. We work in an environment that maximizes communication to minimize the volume of spec documents. We build software that can effectively respond to change. We use open source tools where appropriate, and proprietary tools where they make sense. We have executive support and visibility throughout the company.

Email us and tell us why you’d make a great addition to our team: tech-jobs@dovetailsoftware.com

Lots of Events Coming Up

slist — Tue, 05 Feb 2008 16:45:50 GMT

Having entered the Agile community last summer, it seems I have both embraced and been embraced by that community, and some extensions of it. Here's what's coming up:

APLN Leadership Summit, Dallas, TX, February 21-22

I'll be on a lunch panel talking about "What Keeps You Awake At Night". Apparently my blogging convinced someone that I'd be interesting on a panel. Go figure.

Learn more.

Microsoft Global MVP Summit, Seattle, WA, April 14-17

No, I'm not a Microsoft MVP. But I've been invited to facilitate one of the tracks as an Open Space, based on my work at the first Alt.NET conference here in Austin, TX.

Learn more.

ALT.NET Conference, Seattle, WA, April 18-20

Following the Microsoft Global MVP Summit, the ALT.NET community is holding another conference. They, too, have invited me to facilitate their Open Space.

Learn more.

Agile2008, Toronto, Canada, August 4-8

This one's not a done deal (yet), but Ken Judy and I have proposed a session on ethics in agile practice. I'll let Ken tell you all about it.

What's In It For Them?

slist — Mon, 04 Feb 2008 20:01:25 GMT

As I'm reading (and sometimes re-reading) Christopher Avery's wonderful book Teamwork Is An Individual Skill, my thinking gets stimulated. I really like Avery's perspective on things that relate to teamwork, team building, and our personal responsibility.

Here's a great excerpt:

Examine the logic contained in the following five statements:

Everyone alive has hopes, dreams, and wants for themselves.

People who have no hopes, dreams, or wants are dead.

When people get out of bed and go to work, they have linked what they are going to do that day to their hopes, dreams, and wants in a way that makes sense to them. Or they wouldn't get up, would they?

Therefore, all of us have our own excellent reasons for investing in work projects--even if we have learned to deny or hide those reasons, sometimes even from ourselves.

The best way for me to serve fellow workers is to help them uncover and focus on their own motivations--even if they attempt to convince me they have none.

If you agree with this logic, you can stop trying to dictate other people's motivation today. The next time you need to motivate someone, try asking, "What's in it for you to work on this project with this team?" and keep the other person in conversation until he comes up with the personal benefits that motivate him.

Isn't that simple and lovely, yet exceptional. Ask the other person for their motivations. How well that ties into the concepts of teamwork.

Working Through the Railscasts - #17 - HABTM Checkboxes

slist — Mon, 31 Dec 2007 21:10:00 GMT

This one is just cool! I knew that there had to be simple and elegant ways of working with checkboxes on forms, but had no idea how to do it.

One of the great values of watching all the Railscasts is that I'm gaining a greater understanding of what we can do with this technology / framework. Rather than saying "Gee, it'd be nice if...", I'll be able to say "Y'know, I saw in Railscast that we can..."

This may annoy my developers, but it'll make me quite happy.

Anyway, back to this 'cast, I now understand that I can easily use the has_and_belongs_to_many association to drive some fairly simple code to present checkboxes and use those checkboxes to persist many-to-many relationships.

Most cool.

Working Through the Railscasts - #14 - Performing Calculations on Models

slist — Mon, 31 Dec 2007 17:58:00 GMT

It continues to amaze me how much stuff the Rails team has built into Rails.

In this case, it's being able to perform calculations on collections of model objects. While you can do that in any language, it usually requires a block of code.

In this Railscast, Ryan shows us how you can do it with a single method, like

        1: Tasks.sum
  

The implications are wonderful. Now I just need to look up the list of all of them - yet another opportunity to read the Rdocs! (Yes, really - I like it)

Working Through the Railscasts - #2 - Dynamic find_by Methods

slist — Mon, 31 Dec 2007 17:18:00 GMT

Continuing with the Railscasts, I found a good lesson through the example of Railscast #2, Dynamic find_by Methods.

The specific technical content was nothing new to me - the idea that there are many variations on the find_by method, and that there are some fun and effective ways to use them. If, however, you haven't gotten your head around this feature of Rails, do so now!

What happened, though, was that I decided to look at how we are using various find_by methods in our code. I came upon a controller method that included exactly two statements, like this:

        1: a = A.find(params[:id])

       2: b = B.find params[:id]

Of course, I already knew that in most cases, parentheses around method arguments are optional. As an older programmer (wheeze, cough), I like parentheses - they neatly encapsulate the arguments and make for clear reading, to me. However, I accept that there's a different kind of readability that comes with a language that doesn't require them.

Rails had, before 2.0, been seemingly somewhat inconsistent about when it did and did not require parentheses. At least, it seemed inconsistent to me.

Regardless of that, my problem was in seeing two lines of code, one directly below the other, that did the same thing on two different models with two different coding approaches.

Given that not only our development team, but our customers, will be reading this code, a certain consistency seems to me to be of value.

So while I didn't learn anything new about find_by methods from this Railscast, I did have an opportunity to add something to our discussion of our programming style.

Working Through RailsCasts - Picking Tasty Tidbits

slist — Mon, 31 Dec 2007 17:03:00 GMT

I'm slowly working my way through all of the Railscasts, with the goal of being able to understand more of what the team is up to, and maybe suggest some changes.

Thanks to a suggestion by my friend Luke Melia, I'm going to identify my favorite tips and tidbits, and share my thoughts about why they're my favorites. This forces me to tread carefully the line between "I'm a techie/programmer" and "I'm a manager of an agile team". Hopefully, I'll manage okay.

I'm delighted to say that my first favorite tidbit comes from the first Railscast from March, 2007 titled "Caching with Instance Variables". I should mention that the Railscasts are the work of Ryan Bates, who is a Rails Core Contributor, among other claims to fame.

In the first Railscast, Ryan suggests that it's more efficient to cache user information in the Application Controller rather than pulling it out of the database every time you need it.

This rang a bell for me, since we have a nifty current_user helper that is pulling the user info from the database every time it's invoked. While usage is not a big deal right now, while we're in development, it could become so later on. And while we may eliminate this helper later on, why not use good practices now?

There was an additional lesson in this for me - that the Application is instantiated for each session, so storing the user in a cached instance variable makes sense. It may seem obvious, but I hadn't really thought about it before, and since we hadn't used any instance variables in the Application controller, I had no examples to lead me to ask the question.

I checked in with my team, and asked if there was any reason we shouldn't use this technique. The answer? Try it and run the tests and if it passes, then it's okay. I did, they did, and it is.

Thanks, Ryan!

How does an office move affect the team?

slist — Tue, 04 Dec 2007 15:33:00 GMT

We moved our office last week. In spite of everyone's best intentions, it was hard NOT to have the planning and preparation for the move affect the team.

Velocity is down.

People were distracted.

Then we get into the new office, and the space had to be arranged to suit the team, furniture reconfigured, equipment hooked up, and so on.

Some folks fell right back into their work patterns, just in a different location. Others took more time to get everything arranged, help out with moving stuff around, and generally get ready to get back to work.

I'm wondering how much of this is in any way specifically relevant to agileness.