Robby on Rails

Earlier this week, we published Episode 3 of the Planet Argon Podcast. In this latest episode we responded to one of the ideas someone in the audience asked on this brainstormr, which was, “How do you manage bugs?”

We had a round table discussion about how we classify and prioritize bugs with our clients, ticketing systems, and other tools that we use to streamline this process.

You can listen to this on iTunes or online.

We’re not looking for rock stars or ninjas at Planet Argon. ;-)

We’re looking for individuals that share our core values.

• COLLABORATION – We believe that an open dialogue between all members of a group helps to produce more reasoned and intelligent decisions.
• ENTHUSIASM – We recognize the unique power of people who are passionate about their craft. We believe that fun is an essential ingredient in a collaborative and vibrant company culture. We think happy people make better software.
• COMMUNITY – We are part of many communities. Our neighborhoods, our cities, our workplace, and our professional communities. We give back to our communities by implementing socially responsible business practices and sharing our knowledge and tools with our peers.
• VERSATILITY – We believe that it is important for our team to be open and flexible, as well as the work that we do. This allows us to adapt to change and encourage innovation.
• EXECUTION – We value action and when people make things happen. It is important that we follow through on our commitments, plans, and ideas.

..maybe you’re a .NET/Java/PHP/Python developer (who secretly plays with Ruby on Rails at night/weekends). We’re looking for an intermediate-level Rails developer to join our team. Ideal candidates would be in the Portland, Oregon area or willing to relocate.

If you’re interested, take a moment and introduce yourself.

Amy Hoy, of slash7 fame, gave a talk titled, Rubber, Meet Road: Getting Designers Running with Rails, which provided a good overview of some of the problems that designers and developers face when working together. This was one of my favorite talks, because she essentially explained several of the problems that our team has faced in the past and in many ways, still encounter from time to time. A few things that I was surprised to hear, was that several companies leave their developers to implement HTML/CSS in the Rails applications, rather than let their designers into the area. Some teams, provide a directory in public/ for their designers to write their HTML/CSS. Amy said that she preferred to work in the standard view directories (as a designer), which is exactly how our team works.

In fact, I agreed with Amy on several points.

• Developers say, “We can’t do that” too often, when really… we mean, “We won’t/don’t want to) do that”
• Template languages create extra barriers to training designers. Stick with RHTML… designers won’t be afraid of ERb syntax if you sit down with them and explain some of it. Move the ugly stuff to helpers… like you should be anyways!
• Teach your designers how to use subversion… let them break it first and then help them… they’ll love you for it
• When meeting clients with a designer and a developer… don’t let the developer speak too much about implementation when it hasn’t been designed yet. Interaction Design should dictate architecture not vice-versa.

“Stop, Collaborate, and Listen”—Vanilla Ice

I’d like to personally thank Amy for being a diplomatic designer and telling the hundreds of developers that showed up for her talk to remember that designers and developers… think differently… and that’s a good thing for the application and ultimately… the user experience.

Having said that, I’d like to request that tomorrow, May 23rd, be… Hug Your Designer Day.

A few weeks ago, I was explaining some of the concepts behind Dialogue-Driven Development to Michael Buffington and when I said that we were working to create patterns of Dialogue... his immediate thoughts were on code. I don’t remember the exactly how he worded it.. but he basically thought we were working on a parsing tool for grabbing requirements out of emails, messages, etc. I quickly explained that d3 had nothing to do with actual code and was merely a practice that we as developers and consultants are using to think about our interaction with clients, users, and amongst ourselves.

Just last night, I was chatting with a friend of mine about d3… (names changed to protect the guilty)

context: Harry works in a development team¹ of about ten people and Paul is one of his “team”mates.

  Harry: i guess it prevents discussion domination
   me: yeah, that happens as it is sometimes
  Harry: and ensures equal contribution
  Harry: paul does that 
    and he's not very polite about it either
    and will often raise his voice and speak over you
    which is crazy
    kindergarten stuff
  me: hah
  Harry: need a talking stick!

This happens all too often amongst ourselves. While we’re striving to improve our client interaction… we often overlook our own internal struggles to achieve healthy collaboration. It takes discipline by every individual in a collaborative environment to really think together.

So, how does d3 address this? Well, it’s our goal that through mindful dialogue, we can cultivate healthier collaboration in all of our professional (and personal) relationships.

I would also like to point out a few common misconceptions about d3.

• d3 is not a methodology… nor a replacement for Scrum or XP. d3 is a thoughtful practice that focuses on the collaboration between a group of individuals, whether they be clients, developers, managers, or users.
• d3 is not a Silver Bullet, but it can be used as effective ammunition.
• d3 is not something you learn in a weekend, but you might be able to find a good book on Dialogue and have a new perspective on how you communicate with others.

Dialogue-Driven Development is about being in the conversation as it is happening… and really listening.

The next time that you’re getting ready to interact with your teammates, ask yourself:

• Am I contributing something meaningful?
• Am I listening to others well?
• Is everybody contributing an equal share of information?

If you’re quiet, try to speak up more. If you talk too much, be mindful of how much you may dominate a conversation. If you’re not participating at all.. why are you there?

¹ You’ll be happy to know that Harry also gave his two-weeks notice yesterday.

First, a quick update from our sponsors…

Brian and I talked yesterday and agreed to stop referring to Dialogue-Driven Development as DDD. We’ll leave that for the Domain-Driven Design fans. From now one, the short version for Dialogue-Driven Development will be d3.

MSM posted an email in regards to d3 on a Scrum development mailing list. He writes, “While I believe there’s room for plenty of Agile methodologies in the world and wouldn’t want to discourage the development of DDD if it helps them get their software written, I would hate to see Scrum described inaccurately, especially in a well-oiled meme propagation machine like the Rails community.” (link)

Michael D. Ivey responded with, “That being said…as someone who has gotten 100% into Rails development, I find myself using Scrum less. At least, on the surface, official Scrum. Rails makes me^{W^W}Wlets me be so productive that we are basically having 1 day sprints.

What’s interesting here is that we have a someone who is working with Ruby on Rails and finds himself using Scrum less because the environment is much different. This is exactly why Brian and I started seeking out something even more lightweight. We’re not aiming to replace other methodologies, but to structure our own that focuses on dialogue. With Rails, we’re finding that the amount of collaboration and dialogue with clients has both increased and improved tremendously.

Ivey also goes on to say, “I believe, having done Scrum well, and having done the ””Rails experience,”” that what Robby and …. the other guy …. are describing with ””Dialogue Driven Development”” is exactly what happens when you start with Scrum or something Scrummy, add a hyper-productive programming language and framework, mixin a very active and interactive customer, and then just start running at a comfortable pace and see when you get somewhere cool.

Perhaps Michael is right… and of course, this is open for discussion. :-)

Brian and I are spending a good deal of time thinking and talking about this stuff. We want to outline a new pattern that changes how requirements are gathered and documented through dialogue. It’s apparent that as we read different peoples comments on our articles that the general consensus is to interpret the Product Backlog pattern described in the books on Scrum in a way that works best for your team. The approach outlined in Agile Software Development with Scrum doesn’t work for us.

What’s your pattern? Share your story…

A few months ago, I posted an article titled, Trawling for Requirements, which was just before the Argon Express left for our trip to Chicago for RailsConf 2006. I’ve been kicking around some ideas with Brian ever since that afternoon on how there just seemed to be a big void in software development arena. It’s always felt that so many of the software development methodologies are designed to get developers to find a better way to work for and with clients. It’s our goal to outline a pattern that simplifies this process, not just for ourselves, but also our clients.

With each new project that our team starts, we are given an opportunity to improve on our evolving pattern for communicating with clients to better understand their goals. If there is one thing that we’ve seen help this process, it is consistent dialogue. When good collaboration exists through meaningful dialogue, confidence increases in not only the client. As developers, we are able to be confident that we understand their goals. This should generate better results.

“You are not writing requirements to serve as a contract with your client. Rather, you are writing them to ensure that both of you share the same and demonstrably correct, understanding of what is needed. Do not ask the client to sign off on the requirements; instead, ask the client to sign on to them and make them a collaborative effort.”

—Suzanne and James Robertson, Mastering the Requirements Process, 2nd Ed.

In Mastering the Requirements Process, the authors list the following as being key to identifying the project goal.

• Purpose: What should the project do?
• Advantage: What business advantage does it provide?
• Measurement: How do you measure the advantage?
• Reasonable: Given what you understand about the constraints, is it possible for the product to achieve the business advantage?
• Feasible: Given what you have learned from the blastoff, is it possible to build a product to achieve the measure?
• Achievable: Does the organization have (or can it acquire) the skills to build the product and operate it once built?

At first glance, I would agree that these are good questions to find answers for with your client.

Requirements, Not Solutions

Many clients come to us with a list of solutions (features) that describe implementation. This has been one of our concerns with the Product Backlog as it doesn’t discourage feature lists. Take a moment to read Goal Oriented Requirements, which gives you a few bullets to think about when interacting with your client when extracting requirements.

Take a moment to read Brian’s thoughts on the product backlog.

In Mastering the Requirements Process, the authors give two examples to show the difference between a solution and a requirement.

A Solution

The product shall display pictures of goods for the customer to click on.

A Requirement

The product shall enable the customer to select the goods he wishes to order.

When requirements are defined in this form, it allows for further dialogue about multiple implementations.

For example, we’re working on a project where the product shall enable the users to send messages to a central system. We’ve defined a few specific implementations (email, text message, web form) and know that as new technologies emerge, the same requirement will still apply. It’s important to remember that we are gathering requirements not solutions and from there… we can collaborate with the client to design a solution that fits the requirements. Before we attempt to do solve the problem, we must ask that the requirement is aligned with the project goal.

We want our clients to assimilate our development methodologies quickly and naturally, which is what Dialogue-Driven Development aims to help achieve—namely through communication, something we humans do rather well. By lowering the learning curve and accelerating the integration of clients into our process, we can focus a greater sum of our collective energy on the needs of the client, the purpose of the project, and the goals of it’s users.

Although, perhaps we have it all wrong when trying to make software and the development process simpler as Paul Kedrosky suggested. ;-)

Our clients don’t just want simplicity. They deserve it!