For the past 7 months I’ve been trying lean web application development for the MessageBoard project. Now that the project is complete, I thought I’d compare lean application development with the typical waterfall method. Many of these ideas came from the book Implementing Lean Software Development, which I highly recommend reading if you are used to a conventional waterfall development process.
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.
no comment untill now