This post originated from an RSS feed registered with Ruby Buzz
by Robby Russell.
Original Post: The Art of Delivery, part 1
Feed Title: Robby on Rails
Feed URL: http://feeds.feedburner.com/RobbyOnRails
Feed Description: Ruby on Rails development, consulting, and hosting from the trenches...
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. :-)
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?
Previous Topic
