Riding Agility
by George White
We recently completed a project for a new client, Vizzitt. The project had a short duration, a mere four weeks. And the budget was fixed. And the client needed an entirely new site up and running, with a significant number of features. How to do it?
The answers we came up with:
Agile Development
We followed a roll-your-own agile approach during this project. While some of us have participated in agile development using established practices such as XP and Scrum in the past, this is the first time the I’m aware of were Bit Group was trying out an agile process in a determined manner. Unfortunately, we didn’t have time to train everyone up on using one of the existing methods so we synthesized something from existing practices that would be easy enough to roll out quickly and would still provide enough framework to get the job done.
Here’s an excerpt from the agile process as proposed at the start of the project:
- 5 day iterations. This is very short, but we don’t have enough time to do ten-days. This constraint will also help us to keep the scope down.
- Each iteration produces a working release
- Have a client on site (as much as possible)
- Daily 15 minute stand-up meetings
- Divide the job into user stories, add estimates to each story, then work with the clients to plan what stories go into each iteration.
- Re-evaluate the stories for each iteration at the beginning of each new iteration.
- Use Planning Poker to capture user stories and estimating. We will work the clients to create the stories and to do the estimations. Once we’ve got that, we can plan out our iterations.
- Track velocity.
If you know agile development, you can see that we borrowed some of the common practices. But we also left a lot of stuff out. We wanted a light-weight process and this seemed like the lightest one that would work. So, how did it go?
Overall, pretty good.
Somethings That Worked Well
Iterations
Having to build and deliver an iteration on regular intervals was a great boon to keeping us sane. We could plan out what needed to be done and validate what we had planned against the delivered build.
Having the Client On-site
Having the client on-site and available pretty much every working minute was vital to the project. We were able to review work in progress, fill in holes almost as quickly as they were found, and to ask for assets and content that were needed to take the application from functional to complete.
It seems risky to let the customer see the sausage being made, but it practice it was liberating. There were no surprises and the customer was able to see how much work went into getting their application built. They were able to participate directly in every stage in a collaborative way.
I will work this way whenever I can get it!
Stand-up Meetings
Having a daily review of where you are and where you’re going helps keep everyone sane. We were able to re-prioritize and re-allocate work as needed, figure out what issues really needed to be addressed, and generally share our feelings on project progress.
Some Things That Worked Less Well
Iterations
Given the short total duration, we didn’t have much choice but to do very short iterations. On one hand this was a good thing, since it kept us focused. But we didn’t really have enough time to revise the stories and plan out the next iteration. We could have handled this by reducing the scope, but we really wanted to get in a certain level of base functionality.
For future projects, we are going to push for two-week iterations. This is still short enough to provide a decent constraint for purposes of implementation and client review, but long enough to have some planning activities.
User stories
We had some problems with the stories. The biggest issue was that many of the stories were not granular enough to implement. In those case, we re-wrote or decomposed some of the stories to get to something that we could definitively build.
Another problem was that a lot of implied architecture arose from the stories we had. Mike and I were able to add additional stories to back us into the basic functionality needed to implement the business-oriented features. But it would be very true to say that the stories weren’t complete.
Process Discipline
By the end of the project, we weren’t following our original process as closely as I would have liked. The factors that lead to this were multivariate, but when boiled down, it comes to this: we were rushing to finish the project and we let the process go in favor of getting things done.
This worked out alright, but it could have been disastrous. What kept the car on the road was the tight integration of the team and the constant communication between us and the client. But it was a bit loose. Lengthening the iterations will help with this, but team experience will also be a factor. And we’ll need to revise the process itself to fit what really works for us.
Oh, and we never tracked velocity. 
Ruby on Rails
If you are working in Web application development and you haven’t heard about Rails then you must really be immune to hype.
I can say with confidence that a significant part of our success in delivering this project on time was the choice we made at the outset to implement using Rails. It was not as easy as “everything just worked” but the framework made getting things done smoother and simpler.
I could bore you with the specifics of how Rails and Ruby helped us get Vizzitt out of the gate in four weeks. But it’s really not important. What is important is that the developers were able to a) concentrate mostly on application functionality and b) we were able to react to new feature, enhancment and bug fix requests rapidly. There’s nothing quite as satisfying as fixing a bug as soon as it was reported and being able to show the client the fix in minutes.
And I LOVE Ruby. Not enough to leave my with and run away with it, but I would consider replacing one of our cats with Ruby. Seriously. Ruby, unlike the cats, does not shed.
Epilogue
The Vizzitt project was successful by most of the standards of measurement. We completed it on time, we did not blow out the budget, it’s not shot through with bugs. But two factors indicate the success of the project more than any others:
- The clients were happy with the outcome
- The project team felt really great at the end
The reason the first item is so important should be obvious. Our goal is to satisfy the customer by adding value and providing them with the tools they need to facilitate their business goals. If they come away from a project feeling like we’ve done that, we get a big tick in the win column.
The second item is, to me, an even greater indicator of success and a big part of the reason that we’re going to follow the basic approach in this project whenever we can. The team felt great at the end of the project. Happy, content with the work, and ready to tackle new projects. No one was burned out. We all still wanted to speak to each other.
If you have ever worked on a “typical” software project, you know how valuable this great feeling is. Building software in teams is often an arduous, unpleasant task. There’s a whole host of reasons for this and I won’t re-hash them here. But to come off of a project and feel like you’ve knocked one out of the park, that’s pure gold.
And we’re going to do it again. And again. And again.
Tags: Agile, Development, Rails
July 22nd, 2008 at 10:19 am
Great project summary. I’d just like to add that there was some UI and visual design work included in this project, overlaid with ongoing development work. The iterative process worked great on the design side as well, but as George mentioned, the short iterations allowed for limited design work. It’s also a transition, as a designer, to work behind development rather than ahead of it.
What worked well:
The client was open to receiving informal documentation and deliverables (e.g. napkin sketches)
Transparency throughout the project, which is hard for designers to do - let you client into your studio to see a work-in-progress
Bottom line, we were able to produce as much as humanly possible in a limited amount of time. Longer iteration cycles will allow for additional design and multiple rounds of reviews/iterations (and not require homepage comps to be produced in a weekend).
Lastly, as George mentioned and I feel is necessary to reiterate, the team was very happy at the end of this project!
July 24th, 2008 at 9:23 am
Chris:
Good to hear from you man!
So, planning poker. The idea behind planning poker is that an aggregate estimate from all team members is more likely to be accurate than from a single member. Here’s what you need to play:
1. A project
2. A team, ideally multidisciplinary and all deeply involved
3. A collection of user stories
4. A deck of estimate voting cards
5. A table and some comfy chairs
The estimate voting card “hand” consists of note cards with the following values written on them:
0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?
Each player of the game gets a hand of these cards.
To play the game, pick one of your user stories and read it out loud. The players should discuss the stories, clarifying it if needed. Once the players agree that they have an understanding of the story, it’s time to play the hand. Each player has to minutes to select an estimate value from their hand and play it face down on the table. After everyone has played a card, they’re all turned face up and compared.
An average estimate value is computed from the played values. For example, is a game with three players, the estimate might be:
Charlie: 5
Stella: 5
David: 1/2
The team estimate here is 3.5 hours (at least is some versions of the game. Some folks don’t uses averages) . At this point the team discusses the estimate again and can either choose to accept the current estimate, manually adjust the estimate and accept the new value, or play another hand with the same story. How do they decide what to do?
First off, there are a couple of things to watch for in a planning game. One is wide variances in estimation, either high or low. For example, in the example above, David’s estimate was considerably lower than his fellow players. This is a sign that something’s not right and needs further discussion. David could just be a really poor estimator, or perhaps he has information that leads him to believe the task is far simpler than the others has assumed. In any case, such wide divergence warrants discussion and probably another round of estimation so see if the players can get closer to a flat consensus.
Another thing is to watch for is having too much granularity in the estimate deck. The levels I’ve described above are those used by the online planning game at http://planningpoker.com. I really like this site, since it allow remote players to use the planning game. However, I think that there are too many cards in the hand. I like the suggestions in this InfoQ article: http://www.infoq.com/articles/agile-estimation-techniques. The powers-of-two suggestion and capping out at 8 hours is good.
The cap is another important item. Any user story that takes more than 8 hours in an estimate is probably not specific enough to implement. In other words, it needs to be decomposed or re-written.
There’s a lot of information on planning games in the agile development literature. They’re a great way to generate estimates that have some chance in heck of being more-or-less correct.
August 28th, 2008 at 8:15 am
George,
Sounds like the Agile process really worked in your favor even in the short duration. My own experience with Agile comes from reading about it and practicing it only with a small team (4 person team). Some have said that Agile doesn’t work best in such a small team.
Nonetheless, I took note of the important parts of XP and Scrum and made my own process called SPIT. Note that I was in a start-up environment where prototyping and time to market were crucial elements of success.
S = Simple. Quality of code is important but in a start-up environment, simple is more important. If you don’t need layers of abstraction, just keep it simple.
P = Priorities. I mainly prioritized the top 10 things to be done. Item #11 and beyond goes on to version 2.
I = Iterative. We released new functionality every two weeks. We released bug fixes every week.
T = Tested. Testing, testing….I can say enough about testing. We didn’t have a QA team but even user acceptance testing in terms of core functionality was key.
I came up with the acronym so we can say “Let’s SPIT out products quickly”.
My 2 cents.
Ivan
November 14th, 2008 at 8:38 am
So, we used this process again for another client - Transition Assist. Overall the project was successful, but it took longer to complete (about 10 weeks) than the Vizzitt project. On this project, we identified 3 primary iterations that were 2-3 weeks in duration. After the 3rd iteration, we also had a 1-2 week period of bug fixing and feature refinement before the site was finalized for launch.
As I think back to why the Transition Assist project took as long as it did, 2 primary reasons come to mind. The first reason is not so interesting - team member allocation was not as high as it should have been.
The more interesting reason is that the core feature of the website - a health plan comparison tool - required a very complex user interface. This UI included the ability to search, compare and save complex and detailed health plan information, which required many rounds of refinement.
As a lesson learned, features requiring a complex UI should be identified up-front with a plan for continual refinement (ideally including user testing) built into the project plan. Of course, continual refinement will burn through a fair amount of hours, which may end up detracting other tasks. All of this should be considered when identifying the scope of each iteration.
I think we did a good job of identifying the complexity of the plan comparison feature up front, but I also think we under-estimated the amount of refinement that would need to occur throughout the project.
Despite this lesson, I do think the project was a success and I was amazed by how much functionality we actually delivered in such a short period of time. Once again, the Ruby on Rails platform proved to be an excellent choice.