1. Lean development constrains time, not scope
Plan to spend a fixed amount of time working on a set of functionality. If you overestimate what you can produce in that amount of time, don’t adjust the deadline–adjust the scope. I’ve taken out sorting, filtering, and other behavior to make a monthly release deadline. Note the missing behavior and bundle it for a subsequent iteration. At the end of each month, I’d reflect on what I did to over/underestimate, then learn and adjust going forward.

There are a few compelling benefits to constraining time over scope. Estimating, previously one of the hardest tasks for me to do accurately and important during end-of-year performance evaluations, became easier because I was always working with the same unit of time (one iteration is always one month). Scheduling Q/A and planning sessions time was straightforward since I was making my deadlines.

Constraining deadlines over scope results in better prioritization. I’ll start on the required functionality, saving nice-to-haves until the end. If I am approaching an end-of-month deadline, I’ll postpone (or eliminate, team willing) the least cost-effective functionality. I feel this has the effect of focusing staff time on the most valuable functionality.

2. Frequent reviews, lots of feedback
Transitioning from the design mockup to a working product is a big step where many usability and programmatic issues are discovered. Including Q/A and designer at the beginning and end of each month-long iteration saved time in the long run because these issues were discovered earlier in the implementation phase while the code was still flexible.

Having a designer writing HTML, CSS, and javascript code was also helpful. We invited our designer in the first Q/A session of each month, allowing Q/A to talk directly to the designer about user interface issues (wording, confusing behavior, potential support issues, etc….) I thought it was more effective for the two to communicate directly instead of interpreting and relaying messages between the two team members.

When releases are small and frequent, making minor course corrections becomes much easier. With the waterfall method, I wouldn’t see a designer or Q/A very much until major coding was completed. I’d receive a huge amount of feedback right at the worst time: when code was mostly complete, rigid, and changes were very error-prone. This feedback was more than just application bugs–it included UI and requirement changes. With our three person team frequently reviewing the product and communicating, we could quickly identify what needed to be changed (either due to oversight or a change in our perception of user needs) and then decide on a course of action.

Conclusion & Looking Forward
We’ve brought Q/A fully into the iterative development, next I’d like to see if bringing our design activities into the iterative process is more effective than completing the design mockups prior to coding. I think we’ve already seen the benefit of keeping the design flexible during implementation, allowing us to quickly make necessary UI changes. Perhaps with a solid requirements, a good roadmap, and some rough mockups this added flexibility will result in more usable applications. Keeping the design rough and more open to change could reduce some of the friction that comes when the team is reviewing “final” UI design documents.

I think the ingredients essential to delivering this application on-time and within budget were:

• Partnering with a user experience expert who designed the mock ups and wrote the bulk of HTML, CSS, and Javascript
• Doctrine ORM: previously we hand-crafted SQL which was error-prone and occasionally introduced security vulnerabilities.
• Month-long development iterations with a tested, working product delivered at the end of every month.

Looking forward, there is an increasing need at our campus for an Academic Personnel Review web application, which will transform a paper process into a fully online process. The major motivation behind this project is to reduce the massive amount of staff time that goes into coordinating this process in each campus unit.

This application will very likely be built in Java!

MessageBoards will provide board, forum, thread, and post-level functionality we have all grown to love–yet in the context of our academic portal tied into roster info.

I’d like to approach the way I code this tool differently, specifically:

• Introduce month-long design/code/QA iterations.
• Unit & integration testing.
• Create a good set of Selenium tests.
• Use the Doctrine framework for the underlying model.

Why bother changing the approach? We could code this tool just fine without changing the process, adding automated tests, and changing the framework.

MessageBoards is a big experiment. It may actually take longer to develop (although I hope not)–and it will give us a lot of good feedback on some new web development approaches that promise to reduce time to delivery. Delivering results faster–and with similar quality–would be a huge win.

There are a lot of variables in play, like the percent of time I dedicate to MessageBoards, and the four new approaches mentioned above. In the end, I anticipate it will be a challenge to isolate which variables added or removed value.

Another couple variables I bet will reduce time to delivery: working in parallel with a talented UI designer and the excitement of possibly finding something that will make other programmer’s lives easier.