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.

Borat finds a new stakeholder

Posted by Fri, 09 Jun 2006 13:23:00 GMT

2 comments Latest by Robby Russell Fri, 09 Jun 2006 17:16:34 GMT

Picking up on my last Borat post, Prototypes Are Your Friends, I would like to direct you over to the next post in the series, G’day Project Borat where Brian Ford jumps into the game…

“When we, as developers, began focusing on user-centric design and usability, it was a recognition that users deserved respect and need not be rescued, if you will, by our bright ideas. In a big way, we needed to keep our bright ideas out of the user’s way.”

Read more...

Trawling for Requirements

Posted by Thu, 08 Jun 2006 20:49:00 GMT

5 comments Latest by g! Fri, 09 Jun 2006 08:46:28 GMT

This morning, Brian Ford and I headed over to Powell’s Technical Bookstore to pick up their one used copy of Code Complete, 2nd ed. While we both stood there reviewing the contents, I felt somewhat unsatisfied with the purchase that I was about to make. It then occurred to me that what I was looking for was quite different and while the programmer side of me felt the need to make the purchase, there was another void to fill. Requirements gathering, prototyping, use cases, and delivery are areas where I am really focusing a lot of my attention to. Brian and I discussed how Test-Driven Development solves some of the problems surrounding application development and Behavior Driven Development might pick up on some of that slack as well.. but what about the stuff that happens prior to sitting down to code these units of work? How do we define them? How do we extract meaningful requirements from the client and allow them to participate in a sign-off process where they confirm that they are confident that you understand what their problem is and that you have a clear picture of a solution? These are questions that I have been trying to answer for myself.

While talking with Brian during our walk to and in the store… a random Delphi developer that struck up a conversation with us about the Code Complete book we had in our hands and XP methodology. While listening to him, I noticed a book title, Mastering the Requirements Process, 2nd ed., which I picked it up and glanced at the table of contents and noticed the title for Chapter 5, “Trawling for Requirements.”

”...in which we drag the net through the work area looking for requirements, and discuss some useful techniques for doing so”

I was immediately drawn to the book at that point and decided to purchase up both books for the PLANET ARGON library. It’s written by Suzanne and James Robertson and published by Addison Wesley.

The book describes this figure with, “The overlap between Requirements Gathering and Systems Modeling varies as the development of the product progresses. Initially, very little modeling is done, and the majority of the effort focuses on gathering and verifying requirements. As development continues, the modeling activity expands to occupy a continually greater proportion of the effort.”

I’m really looking forward to diving deeper into this book and will share my thoughts on Requirements Gathering and how we’re doing it at PLANET ARGON. :-)

Prototypes Are Your Friends

Posted by Wed, 07 Jun 2006 20:30:00 GMT

4 comments Latest by Danger Sat, 10 Jun 2006 09:20:47 GMT

I’d like to apologize for not keeping you updated on Project Borat. If you’d like some background, please read Project Borat, an introduction.

“In early stage design, pretend the interface is magic.”[1]

We’re finishing up Iteration 1, which is a prototype and requirement feedback process. When I used to be a house painter, we’d spend time painting small samples for the customer. The customer would come by when the paint was dry and compare the colors to what they had pictured in their mind and once there was an agreement, we’d move forward with purchasing the necessary quantity of paint for their house. Thinking back… I never questioned this “Show them samples” process as it was how the company did business… but now it seems obvious that people must that made many mistakes of buying colors that weren’t exactly what the customer wanted. Then the painters would be required to repaint. Development work resembles this and this is where prototypes come into play. Painting a house is not quite like developing an application… but that reoccurring process of encouraging customer feedback as early as possible is very similar. It is this feedback that builds confidence that you understand the customers desires. However, if you end up with too much of the wrong color of paint… you might be able to paint a few dog houses with it. ;-)

Over the past few weeks, we’ve had several meetings with the Client to discuss prototypes, user interaction, and goals. For example:

  • When User does X, what information should they be presented with?
  • What types of users will use this application?
  • What are some of the goals and intentions of the users?
  • Might a user want to do z before x?
  • Are users interested in doing something completely different?

During this Iteration we also hit a major milestone for the client. For the first time since they came up with their idea, they were able to see something visual and had semi-functional to play with. The prototype resembled what they had been thinking about conceptually for several months. It can be easy as a developer to forget the importance and excitement that goes along with seeing something that consolidates your ideas… visually for the first time. This process requires a good stream of feedback and asking specific questions about functionality possibilities and not burdening the user with too much information in certain contexts… while still providing them with enough to keep them interested.

In The Art of Project Management, Scott Berkun raises the following questions for iterations and prototypes.

  • What requirements does this satisfy? Can we verify this? (Usability, use-cases, etc.)
  • What’s good and bad about this design relative to the problem it’s supposed to solve (Pros and cons for each of usability, business, technology, considerations.)
  • What data do we need to evaluate this design? (Perhaps a usability study, an informal review by a programmer for engineering sanity, marketing, an expert’s opinion, etc.)
  • What did we learn from this design that we should keep in the next attempt? Eliminate?
  • Are there any other idea groupings or from other prototypes that we should include?

Another important thing to do during any iteration is to keep a list of open-issues. Berkun suggests using a simple tool for this. We’re using plain text files in subversion and using Textile for markup.

What’s next?

  • Idea consolidating
  • More prototypes
  • Discussing architecture plan
  • Scheduling

Until next time…

1 Alan Cooper & Robert Reimann, About Face 2.0: The Essentials of Interaction Design. Wiley 2003.

The Art of Delivery, part 1

Posted by Wed, 31 May 2006 05:09:00 GMT

1 comment Latest by David Rosebaugh Wed, 31 May 2006 20:52:02 GMT

Over the next few weeks, I am going to interact with the readers of my blog in a segment that I call… The Art of Delivery.

As a professional developer, my experience with working in development environments has been fairly unique each time. Up until PLANET ARGON, I had very little say in how we structured the very process that I was expected to follow. Granted, there is is a benefit to having leaders who have some good experience to help guide a team throughout the life span of a project, but a leader should also posses a sense of humility and stay agile in their processes. You cannot succeed in an environment where an old dog can’t learn new tricks. This sort of thinking reminds me of managers who feel that their sole responsibility is to manage people. People manage themselves, a leaders helps facilitate self-management. I’ll be the first to admit that I have much to learn in both areas. :-)

Delivery!!!

Earlier this year, the PLANET ARGON Core Team met to outline new processes. One hot topic was project communication and delivery. One of the areas that we all insist that we excel at is building better estimates and managing project delivery more efficiently. Every one on our team has their own ideas of how best to coordinate projects and we wanted to find a way to invent our own pattern… but what we realized is that we were borrowing a lot of ideas from books we’ve read as well as the lessons learned in previous environments. One of the things that we realized is that while we weren’t horrible at building estimates for a six month project… it was that we knew that the requirements of (almost) any project would change scope within six months. How could we accommodate new ideas in a project without disrupting the budget and the agreed timeline? We wanted to rethink this process and push ourselves to follow an iterative approach.

Focus on the now and then the then

Since then we have begun to define and redefine what each stage of a project looks like. How do we communicate stages of a project with our clients in a meaningful and clear way?

I’m now about to give away how we do business at PLANET ARGON.

Project(s), Release(s), Iteration(s), Task(s)

It’s not rocket science… and it shouldn’t be!

  • A project has many releases
  • A release has many iterations
  • An iteration has many tasks

What we do is isolate an iteration by collecting a set of goals to be accomplished that the client and we agree on as being of high value to the success of the project at this point in time. Tasks are essentially the individual steps needed to achieve those goals and we don’t go out of our way to list each one of those during an estimate process as some tasks take less time than it takes to generate an estimate for them. We include our developers in our estimate and specification process as they often have many great questions to send to the client to get further clarification. Often, much of this clarification process happens during a first iteration, which some call Iteration Zero... as no code is developed during this iteration. Prototypes, estimates, mockups, and Q&A is what iteration 1/zero consists of. This is that important design phase that people talk so much about. :-)

Let’s get back to thinking about delivery… and we’ll make the assumption that you’ve already worked out your estimates and are now ready to work on your (next) iteration.

Open Question: As developers, project managers, and curious readers… how do you proceed?

...to be continued

The Daily Stand Up, part 2

Posted by Mon, 29 May 2006 16:11:00 GMT

4 comments Latest by Reagan Wed, 31 May 2006 04:29:40 GMT

In a previous post, I outlined how the PLANET ARGON team handles their communication of day-to-day work with the daily stand-up. Several people posted comments about similar processes and some suggestions were made to keep them from getting too stagnant. I wanted to highlight a few of those comments.

Aslak Hellesoy suggests, “Use a token – a rubber ball or something – for each person giving status. Only the person holding the token is allowed to talk.”
Florian Weber said, “Everybody standing up makes meetings go faster and more focus…”

However, not everybody is convinced…

Doug said, “I hate meetings, why on Earth would you punish your employees on a daily basis?”

Perhaps Doug has worked in environments that encourage too many bad meetings. A client recently said, “meetings are expensive” when we agreed to not have too many meetings throughout the project. Less meetings that are well-focused are much more valuable and productive. :-)

The one that caught my attention was the comment made by Aslak Hellesoy… he goes on to say, _“When a speaker is done, throw the token to a random person instead of just handing it to the left or right. This forces everyone to stay more alert, as noone knows who’s next.”

This got me thinking about how we had made it a ritual to stand in similar positions and I would start off the meeting. The team wasn’t too keen on throwing a ball around the room as we often hold coffee in our hand… so I came up with the following solution…. which reunites us with our little friends, the index cards!

Randomizing Daily Standup Meetings

Basically, all I did was take a stack of index cards and write a number on each one. Then at 9:15am PST, we all walk into the meeting room and take one. Whoever got #1 goes first and we work our way up from there. We’ve done this three times so far and most of the team seems cool with it. I’ll keep you posted as we solidify our approach to The Daily Stand-up.

...and of course… this comment also reaffirmed our decisions to do daily stand-ups…

Kevin Rutherford said, “Cool. And by “inventing” the idea yourselves, I guess you have much greater buy-in too?”

Related Posts

Older posts: 1 ... 7 8 9 10