Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 17:59:00 GMT)

Dialogue-Driven Development

Posted by Thu, 03 Aug 2006 02:55:00 GMT

13 comments Latest by Pat Wed, 09 Aug 2006 03:24:52 GMT

Just a few months ago, I wrote a short article called, The Art of Delivery, which outlined how we at PLANET ARGON approach iterative development and how it relates to quicker release cycles. I wanted to follow up with this and add some more thoughts to that and what we’ve been trying and learning since that point in time.

With iterative development cycles, we’re able to focus our attention on very specific and well-defined goals while we work with the client to organize the other goals that they’d like us to help develop solutions for.

An End to the Product Backlog

While everyone at PLANET ARGON has been doing some research on modern Agile-related methodologies, we’ve been throwing a lot of ideas back and forth… and often times we end up cherry-picking individual practices and throwing it into our evolving processes.

The problem that we’ve seen with most examples of using a standard Scrum Product Backlog is that it focuses too much on tasks rather than providing solutions for goals that are central to the success of the project. It also requires that someone maintain, on a regular basis, a well-defined list of tasks, which often times the client (Product Owner) dictates. We’ve seen many situations where a client has more feature requests than is necessary in order to attain the goal that was originally set. If we had a nickel for every time we heard someone say, “wouldn’t it be cool if it did this?”

I’ve personally worked on many projects that fell into this routine too early in the development cycle. Most clients that we work with are trying to provide a solution for their users and aren’t always the best Domain Expert. Taking the whole less is more approach, it’s vital that the earlier you can get your users in front of your application, the sooner you can get them to generate feedback, which aids in you making educated decisions about what to add to the project later on.

Features are Expensive

Aside from the monetary costs of adding new features and functionality, it is important to remember that as you add new code to an application you increase the maintainability and overall scope of the project. With each new feature, the requirements change, complexity increases, and as far as your users are concerned, they are now being exposed to something new, which may or may not be what they want or need. For example, I was in a sales meeting yesterday and our potential client mentioned that at a former job during the dot-com era, their web team added e-Cards to their web site and it had nothing to do with their business model. The users did however use this new feature but they later went out of business. Perhaps they should have been an e-Card business instead. Imagine if BaseCamp added a local weather feature… I might use it… but it doesn’t help me manage our projects any better.

When clients approach us with a new feature that wasn’t previously discussed, we have to ask them they Why, What, and How? What goal is this feature providing a solution for? Do we already have a solution implemented that solves this problem? Is this a new goal and how (and why) did this goal come about? What are the costs of implementing such a feature and how will it affect the current stability of the user base and application? If we put it off 3 months, would it cause the project to come to a grinding halt? What about 6 months?

It’s important to always remember that one of the biggest problems in software development is feature creep. Many projects fail due to this and as a project manager, developer, or client… please consider the consequences and benefits of each new feature. Focus on the goals and connect the dots from there.

Get the goals clearly defined and provide clear and simple solutions for them.

Just Say NO to Bloat!

Start with a Mission Statement

One of the new things that we’ve begun doing with a few new clients is assigning them with an initial task of providing us with a Mission Statement. From the Mission Statement we can ask how each goal that the client and we outline relates to it. If one of the key goals of the Mission Statement is, “to provide gorillas with easy access to basketballs”... we will have to question any goals that imply that we might also need to provide access to soccer balls, car batteries, or scissors… or that when a gorilla is getting their basketball we might want to provide them access to stock reports. We’re not trying to solve all the gorilla’s problems and it would be naive for us to think that we know what they want before we’ve had a chance to really engage in that dialogue.

Users are the Domain Experts

Very rarely do we get a chance to interact with users before we’ve begun coding a project and getting an alpha release in front of a subset of users. Brian and I just got back from a few days in Washington DC, where we worked with a new client. They have an existing GUI application that began development in the mid-90s and we’re being contracted to help build a new solution to the problem that they began to solve ten years ago. The application has suffered from a lot of feature creep as many evolving products do. As they gave us a demonstration of their existing product, we saw first hand how it was even difficult for them to remember why Feature X was in the system. “Most customers don’t use that anyways.”

So, why is it there? Of course, nobody remembers why everything is there now. As developers come and go projects get managed by various people over the course of their life, many of different opinions and features get injected into the application. It’s a common problem and it takes a lot for a company to finally admit that it’s time to throw it out the door and start fresh.

The old rules don’t apply anymore. *

One of the first things that we did in our meetings was discuss what goals their product was aiming to provide solutions for. What do they believe that their users want and need? To get this answer, we scheduled a few conference calls with real users of their existing software! I cannot describe how helpful those interviews were and we saw a lot of consistency in their goals as users of such a system. It became apparent that they were the Domain Experts and as we move forward with the project we are going to have access to interact with those users.

Rethinking the Dialogue

When thinking about delivery, we must consider the major obstacles to overcome during the course of an iteration or release cycle. More important than having well-defined deliverables is having well-defined expectations. If you’re delivering a prototype, be clear about what a prototype is and what is it not. Schedule regular meetings with your client throughout the process. Keep the client updated as much as possible. Ask questions as soon as you can… and be sure to ask them the right questions.

There is an art to it and it’s important that you keep this process lightweight and agile like you do your development process. Perhaps we need to think of development and project management under a new heading… *Dialogue-Driven Development? DDD? ...just what we need… another acronym. ;-)

UPDATE

We’re not going to call it DDD… just d3.

Get help with your Rails project

comments powered by Disqus
Comments

Leave a response

  1. Avatar
    Reagan Thu, 03 Aug 2006 03:49:56 GMT

    In a recent project that my development team has been working on, we decided to try pairing with the client and both the developers and clients learned a lot about the goals of the business and how it related to the code the developers were writing. One of the biggest problems we were hitting was that we would begin developing a project too soon in the process in an effort to start the dialogue sooner. What we’ve learned is that dialogue starts much earlier in the project and it’s important to understand what the client’s goals are before we attempt to implement a solution based entirely off their feature list.

  2. Avatar
    Ryan Allen Thu, 03 Aug 2006 04:13:10 GMT

    Hi Robby! I’m wondering how you would class a project a failure? I know roughly of the classical definition, but what is your measure?

  3. Avatar
    Ryan Allen Thu, 03 Aug 2006 04:18:04 GMT

    Oh and I’d like to add, that I recall Jeremy was talking about reading Domain Driven Design by Eric Evans a few weeks ago, I’ve only read a few chapters but it sounds kind of similar to what you’re describing in the sense of being as close to the Domain Experts as possible.

    If you have not read it yet, go grab it from his shelf and read the first few pages of chapter one (starting on page 7). You’ll totally dig that story! It’s amazing what they came up with! Big Fat Smiles all round.

  4. Avatar
    Justin Thu, 03 Aug 2006 04:38:12 GMT

    Ryan, I would think that it would be hard to generate a clear definition for a failed project. A client that sees the project not evolving into what they hoped to see could be seen as a failure in their eyes and the developers might see it as a huge breakthrough. It’s subjective depending on what type of stakeholder you are on the project and what your expectations were.

    For me, a failed project is when a client stops paying their bills and stops returning your calls. Any project can hit that grey area that feels like it’s headed in a downward spiral and if a development team is experienced and smart enough, they should be able to turn things around. Failed projects can equally be due to the clients as the development team.

  5. Avatar
    Reagan Thu, 03 Aug 2006 04:43:37 GMT

    I would have to agree with Justin on this and not just because we work together! ;-)

    We’ve seen many projects hit a point where we feel like the project can’t advance due to the client’s inability to make compromises or allow for the development team to be part of the solution building process. If a client has all the answers well-defined and in the form of 250 pages of technical specifications and requirement documentation, run far, far away.

    Waterfalls only move water in one direction.

  6. Avatar
    Robby Russell Thu, 03 Aug 2006 14:09:43 GMT Recommend me on Working with Rails

    When Martin Fowler was speaking at RailsConf he used the word “dialogue” several times in relation to how Ruby on Rails encourages dialogue earlier in the development cycle. When we’re able to develop prototypes within a Rails environment, we’re able to provide the client with a much richer concept of our proposed solution to their goal. I remember sitting next to Brian Ford and hearing Martin Fowler reuse the word “dialogue” and I wrote down on a piece of paper, “Dialogue Driven Development.” Brian smirked and I have been thinking about this ever since. What I’ve noticed when working with many developers (trying not to generalize them all here… but many... not all) have this idea that they have a problem put in front of them and they can code their way to a solution.

    This is why we’ve been focusing so much on encouraging clients to work with us on an ITER-ZERO (Iteration ZERO), where we focus on capturing goals (not just requirements). Pushing the dialogue to the very first interactions with our client. Focusing our attention on the big picture, goals, the mission statement, and documenting terminology in a glossary on a wiki, and showing the clients how to interact with us through the wiki, basecamp, and face-to-face meetings, we’re essentially opening up the doors to Dialogue-Driven Development.

    The coding and delivery stuff is easy when there is a healthy and vibrant feedback-loop with the client.

  7. Avatar
    Robby Russell Thu, 03 Aug 2006 14:26:26 GMT Recommend me on Working with Rails

    Ryan,

    A failed project is a project that has failed. ;-)

    This is actually fairly difficult to measure and it really depends on who is calling it a failure. I’ve seen projects that were failing due to miscommunication, bad expectation management, over-promising and under-delivering, and bad upfront architecture design. Usually, it comes down to a breakdown in forward-thinking dialogue between the various stakeholders in the project. When you build confidence in the client that you understand what their goals are… you can achieve a lot in a meeting with them.

    I’m sorry that I can’t give a really good answer to this… but when a project starts to smell… it’s a good sign it’s failing. Accepting responsibility for the failing of a project is never fun… but sometimes necessary.

  8. Avatar
    Robby Russell Thu, 03 Aug 2006 14:30:14 GMT Recommend me on Working with Rails

    Reagan/Justin,

    Pushing back on feature requests in exchange for building solutions that attain their well-defined goals should be encouraged as much as possible. Feature lists are too easy to build and don’t always solve the problem. Not understanding the client’s goals can be one of the biggest problems in a project. Complex goals should be broken down into simple goals and when we are focused on simple goals we can build simple solutions with precision… and hopefully in less time. If you’re current project has too many complex goals, perhaps it is time to break those down and generate new forms of dialogue with the client.

    With all the hype around Web 2.0™ currently… almost every Product Backlog I would expect a Product Owner to deliver would have a lines with ‘tagging’, ‘social networking’, ‘blogs’, etc… and when a client already has the solution figured out… it’s hard to get them to work back to the original goal was that prompted them to decide they needed X, Y, and Z to achieve these goals. Start with the goal… work your way to the solution… not backwards. :-)

  9. Avatar
    Ryan Allen Thu, 03 Aug 2006 15:41:37 GMT

    I’m going to keep going at that you can define failure :)

    You said: I’ve seen projects that were failing due to miscommunication, bad expectation management, over-promising and under-delivering, and bad upfront architecture design..

    So those are the causes of the failure, but what are the specific effects of those causes? If you define them then you can start to define what a failed project actually looks like.

    So therefore:

    • Miscommunication can lead to the implementaiton of the wrong solutions
    • Poor expectation management leads to client disatisfaction (missed deadlines, being delivered something other than they were expecting)
    • Over-promising and under-delivering obvioiusly it’s just a right pain in the arse and if they have other things running in parellel to your software development (say hiring people or organising conferences, or making promises to other businesses), and my favourite:
    • Bad upfront architecture leads to not inital problems, but problems later down the road when you have to inevitably change direction or extend the existing product.

    So would it be reasonable to say that a failed project is one that implements the wrong solutions to problems (that may or may not have been defined with your customer), delivers something totally different to what the customer was expecting (regardless if it’s the right or wrong solution), delivers late or over budget (if you quoted fixed price it’s your own loss!) or with features missing that were promised, or fails to provide any return on investment when you have to modify or extend the software (ala PHP souphack… Sorry, I’m biased).

    I dig what you’re saying, and a lot of the practices you advocate look like they’re trying to avoid the actual effects I’ve mentioned above.

    Your thoughts? :)

  10. Avatar
    Robby Russell Thu, 03 Aug 2006 16:14:01 GMT Recommend me on Working with Rails

    Ryan,

    Yes, I would have to agree with you here. It’s important to understand why things are failing and to do everything in your power to avoid those from occurring (or reoccurring). Nobody wants to be responsible for a failed project… at least I hope. ;-)

  11. Avatar
    Samuel Thu, 03 Aug 2006 18:38:05 GMT

    Robbie,

    I take it that you are not a fan of Feature-Driven Development?

  12. Avatar
    Howard Sat, 05 Aug 2006 22:42:42 GMT

    I saw a reference to your post on an Agile-related forum and decided to give it a read. I’ve been working on getting my development team to accept Scrum as their lord and savior and I honestly think it would be easier to get them to let me pull their teeth out. They don’t like all the roles required in a project and you’re right the backlog always ends up resembling something like a long-winded excel file with tasks and features. 150 lines in a backlog doesn’t help anybody get a good sense of where the project stands each day. There must be a better way. How does Dialogue Driven Development address these two concerns that my team members and I are having trouble with?

  13. Avatar
    Pat Wed, 09 Aug 2006 03:24:52 GMT

    This is sweet!

    The whole time I’ve been using Rails I thought the point was to build quality software quickly. Less time spent in meetings, more time doing stuff that matters.

    But now I realize that I can use all that extra time for more meetings.

    I used to be an Agile Developer, but you’ve got me yearning to be an Agile Meetinger.