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

Clients Deserve Simplicity

Posted by Mon, 07 Aug 2006 02:57:00 GMT

1 comment Latest by Sammy Mon, 07 Aug 2006 10:41:08 GMT

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!

Dialogue-Driven Development is about rounded corners

Posted by Sat, 05 Aug 2006 14:49:00 GMT

5 comments Latest by James Mon, 07 Aug 2006 21:01:31 GMT

In response to our introduction of Dialogue-Driven Development, mechanismalley.com writes, ”...it seems to be the Rails community’s pattern to take an existing concept — or misconception — put rounded corners on it and deem it something new.” (link)

I’m not sure that I can completely agree with this generalization. What I’ve witnessed as a member of the Rails community, is an attempt to simplify code, solutions, processes, and as a result… conversation between developers and clients has become much richer and coherent. Take this with a grain of salt as this has only been my experience. Complex solutions are complex to explain and often too complex to know if they are actually solving the right goal. On the other hand, simple solutions make way for better dialogue. With Ruby on Rails, we are provided with a foundation that encourages and embraces best practices and simple solutions (rounded corners?), which makes it easier to discuss with the client. This is what fascinates me about Ruby on Rails… and what Martin Fowler in his keynote at RailsConf.

Perhaps it makes sense that what Brian and I are outlining with our approach to defining patterns for client<->development team interaction evolved through us working with Ruby on Rails. However, there is nothing that requires Rails in order to follow the patterns that we’re discussing. In Brian’s first article about d3, he referenced the following…

“What we are seeing is a drive toward simplicity. Conventional wisdom once was “quick necessarily means dirty”. Ruby challenges that.
Martin Fowler

At the very core of our approach with Dialogue-Driven Development is the Agile Manifesto. The author of this post is correct, we’re taking an existing concept and putting rounded corners on it. We’re trying to make it simpler. We find that Scrum is too process heavy and while we can see it being a good step away from the Waterfall approach, it’s still not giving us that warm and fuzzy feeling. Rails developers know what that warm and fuzzy feeling is… and we are hoping to find something that gives our clients and us the same feeling when we’re not coding. We want lightweight methodologies to complement our lightweight frameworks and patterns.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

The Agile Manifesto

It’s time to start rethinking how we work with clients. Too often we end up working for them and while we might build them what they want… we might not be giving them what they need.

So, I must ask… has working with Ruby on Rails reshaped the way you think about client and developer conversation? If so, for the better or worse?

High traces of collaboration and dialogue are usually found in the recipe of any successful project.

Related Articles

DDD (d3) is the new conversational software development

Posted by Fri, 04 Aug 2006 02:28:00 GMT

I’m not sure how I missed this recent post on Martin Fowler’s bliki last week on Customer Affinity. In this post he references when the term “agile” first came about and mentioned that, “one of Kent’s suggested names for ‘Agile’ was conversational software development – the point being that it’s a two way communication. “

Conversational Software Development.

This doesn’t sound so different than what Brian Ford and I are calling, Dialogue-Driven Development. ;-)

Fowler goes on to say, “This isn’t something like a telecoms protocol that you can define, but the back and forth discussions about how software can enhance the business are where the real value lives. Much of this conversation is of half-baked ideas, some of which grow into valuable features – often ones that aren’t things that the customer originally thought of.”

If you didn’t follow the thread of comments on my recent post on Dialogue-Driven Development, you might not know that this name came up during Martin Fowler’s keynote at RailsConf when Brian and I were sitting next to each other and Martin kept reusing the word “dialogue.” Brian and I can’t seem to agree if I said, “Dialogue-Driven Development” out loud or if he wrote it down on a piece of paper first… so we’re going to have to share the credit. What made this so fascinating at the time was that for the entire trip from Portland to Chicago on the Argon Express, Brian and I had been discussing a lot of what we’re planning to change and define with our approach to Client/Project/Development Collaboration & Management… and in the end… we left Chicago with DDD d3.

Thank you, Martin for being part of this process.

Like all things, this approach is open to discussion dialogue.

UPDATE

Brian has written an article called, It’s all about the dialogue. (digg.it)

Dialogue-Driven Development

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

13 comments Latest by Pat Wed, 09 Aug 2006 02: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.

Older posts: 1 2 3 4